Re: Telemetry Policy - Remaining Questions
On 4 April 2018 at 12:37, Ben Cooksley wrote: > On Tue, Apr 3, 2018 at 8:57 PM, Jaroslaw Staniek wrote: > > > > > > On 3 April 2018 at 10:17, Ben Cooksley wrote: > >> > >> On Tue, Apr 3, 2018 at 11:20 AM, Jaroslaw Staniek > wrote: > >> > > >> > > >> > On 2 April 2018 at 22:56, Lydia Pintscher wrote: > >> >> > >> >> Hey Jaroslaw :) > >> >> > >> >> On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek > >> >> 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 > cooki
Re: Telemetry Policy - Remaining Questions
On Tue, Apr 3, 2018 at 8:57 PM, Jaroslaw Staniek wrote: > > > On 3 April 2018 at 10:17, Ben Cooksley wrote: >> >> On Tue, Apr 3, 2018 at 11:20 AM, Jaroslaw Staniek wrote: >> > >> > >> > On 2 April 2018 at 22:56, Lydia Pintscher wrote: >> >> >> >> Hey Jaroslaw :) >> >> >> >> On Mon, Apr 2, 2018 at 10:28 PM, Jaroslaw Staniek >> >> 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
Re: Telemetry Policy - Remaining Questions
On Tuesday, 3 April 2018 18:16:10 CEST Jaroslaw Staniek wrote: > On 3 April 2018 at 10:42, Volker Krause wrote: > > > > https://community.kde.org/Talk:Policies/Telemetry_Policy# > > > > > > Thank you! Volker is probably best equipped to answer these. > > > > I've commented on all points on the talk page now I think. > > Thanks Volker, > I must have missed the info that the concepts of intervals have been > documented two weeks ago. Apologies. > The concept has potential to change the game and convince people to > "invest" in telemetry. However maybe a pilot phase with an app or two would > be more in place to see the results. Policies would then follow reality > even more. The agreement at Akademy 2017 was to not do that without regulation, which is what got us here. > It would be good to consider picking larger projects, e.g. part of KDE > Applications release or Plasma itself, and with maintainers able to discuss > during the Akademy. Right. That's what happened last year, that's why we are having the policy draft and this discussion. > KEXI is just not in this group. Also, based on my > knowledge, statistical KEXI users would not even have access to the KDE > "kill switch" since Plasma is rarely used by them. That's why the policy says "[...] where they exist.". Obviously if you are running on a system without such settings there is nothing you can do, so you just follow per-application settings there. > In particular there is a chance that if pilot apps get released with the > KUserFeedback telemetry, the challenge of handling access to the raw > anonymized data would get addressed, since we would know why there is the > interest in data and what is the purpose of collecting it. In the > post-Akademy thread Ingo Klöcker has once provided interesting general > observation, even it it refers to German law. Once the data "leaks" outside > of the telemetry team (say telemetry team within a single app project), to > people not even affiliated with the project, it is no longer possible to > expect it (the data) is used in a way compliant with the Policy, and > only for the needs of "legal" telemetry. KDE would still be responsible for > all the uses of the data. Coming year stronger law comes to Poland too. That's where the motivation to make the result "data" rather than "personal data" comes from. Then leaking/sharing/etc is not a problem. As soon as there is anything in there considered "personal data" (as defined by data protection regulation), you are right, we need access control, data removal procedures, limited storage time, etc, and come into scope of GDPR & friends. That is why allowing a unique identifier makes such a big difference to all of this. > So making it harder to download the data and increasing level of its > aggregation would make sense then to me. Long-term idea would also > be giving access to an analysis tool and the results instead of to the data > on which the tool operates. > > > And then in the meantime folks like the Promo team have potential to work > on proper messaging to improve the number users understanding and accepting > telemetry. My example follows here. On more "human" level: KEXI offering a > telemetry "for KDE" that is still seen as a "desktop" (regardless of a > reason) than "for KEXI Team" would be potentially a disadvantage for the > app's project itself. KDE contributors and fans understand the idea of an > organization. I've learned from my group that for everyone else "Help > improve Visual Studio" type of message tends convince more than more > questionable "Help Microsoft" ;) How to communicate things to the user is an important topic, and probably has no unified answer. I indeed can see that being different for say KEXI and Plasma. However, I do think it's useful for this to be able to point to strong regulation that ensures privacy, control and transparency. Regards, Volker signature.asc Description: This is a digitally signed message part.
