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