<div dir="ltr"><div class="gmail_default" style="font-family:monospace,monospace;font-size:small"><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 17 August 2017 at 16:19, Volker Krause <span dir="ltr"><<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Wednesday, 16 August 2017 20:35:59 CEST Jaroslaw Staniek wrote:<br>
> On 16 August 2017 at 18:56, Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@kde.org</a>> wrote:<br>
> > On Wednesday, 16 August 2017 15:23:07 CEST Jaroslaw Staniek wrote:<br>
> > > On 16 August 2017 at 14:13, Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@kde.org</a>> wrote:<br>
</span>[...]<br>
<span class="gmail-">> > > In addition maybe distributors can sometimes make the decision based on<br>
> > > opinions from given subprojects.<br>
> > > For example the option would be pre-set to ON in KEXI's installer for<br>
> > > Mac and  Windows itself and for Linux AppImages, not in the source code.<br>
> > > Just saying, KEXI has not yet switched to the new framework :)<br>
> ><br>
> > The policy we are discussing here is (and is supposed to be) independent<br>
> > of the implementation. And that's not just theoretical, Kexi is one<br>
> > prominent case for an alternative implementation, and the Krita GSoC also<br>
> > seems to contain some alternative server code for example. So input in<br>
> > particular from those teams matters a lot for me, as this policy in its<br>
> > current form would affect them too.<br>
> ><br>
> > And a policy we only adhere in code and work around in the end by putting<br>
> > on a distributor hat (which we can in many places, as your examples show)<br>
> > isn't really helping, I'd much rather have it reflect what we actually do<br>
> > :)<br>
> ><br>
> > From having read the code of both, I think the only possible points of<br>
> > conflict with the policy draft might be:<br>
> > - opt-in<br>
><br>
> Source code has 100% of opt-in (grep for<br>
> 'areas(KexiUserFeedbackAgent::<wbr>NoAreas)'). Anyone is free to change this<br>
> default and create distribution under his name and I understand this will<br>
> not be a "distribution by KDE".<br>
<br>
</span>Great, so I just misread both Krita's and Kexi's requirements here and we<br>
don't have a problem :)<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">In case of KEXI the idea from the very beginning was to make also some distros happy (avoid the need of patching the source).<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> > - hosted on KDE infrastructure<br>
><br>
> My assumption: As KEXI is an open-core+whatever-license-<wbr>for-plugins<br>
> architecture, ultimately the telemetry information from KEXI users would be<br>
> better hosted by KDE. Any extra information retrieved by plugins (if that<br>
> even exists) can be hosted elsewhere but and this is a responsibility of<br>
> plugin developers.<br>
<br>
</span>Yep, I'd say 3rd party addons are encouraged to follow the same policy, just<br>
like distributors, but we have no way of actually enforcing it.<br>
<span class="gmail-"><br>
> > - Kexi seems to (optionally?) contain a unique identifier<br>
><br>
> This is mostly related to cases when any kind of cloud storage is used.<br>
> These cases involve unique accounts already so users can be identified very<br>
> well even without having telemetry functionality.<br>
><br>
> KEXI installations limited to open-core, used away from a cloud, do not<br>
> need identifiers.<br>
> However I understand that identifiers, independent of network or host ID<br>
> (basically a random-generated QUuids) are useful for even basic telemetry<br>
> needs. Without them it's easy to abuse the system using any kind of bots to<br>
> trick us that e.g. 99% of sessions happen on KDE 1.0 or that given Linux<br>
> distro has 90% of the global market :)<br>
<br>
</span>Vandalism is a potential problem indeed (did you actually have issues with<br>
that on Kexi btw? if so, what counter-measures did you apply?). However I<br>
don't see how a UUID is helping here, the bot could just as well generate<br>
UUIDs for each submission?<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">UIDs indeed can't help with too clever bots ​but e.g. semi-evil use cases such as executing apps in batch mode can be catch. I've mostly encountered logs coming from test machines including myself so I probably should not have used the term 'bots' but (as unrealistic as it sounds) real bots can be created.<br><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> Similarly app projects may need the IDs to answer question about most and<br>
> least used features. Most used as in "most users found it, understood it<br>
> and use it", not "most usage reports has been delivered for it (maybe<br>
> coming from a single user -- maybe even my very own co-developer). There<br>
> are many other examples probably already discussed.<br>
<br>
</span>Sure this gets easier with unique ids, but it's not impossible without them.<br>
After all the goal here isn't to make our lives easier, but to agree on<br>
something that is acceptable for our users. And yes, that might imply more<br>
work and/or less accurate data.<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">My assumption when started with telemetry was having adequate level of precision. Assuming no logs are fabricated as fake interesting questions are for example: how many users actually run supported software and how many run outdated one? Not how many executions per given period of time because it may be that old software is executed by a few users very frequently for some reason. e.g. because 3 years old sofware crashes on old OS every minute and restart was needed :)<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">How to know that without unique (anonymous) identification?<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Using extra fields such as OS+Desktop type/version would be indeed a form of cheap UID. <br>But I would say disclosing OS+Desktop type/version for that discloses more than the anonymous random UID represents.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">In bugzilla and mailing list we're asking for all this information too anyway and (at least I) do not like supporting anonymous users since I am not anonymous.<br></div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">​BTW, it's worth to remind, the UID is not even a hash of any host and user info, it's a random number. I do admit that "hash of a host and user info" would be even better as it allows to recreate the UID after e.g. OS has been reinstalled or new account created. But I do not use hashing for KEXI anyway.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> Thus I would see the Anonymity is covered by KEXI's approach except that it<br>
> offers opt-in tracking of unique user for unique installations. KEXI<br>
> currently does not track unique installations at all until the user agrees<br>
> for any telemetry (the KexiUserFeedbackAgent::<wbr>AnonymousIdentificationArea<br>
> value). This is required by nature of stats computed (and abuses mentioned<br>
> above are the reason).<br>
><br>
> Is this a big deal? We're close to philosophy area here.<br>
<br>
</span>Correct, this is about the philosophy behind our products :) And one very core<br>
part of that happens to be privacy.<br>
<br>
That basically leaves the question: do we want to additionally allow the opt-<br>
in use of unique identifiers?<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">I would say yes. For example ​I see no reasons to reject any (inter)network software having ​a concept of accounts from KDE. Our Phabricator and forums and bugzilla are example of that. Well, our very own Akademy registration software especially if it's "our" code base. All of them operate with unique IDs. Even more: some software disclose some user-visible strings (e.g. user names on the forums).<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">I think the key is to require that the apps, no matter what type, precisely and clearly ask users for the agreement. And do not scare them.<br></div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class="gmail-"><br>
> Before designing the stats engine I guessed: not more than installing an<br>
> email app or buying a SIM card and starting to use them; they allow me to<br>
> send email or make a call using protocols that disclose quite a bit about<br>
> me.<br>
<br>
</span>Sure, but that is also where we can differentiate. Just because other<br>
applications <div style="font-family:monospace,monospace;font-size:small;display:inline" class="gmail_default">​​</div>weren't designed with privacy in mind doesn't mean we should<br>
follow their example IMHO.<br></blockquote><div><br><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Well, ​"​weren't designed with privacy in mind"​ sounds s bit strong. Each application has desired *level* of privacy hopefully defined maybe at design time. I can imagine a storage for KEXI that is using public GitHub account and repos in exchange for being free-as-beer cloud solution.<br><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Example. Our KDE software runs on hardware that is not assuring privacy (emits signals that someone can easily decipher). ​"The apps weren't designed with privacy in mind because they should block non-open CPUs" -- someone with high-enough expectations would easily say. "But we don't care, we still want to develop them and see them used" -- we say, that's not our level.<br><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">For most of the folks email has confidentiality are the SIM is OK.<br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default"><br></div><div style="font-family:monospace,monospace;font-size:small" class="gmail_default">Thanks for the notes and for working on the stuff, Volker.<br><br></div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Volker<br>
<div class="gmail-HOEnZb"><div class="gmail-h5"><br>
> I would respect<br>
> users that disagree with that but they are unlikely to become KEXI users.<br>
> For in my book anonymous users less likely receive support from me in the<br>
> MLs or forums.<br>
><br>
> > Regards,<br>
> > Volker<br>
> ><br>
> > > > Seeing yesterday's blog from the Krita team (<br>
> ><br>
> > <a href="https://akapust1n.github.io/" rel="noreferrer" target="_blank">https://akapust1n.github.io/</a><br>
> ><br>
> > > > 2017-08-15-sixth-blog-gsoc-<wbr>2017/), I'd particularly be interested in<br>
> ><br>
> > their<br>
> ><br>
> > > > view on this.<br>
> > > ><br>
> > > > Regards,<br>
> > > > Volker<br>
> > > ><br>
> > > > > On Sun, Aug 13, 2017 at 3:18 AM, Christian Loosli<br>
> > > > ><br>
> > > > > <<a href="mailto:christian.loosli@fuchsnet.ch">christian.loosli@fuchsnet.ch</a>> wrote:<br>
> > > > > > Hi,<br>
> > > > > ><br>
> > > > > > thank you very much for this work, sounds great!<br>
> > > > > ><br>
> > > > > > Only point I have: maybe make sure that the opt-in / default<br>
> ><br>
> > settings<br>
> ><br>
> > > > are<br>
> > > ><br>
> > > > > > not only mandatory for application developers, but also for<br>
> ><br>
> > packagers<br>
> ><br>
> > > > > > /<br>
> > > > > > distributions.<br>
> > > > > ><br>
> > > > > > Some distributions have rather questionable views on privacy and<br>
> > > > > > by<br>
> > > > > > default<br>
> > > > > > sent information to third parties, so I would feel much more safe<br>
> ><br>
> > if<br>
> ><br>
> > > > they<br>
> > > ><br>
> > > > > > weren't allowed (in theory) to flick the switch in their package<br>
> > > > > > by<br>
> > > > > > default to "on" either.<br>
> > > > > ><br>
> > > > > > Kind regards,<br>
> > > > > ><br>
> > > > > > Christian<br>
<br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">regards, Jaroslaw Staniek<br><br>KDE:<br>: A world-wide network of software engineers, artists, writers, translators<br>: and facilitators committed to Free Software development - <a href="http://kde.org" target="_blank">http://kde.org</a><br>Calligra Suite:<br>: A graphic art and office suite - <a href="http://calligra.org" target="_blank">http://calligra.org</a><br>Kexi:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>Qt Certified Specialist:<br>: <a href="http://www.linkedin.com/in/jstaniek" target="_blank">http://www.linkedin.com/in/jstaniek</a></div>
</div></div>