<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 4 April 2018 at 12:37, Ben Cooksley <span dir="ltr"><<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@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"><div class="gmail-HOEnZb"><div class="gmail-h5">On Tue, Apr 3, 2018 at 8:57 PM, Jaroslaw Staniek <<a href="mailto:staniek@kde.org">staniek@kde.org</a>> wrote:<br>
><br>
><br>
> On 3 April 2018 at 10:17, Ben Cooksley <<a href="mailto:bcooksley@kde.org">bcooksley@kde.org</a>> wrote:<br>
>><br>
>> On Tue, Apr 3, 2018 at 11:20 AM, Jaroslaw Staniek <<a href="mailto:staniek@kde.org">staniek@kde.org</a>> wrote:<br>
>> ><br>
>> ><br>
>> > On 2 April 2018 at 22:56, Lydia Pintscher <<a href="mailto:lydia@kde.org">lydia@kde.org</a>> wrote:<br>
>> >><br>
>> >> Hey Jaroslaw :)<br>
>> >><br>
>> >> On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek <<a href="mailto:staniek@kde.org">staniek@kde.org</a>><br>
>> >> wrote:<br>
>> >> > Thanks for reminding me Lydia<br>
>> >> ><br>
>> >> > I've not forgotten this. While there's progress I do still see this<br>
>> >> > as a<br>
>> >> > pilot stage and do not think we're in a hurry given telemetry is<br>
>> >> > something<br>
>> >> > "extra" for a project development, not a core feature of any product.<br>
>> >><br>
>> >> We are in a hurry now. We're waiting for projects to be able to start<br>
>> >> using it and get us valuable insights about how our software is used.<br>
>> >> We've been on it since last Akademy. Let's get it finished :)<br>
>> >><br>
>> >> > Below I am referring to this version:<br>
>> >> ><br>
>> >> ><br>
>> >> > <a href="https://community.kde.org/index.php?title=Policies/Telemetry_Policy&oldid=78057" rel="noreferrer" target="_blank">https://community.kde.org/<wbr>index.php?title=Policies/<wbr>Telemetry_Policy&oldid=78057</a><br>
>> >> ><br>
>> >> > tl;dr: Why discussing: Any deep change and limitation to projects'<br>
>> >> > freedom<br>
>> >> > needs to bring substantial benefits over drawbacks. Level of<br>
>> >> > complexity<br>
>> >> > of<br>
>> >> > the contract for a project or individual developer needs to be<br>
>> >> > balanced<br>
>> >> > by<br>
>> >> > real (not hypothetical) benefits.<br>
>> >><br>
>> >> The benefits here for KDE are:<br>
>> >> * we have a<br>
>> >> better understanding of our userbase leading hopefully to<br>
>> >> better software<br>
>> >> * we have a better understanding of our userbase leading hopefully to<br>
>> >> better marketing<br>
>> >> * we have a clear policy we can point our users to that explains how<br>
>> >> we are handling their data and that is in line with our vision/what we<br>
>> >> stand for.<br>
>> >><br>
>> >> > I've studied the wiki page more in depth and I have these points<br>
>> >> > where<br>
>> >> > I'd<br>
>> >> > like to see improvement. This is based on my experience, not a list<br>
>> >> > of<br>
>> >> > quick<br>
>> >> > ideas.<br>
>> >> ><br>
>> >> ><br>
>> >> <a href="https://community.kde.org/Talk:Policies/Telemetry_Policy#" rel="noreferrer" target="_blank">https://community.kde.org/<wbr>Talk:Policies/Telemetry_<wbr>Policy#</a><br>
>> >><br>
>> >> Thank you! Volker is probably best equipped to answer these.<br>
>> >><br>
>> >> > That said: I will nod to the concept of "Minimalism", it is all<br>
>> >> > classic<br>
>> >> > property of telemetry. I think I've seen them in other projects too.<br>
>> >> > I'd just say, let's not make all this more limited than anyone wants<br>
>> >> > it<br>
>> >> > to<br>
>> >> > be.<br>
>> >><br>
>> >> Where is it too limited? Please keep in mind that we've set<br>
>> >> privacy as<br>
>> >> a core part of our vision and the current goals.<br>
>> ><br>
>> ><br>
>> > Lydia,<br>
>><br>
>> Hi Jaroslaw,<br>
>><br>
>> > It's a core part but still a part and can't contradict, say, with the<br>
>> > Freedom part.<br>
>> ><br>
>> > Please see the list of limitations:<br>
>> >  <a href="https://community.kde.org/Talk:Policies/Telemetry_Policy#" rel="noreferrer" target="_blank">https://community.kde.org/<wbr>Talk:Policies/Telemetry_<wbr>Policy#</a><br>
>> > (in my opinion that's not a "nice to haves" but requirements needed so<br>
>> > we<br>
>> > can even call the whole thing "telemetry")<br>
>> ><br>
>> > I am asking for an alternative approaches, Volker once mentioned there<br>
>> > are<br>
>> > some.<br>
>> > We need them to we move forward.<br>
>> ><br>
>> > In the meantime my stack runs just well, people that use IDs are even<br>
>> > given<br>
>> > right to remove their data, something that's *not* going to be possible<br>
>> > with<br>
>> > the proposed vision. Someone would convince me otherwise.<br>
>><br>
>> Please don't drag our websites ability to have people login to them<br>
>> into your argument here.<br>
>> Cookies as used by websites are quite different to Telemetry on many<br>
>> points.<br>
><br>
><br>
> Dear Ben, based on your experience I'd like to hear your voice how web apps<br>
> of any kind are different or are special cases, compared to apps that happen<br>
> to do the same but do not use the "web" stamp so discussed data collection<br>
> features are delegate to 3rd-party clients called web browsers.<br>
> How an OPT-IN ID like 2a7c819f-636c-403e-afa1-<wbr>c9e37031c1de based on random<br>
> generator[1] is more serious privacy concern than required<br>
> (login+email+password) non-anonymized tuple for web accounts of web apps of<br>
> any kind. Please do not take this as pointing to any core infrastructure, I<br>
> am pointing to specific established technology and practices.<br>
<br>
</div></div>Web applications (as we deploy anyway) are a bit different as the<br>
action of registering, and then logging in, requires specific and<br>
deliberate engagement on the users part while the Opt-In process used<br>
by applications could be as simple as a popup on first startup, or a<br>
checkbox in it's configuration (therefore making the required effort<br>
much lower). If at any point a user is not logged in, we have no idea<br>
who they are until they login (and many of our sites do not send any<br>
cookies until you try logging in)<br>
<br>
Additionally, the only information we collect from users is that which<br>
they deliberately enter in (and have therefore chosen to provide to<br>
us). We also don't record any viewing activity on our sites - only<br>
actions which change the site (such as posting a bug, editing a wiki<br>
page or commenting on a code review) are recorded against your profile<br>
(another decision you've had to consciously make). Application<br>
telemetry on the other hand is automatically transmitted, either on a<br>
time running basis or on application startup/shutdown and the user has<br>
limited involvement in the actual information being transmitted.<br>
<br>
The only exception to this is our web statistics, which are completely<br>
disconnected from all the login systems, and have sufficient fuzzing<br>
applied at the time of being recorded to be useless for identifying<br>
the user in question (it also respects do not track headers and the<br>
like)<br>
<span class="gmail-"><br>
><br>
> Then do we agree that the purpose of random ID collection is secondary as<br>
> long as both sides know it and agree on the terms of collaboration? And<br>
> even: can pull the data out.<br>
><br>
> I am calling functional web sites as apps, produced by any KDE projects,<br>
> hoping that's not seen as dragging. Please do not look at my concern as a<br>
> criticism towards the web apps because in my opinion apps of any technology<br>
> have right to use anonymized unique IDs at user's consent for purposes<br>
> clearly stated to the user to achieve openly explained goals welcomed by the<br>
> users. Or from a different angle, I see nothing in Freedom that prohibits<br>
> Free projects to offer such features to Free users unconditionally[2].<br>
><br>
> [1] If separating of independent aspects measured is a concern (e.g. [screen<br>
> size] from [locale]) unique user can have multiple IDs generated, one per<br>
> single analyzed group of aspects, to fully decouple one area from another in<br>
> the raw data (as in example: separating screen size analysis from locale<br>
> analysis).<br>
> [2] Unconditionally == as stated by the Policy point "applications can't tie<br>
> the availability of unrelated aspects of the application to telemetry being<br>
> enabled" that looks good to me and is needed. Applications designed to work<br>
> offline are still 100% functional when run offline right after installation.<br>
<br>
</span>I would rather that we do not have any form of unique identifier<br>
associated with the information, due to the GDPR compliance risks it<br>
imposes.<br>
<br>
We need to be careful enough as it is with the types of telemetry data<br>
we do collect, as it could still be considered personally identifying<br>
information.<br>
People have already done research into this space - see<br>
<a href="https://panopticlick.eff.org/" rel="noreferrer" target="_blank">https://panopticlick.eff.org/</a> - therefore careful consideration should<br>
be made as to the device characteristics we do collect.<br>
<br></blockquote><div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline"><br></div></div><div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">Thanks for the ​thorough info Ben.</div></div><div><div class="gmail_default" style="font-family:monospace,monospace;font-size:small;display:inline">I understand that admins of the data (from the legal POV) have the last say.</div></div></div><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div>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>KEXI:<br>: A visual database apps builder - <a href="http://calligra.org/kexi" target="_blank">http://calligra.org/kexi</a><br>  <a href="http://twitter.com/kexi_project" target="_blank">http://twitter.com/kexi_project</a> <a href="https://facebook.com/kexi.project" target="_blank">https://facebook.com/kexi.project</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></div></div>
</div></div>