Re: Telemetry Policy - Remaining Questions
On 30 April 2018 at 22:54, Lydia Pintscher wrote: > On Mon, Apr 30, 2018 at 10:41 PM Jaroslaw Staniek wrote: > > Hello > > Now we can assume that solution to non-unique identification Volker > explained in acceptable equivalent of random identifiers so KEXI does not > need exception. > > Thanks for patience! > > > I understand KEXI has time until the next release to switch to > KUserFeedback. In other words, next non-patch release (3.2) would be > compliant and would store data within KDE infra. For 3.1.x we can stop > saving unique random identifiers. > > Perfect. Thank you! > Update: as a first step, I disabled collecting *any* data on kexi-project.org so it's not related to the GDPR matters at all. -- 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
Re: Telemetry Policy - Remaining Questions
On Mon, Apr 30, 2018 at 10:41 PM Jaroslaw Staniek wrote: > Hello > Now we can assume that solution to non-unique identification Volker explained in acceptable equivalent of random identifiers so KEXI does not need exception. > Thanks for patience! > I understand KEXI has time until the next release to switch to KUserFeedback. In other words, next non-patch release (3.2) would be compliant and would store data within KDE infra. For 3.1.x we can stop saving unique random identifiers. Perfect. Thank you! Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors http://kde.org - http://open-advice.org
Re: Telemetry Policy - Remaining Questions
On 30 April 2018 at 22:08, Lydia Pintscher wrote: > Hey folks, > > Jaroslaw: > * Given that > > GDPR is coming into effect on May 25th I'd like to urge you to > look into if what you're currently tracking is acceptable under that > regulation. I don't know how where the data you're collecting currently > ends up but I don't want the e.V. to be liable for personally identifiable > information ending up on non-e.V. servers etc. > * Please make a choice if you're willing to change Kexi to comply with the > policy or if you prefer it to be marked as a historic exception. (My > preference is not to have any exceptions to the policy and make a clear > statement to our users.) > Hello Now we can assume that solution to non-unique identification Volker explained in acceptable equivalent of random identifiers so KEXI does not need exception. Thanks for patience! I understand KEXI has time until the next release to switch to KUserFeedback. In other words, next non-patch release (3.2) would be compliant and would store data within KDE infra. For 3.1.x we can stop saving unique random identifiers. > Everyone: Unless there are big objections within the next week let's > consider the current draft at > https://community.kde.org/Policies/Telemetry_Policy accepted. > > > Cheers > Lydia > > -- > Lydia Pintscher - http://about.me/lydia.pintscher > KDE e.V. Board of Directors > http://kde.org - http://open-advice.org > -- 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
Re: Telemetry Policy - Remaining Questions
Hey folks, Jaroslaw: * Given that GDPR is coming into effect on May 25th I'd like to urge you to look into if what you're currently tracking is acceptable under that regulation. I don't know how where the data you're collecting currently ends up but I don't want the e.V. to be liable for personally identifiable information ending up on non-e.V. servers etc. * Please make a choice if you're willing to change Kexi to comply with the policy or if you prefer it to be marked as a historic exception. (My preference is not to have any exceptions to the policy and make a clear statement to our users.) Everyone: Unless there are big objections within the next week let's consider the current draft at https://community.kde.org/Policies/Telemetry_Policy accepted. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors http://kde.org - http://open-advice.org
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.
Re: Telemetry Policy - Remaining Questions
On 3 April 2018 at 10:42, Volker Krause wrote: > Thanks Lydia for getting this moving again! > > On Monday, 2 April 2018 22:56:31 CEST 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. > > 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. 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. 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. 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. 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" ;) -- 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
Re: Telemetry Policy - Remaining Questions
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. 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
Re: Telemetry Policy - Remaining Questions
Thanks Lydia for getting this moving again! On Monday, 2 April 2018 22:56:31 CEST 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. I've commented on all points on the talk page now I think. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy - Remaining Questions
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. Regards, Ben > > -- > 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
Re: Telemetry Policy - Remaining Questions
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, 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. -- 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
Re: Telemetry Policy - Remaining Questions
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. Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors http://kde.org - http://open-advice.org
Re: Telemetry Policy - Remaining Questions
On 1 April 2018 at 15:41, Lydia Pintscher wrote: > Hey folks :) > > We really need to wrap this up now. > > We need the data and we need the > policy in place. It's holding us back from learning more about our > users and making our software better. That's not good. > > On Sat, Nov 11, 2017 at 12:47 PM, Volker Krause wrote: > > So, I see the following possible ways forward: > > (1) We accept the policy in its current spirit, and Kexi complies with > it (if > > necessary after some transition period). > > This would be the ideal way forward and the right thing to do. > > > (2) We accept the policy in its current spirit, and Kexi is exempt from > it. > > As sebas said this is bad communication-wise. But if Kexi can't or > doesn't want to comply that's the next best option. > > > (3) We make the policy opt-in, ie. using it merely as an extra quality > > criteria for the applications wanting to follow it. > > I don't believe this is an option that's in line with our vision. > > > (4) We give up on the idea of regulating telemetry, rolling back on the > > decision from Akademy. > > I don't think that's an acceptable option either because we need to > get a better understanding of how our software is used in order to > make it better. > > Jaroslav: I think you need to make a choice now for Kexi. We can't let > it sit and hope it goes away ;-) > 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. 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. 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# 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. -- 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
Re: Telemetry Policy - Remaining Questions
Hey folks :) We really need to wrap this up now. We need the data and we need the policy in place. It's holding us back from learning more about our users and making our software better. That's not good. On Sat, Nov 11, 2017 at 12:47 PM, Volker Krause wrote: > So, I see the following possible ways forward: > (1) We accept the policy in its current spirit, and Kexi complies with it (if > necessary after some transition period). This would be the ideal way forward and the right thing to do. > (2) We accept the policy in its current spirit, and Kexi is exempt from it. As sebas said this is bad communication-wise. But if Kexi can't or doesn't want to comply that's the next best option. > (3) We make the policy opt-in, ie. using it merely as an extra quality > criteria for the applications wanting to follow it. I don't believe this is an option that's in line with our vision. > (4) We give up on the idea of regulating telemetry, rolling back on the > decision from Akademy. I don't think that's an acceptable option either because we need to get a better understanding of how our software is used in order to make it better. Jaroslav: I think you need to make a choice now for Kexi. We can't let it sit and hope it goes away ;-) Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher KDE e.V. Board of Directors http://kde.org - http://open-advice.org
Re: Telemetry Policy - Remaining Questions
On Tuesday, 31 October 2017 11:56:23 CET Sebastian Kügler wrote: > On Tuesday, October 31, 2017 10:39:38 AM CET Volker Krause wrote: > > On Monday, 30 October 2017 21:24:59 CET Albert Astals Cid wrote: > > > El dilluns, 30 d’octubre de 2017, a les 9:56:52 CET, Volker Krause > > > va > > > > > > > Let's try to finally get this finished > > > > > > > > The only remaining blocker is the unique identification used by > > > > Kexi. There > > > > was some discussion about this around QtWS, and it seemed like > > > > there was consensus on having a strong policy on this topic would > > > > be a good thing for > > > > KDE, as opposed to e.g. turning this into just recommendations, or > > > > opening > > > > it up to unique identification. The suggested solution for Kexi > > > > was to add > > > > a special exception for it to the "These rules apply to all > > > > products released by KDE." statement of the policy. > > > > > > I'm confused, is that a workaround so that it doesn't apply to Kexi > > > by implying Kexi isn't released by KDE? > > > > That sounds a bit convoluted to me, I was more thinking about making > > it a direct exception to the policy, e.g. like this: > > > > "These rules apply to all products released by KDE (with the > > exception of Kexi, which uses a telemetry system predating this > > policy)." > > This will make the communication downright awful, as people will > concentrate on the exception, not the rule. Quite possible, yes. > I'm thinking along the lines of require code released by KDE to adopt > the policy and even add it to the manifesto as requirement to make it > easier to enforce. With respect to T7050 I agree with this, although we'd probably need a broader set of privacy-related policies for that, telemetry is just one building block there. > Kexi can always make it opt-in, and could be given > some time to do so before we officially adopt and require this > telemetry policy. It's not about opt-in vs. opt-out, the problem with the current policy draft is the unique identification used in Kexi. In my understanding that would turn the collected data into "personal data" in the legal sense (similar to e.g. IP addresses). The whole thing was designed to avoid that and the consequences it has, so relaxing the restriction on unique identification essentially results in a considerable change to the spirit of the current draft. So, I see the following possible ways forward: (1) We accept the policy in its current spirit, and Kexi complies with it (if necessary after some transition period). (2) We accept the policy in its current spirit, and Kexi is exempt from it. (3) We make the policy opt-in, ie. using it merely as an extra quality criteria for the applications wanting to follow it. (4) We give up on the idea of regulating telemetry, rolling back on the decision from Akademy. Obviously, I'd prefer one of the first two options. But this is now dragging on since Akademy and leads to the bizarre situation that I am only allowed to use some of my KDE code (KUserFeedback) in non-KDE applications but not in KDE applications I'm working on... Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy - Remaining Questions
On 31 October 2017 at 11:56, Sebastian Kügler wrote: > On Tuesday, October 31, 2017 10:39:38 AM CET Volker Krause wrote: >> On Monday, 30 October 2017 21:24:59 CET Albert Astals Cid wrote: >> > El dilluns, 30 d’octubre de 2017, a les 9:56:52 CET, Volker Krause >> > va >> > > Let's try to finally get this finished >> > > >> > > The only remaining blocker is the unique identification used by >> > > Kexi. There >> > > was some discussion about this around QtWS, and it seemed like >> > > there was consensus on having a strong policy on this topic would >> > > be a good thing for >> > > KDE, as opposed to e.g. turning this into just recommendations, or >> > > opening >> > > it up to unique identification. The suggested solution for Kexi >> > > was to add >> > > a special exception for it to the "These rules apply to all >> > > products released by KDE." statement of the policy. >> >> > I'm confused, is that a workaround so that it doesn't apply to Kexi >> > by implying Kexi isn't released by KDE? >> >> That sounds a bit convoluted to me, I was more thinking about making >> it a direct exception to the policy, e.g. like this: >> >> "These rules apply to all products released by KDE (with the >> exception of Kexi, which uses a telemetry system predating this >> policy)." > > This will make the communication downright awful, as people will > concentrate on the exception, not the rule. > I am sure energy would be concentrated on exception and nonconstructive activities (from 3rd parties?) because... please read below: > I'm thinking along the lines of require code released by KDE to adopt > the policy and even add it to the manifesto as requirement to make it > easier to enforce. Kexi can always make it opt-in, and could be given > some time to do so before we officially adopt and require this > telemetry policy. > Jaroslaw, would that work for you? because... one thing is apparently missed even in this internal thread: IIRC Kexi apps have never offered opt-out policy even for anonymous telemetry. I blogged about that as soon as the feature landed [1]. Users pick level of involvement, zero by default, and telemetry is presented as a way for involvement in the project not as a threat. [1] https://blogs.kde.org/2013/12/09/usage-stats -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy - Remaining Questions
On Tuesday, October 31, 2017 10:39:38 AM CET Volker Krause wrote: > On Monday, 30 October 2017 21:24:59 CET Albert Astals Cid wrote: > > El dilluns, 30 d’octubre de 2017, a les 9:56:52 CET, Volker Krause > > va > > > Let's try to finally get this finished > > > > > > The only remaining blocker is the unique identification used by > > > Kexi. There > > > was some discussion about this around QtWS, and it seemed like > > > there was consensus on having a strong policy on this topic would > > > be a good thing for > > > KDE, as opposed to e.g. turning this into just recommendations, or > > > opening > > > it up to unique identification. The suggested solution for Kexi > > > was to add > > > a special exception for it to the "These rules apply to all > > > products released by KDE." statement of the policy. > > > I'm confused, is that a workaround so that it doesn't apply to Kexi > > by implying Kexi isn't released by KDE? > > That sounds a bit convoluted to me, I was more thinking about making > it a direct exception to the policy, e.g. like this: > > "These rules apply to all products released by KDE (with the > exception of Kexi, which uses a telemetry system predating this > policy)." This will make the communication downright awful, as people will concentrate on the exception, not the rule. I'm thinking along the lines of require code released by KDE to adopt the policy and even add it to the manifesto as requirement to make it easier to enforce. Kexi can always make it opt-in, and could be given some time to do so before we officially adopt and require this telemetry policy. Jaroslaw, would that work for you? -- sebas http://www.kde.org | http://vizZzion.org
Re: Telemetry Policy - Remaining Questions
On Monday, 30 October 2017 11:27:58 CET Jaroslaw Staniek wrote: > On 30 October 2017 at 09:56, Volker Krause wrote: > > Let's try to finally get this finished :) > > > > The only remaining blocker is the unique identification used by Kexi. > > There was some discussion about this around QtWS, and it seemed like > > there was consensus on having a strong policy on this topic would be a > > good thing for KDE, as opposed to e.g. turning this into just > > recommendations, or opening it up to unique identification. The suggested > > solution for Kexi was to add a special exception for it to the "These > > rules apply to all products released by KDE." statement of the policy. > > > > That would still leave us with a strong policy on this subject, while > > solving the conflict with Kexi's current way of collecting telemetry. > > Would that work for everyone? > > Hello > Thanks for pushing this forward Volker. > In the meantime I got an inspired idea to behave no different than KDE > web browsers do with unique cookies e.g. wrt the KDE Identity > accounts. > Namely there would be zero logic for IDs in Kexi itself but a cookie > feature with its standard behavior. As it's the case, it's opt-in. > For now I hope this is technically feasible and the result equivalent > of the previous solution if not even more flexible. > I would appreciate pointing flaws in my assumption. Timeline for that > can be connected to development of sign-in features. > > Unless there is desire to discuss exceptions for a range of KDE > software that implements client side for web technologies maybe there > is no need for adding specific exception for Kexi or having it > communicated by Kexi itself. We can obviously drop the exception as soon as it's no longer necessary. I'm not sure I fully understand the proposed implementation, but I do see local storage (via cookies or otherwise) as a way to address some of the unique identification use-cases, such as aggregating data from the same user. The comparison to KDE Identity is a bit confusing though, as the objective of that is unique identification for authorizing access, which inherently conflicts with anonymity. > I'd like to also mention apparent lack of clarity for the outside user > wrt what "products released by KDE" mean. What are the defaults in > deployed software is a decision of those who deploy the software; > legal modifications are allright. KDE "only" releases the source code. > So I would not place such a stamp "These rules apply to all products > released by KDE" e.g. in About boxes because this has low info value > for the actual user or can truly confuse. > I am mentioning this here to emphasize that I see telemetry more as a > part of the software deployment and support, not a part of the actual > "source code product". Decoupling any logic from the source code is > part of that. Right, we cannot ultimately enforce this due to the free software licenses. While we can only ask external distributors to follow the same rules, we are also a distributor in a number of cases (Windows, Android, Linux app bundles, Neon, etc), and can apply the rules there too. I agree that there is a communication/marketing aspect to this as well, and a policy document is not the right tool for that, especially when things get complicated. Regards, Volker > > On Thursday, 14 September 2017 00:20:57 CET Volker Krause wrote: > >> Hi, > >> > >> as not everyone follows long threads, let's start again for the remaining > >> issues. > >> > >> https://community.kde.org/Policies/Telemetry_Policy > >> > >> The following questions were left unanswered in the previous thread (see > >> there for the full arguments if needed): > >> > >> (1) Should we allow opt-in tracking of unique identifiers? > >> > >> This was requested by Jaroslaw, as Kexi has this right now and the policy > >> as written right now would thus conflict with it. > >> > >> (2) Should we require/allow/forbid publication of the raw data? > >> > >> Publication was suggested by Martin F. Practically, this would have to > >> allow for a certain delay, we can't have public access to live data. > >> Suitable licensing options of the data would probably be CC0 or > >> CC-BY-SA. > >> > >> (3) Should we require a revocation feature? > >> > >> That is, allow the user to "delete" the data they submitted from the > >> server. This was also suggested by Martin F, and is technically possible > >> without compromising anonymity. > >> > >> (4) Should we define limits on how long we store the raw data? > >> > >> Brought up by Bhushan. > >> > >> (5) Should we require an "audit log" feature? > >> > >> Thas is, allow the user to see a detailed record of what has been > >> submitted > >> so far? Martin S suggested this (and it has been meanwhile implemented in > >> KUserFeedback). > >> > >> Not from the previous thread, but from a discussion in Randa: > >> (6) What is the "lower bound" of where we consider this policy to ap
Re: Telemetry Policy - Remaining Questions
On Monday, 30 October 2017 21:24:59 CET Albert Astals Cid wrote: > El dilluns, 30 d’octubre de 2017, a les 9:56:52 CET, Volker Krause va > > escriure: > > Let's try to finally get this finished :) > > > > The only remaining blocker is the unique identification used by Kexi. > > There > > was some discussion about this around QtWS, and it seemed like there was > > consensus on having a strong policy on this topic would be a good thing > > for > > KDE, as opposed to e.g. turning this into just recommendations, or opening > > it up to unique identification. The suggested solution for Kexi was to add > > a special exception for it to the "These rules apply to all products > > released by KDE." statement of the policy. > > I'm confused, is that a workaround so that it doesn't apply to Kexi by > implying Kexi isn't released by KDE? That sounds a bit convoluted to me, I was more thinking about making it a direct exception to the policy, e.g. like this: "These rules apply to all products released by KDE (with the exception of Kexi, which uses a telemetry system predating this policy)." Regards, Volker > > That would still leave us with a strong policy on this subject, while > > solving the conflict with Kexi's current way of collecting telemetry. > > Would > > that work for everyone? > > > > Regards, > > Volker > > > > On Thursday, 14 September 2017 00:20:57 CET Volker Krause wrote: > > > Hi, > > > > > > as not everyone follows long threads, let's start again for the > > > remaining > > > issues. > > > > > > https://community.kde.org/Policies/Telemetry_Policy > > > > > > The following questions were left unanswered in the previous thread (see > > > there for the full arguments if needed): > > > > > > (1) Should we allow opt-in tracking of unique identifiers? > > > > > > This was requested by Jaroslaw, as Kexi has this right now and the > > > policy > > > as written right now would thus conflict with it. > > > > > > (2) Should we require/allow/forbid publication of the raw data? > > > > > > Publication was suggested by Martin F. Practically, this would have to > > > allow for a certain delay, we can't have public access to live data. > > > Suitable licensing options of the data would probably be CC0 or > > > CC-BY-SA. > > > > > > (3) Should we require a revocation feature? > > > > > > That is, allow the user to "delete" the data they submitted from the > > > server. This was also suggested by Martin F, and is technically possible > > > without compromising anonymity. > > > > > > (4) Should we define limits on how long we store the raw data? > > > > > > Brought up by Bhushan. > > > > > > (5) Should we require an "audit log" feature? > > > > > > Thas is, allow the user to see a detailed record of what has been > > > submitted > > > so far? Martin S suggested this (and it has been meanwhile implemented > > > in > > > KUserFeedback). > > > > > > Not from the previous thread, but from a discussion in Randa: > > > (6) What is the "lower bound" of where we consider this policy to apply? > > > > > > That is, does checking for application updates/news (and possibly > > > tracking > > > that on the server) already count as "telemetry" in this context? See > > > e.g. > > > the current practice in Akregator or KDevelop. > > > > > > > > > Allowing (1) might conflict with (2) allowing publication, unique > > > identification brings us in personal data territory. Publication might > > > also > > > conflict with (3) and (4). > > > > > > So, what's your view on those issues? :) > > > > > > Thanks! > > > Volker signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy - Remaining Questions
El dilluns, 30 d’octubre de 2017, a les 9:56:52 CET, Volker Krause va escriure: > Let's try to finally get this finished :) > > The only remaining blocker is the unique identification used by Kexi. There > was some discussion about this around QtWS, and it seemed like there was > consensus on having a strong policy on this topic would be a good thing for > KDE, as opposed to e.g. turning this into just recommendations, or opening > it up to unique identification. The suggested solution for Kexi was to add > a special exception for it to the "These rules apply to all products > released by KDE." statement of the policy. I'm confused, is that a workaround so that it doesn't apply to Kexi by implying Kexi isn't released by KDE? Cheers, Albert > > That would still leave us with a strong policy on this subject, while > solving the conflict with Kexi's current way of collecting telemetry. Would > that work for everyone? > > Regards, > Volker > > On Thursday, 14 September 2017 00:20:57 CET Volker Krause wrote: > > Hi, > > > > as not everyone follows long threads, let's start again for the remaining > > issues. > > > > https://community.kde.org/Policies/Telemetry_Policy > > > > The following questions were left unanswered in the previous thread (see > > there for the full arguments if needed): > > > > (1) Should we allow opt-in tracking of unique identifiers? > > > > This was requested by Jaroslaw, as Kexi has this right now and the policy > > as written right now would thus conflict with it. > > > > (2) Should we require/allow/forbid publication of the raw data? > > > > Publication was suggested by Martin F. Practically, this would have to > > allow for a certain delay, we can't have public access to live data. > > Suitable licensing options of the data would probably be CC0 or CC-BY-SA. > > > > (3) Should we require a revocation feature? > > > > That is, allow the user to "delete" the data they submitted from the > > server. This was also suggested by Martin F, and is technically possible > > without compromising anonymity. > > > > (4) Should we define limits on how long we store the raw data? > > > > Brought up by Bhushan. > > > > (5) Should we require an "audit log" feature? > > > > Thas is, allow the user to see a detailed record of what has been > > submitted > > so far? Martin S suggested this (and it has been meanwhile implemented in > > KUserFeedback). > > > > Not from the previous thread, but from a discussion in Randa: > > (6) What is the "lower bound" of where we consider this policy to apply? > > > > That is, does checking for application updates/news (and possibly tracking > > that on the server) already count as "telemetry" in this context? See e.g. > > the current practice in Akregator or KDevelop. > > > > > > Allowing (1) might conflict with (2) allowing publication, unique > > identification brings us in personal data territory. Publication might > > also > > conflict with (3) and (4). > > > > So, what's your view on those issues? :) > > > > Thanks! > > Volker
Re: Telemetry Policy - Remaining Questions
On 30 October 2017 at 09:56, Volker Krause wrote: > Let's try to finally get this finished :) > > The only remaining blocker is the unique identification used by Kexi. There > was > some discussion about this around QtWS, and it seemed like there was consensus > on having a strong policy on this topic would be a good thing for KDE, as > opposed to e.g. turning this into just recommendations, or opening it up to > unique identification. The suggested solution for Kexi was to add a special > exception for it to the "These rules apply to all products released by KDE." > statement of the policy. > > That would still leave us with a strong policy on this subject, while solving > the conflict with Kexi's current way of collecting telemetry. Would that work > for everyone? Hello Thanks for pushing this forward Volker. In the meantime I got an inspired idea to behave no different than KDE web browsers do with unique cookies e.g. wrt the KDE Identity accounts. Namely there would be zero logic for IDs in Kexi itself but a cookie feature with its standard behavior. As it's the case, it's opt-in. For now I hope this is technically feasible and the result equivalent of the previous solution if not even more flexible. I would appreciate pointing flaws in my assumption. Timeline for that can be connected to development of sign-in features. Unless there is desire to discuss exceptions for a range of KDE software that implements client side for web technologies maybe there is no need for adding specific exception for Kexi or having it communicated by Kexi itself. I'd like to also mention apparent lack of clarity for the outside user wrt what "products released by KDE" mean. What are the defaults in deployed software is a decision of those who deploy the software; legal modifications are allright. KDE "only" releases the source code. So I would not place such a stamp "These rules apply to all products released by KDE" e.g. in About boxes because this has low info value for the actual user or can truly confuse. I am mentioning this here to emphasize that I see telemetry more as a part of the software deployment and support, not a part of the actual "source code product". Decoupling any logic from the source code is part of that. > On Thursday, 14 September 2017 00:20:57 CET Volker Krause wrote: >> Hi, >> >> as not everyone follows long threads, let's start again for the remaining >> issues. >> >> https://community.kde.org/Policies/Telemetry_Policy >> >> The following questions were left unanswered in the previous thread (see >> there for the full arguments if needed): >> >> (1) Should we allow opt-in tracking of unique identifiers? >> >> This was requested by Jaroslaw, as Kexi has this right now and the policy as >> written right now would thus conflict with it. >> >> (2) Should we require/allow/forbid publication of the raw data? >> >> Publication was suggested by Martin F. Practically, this would have to allow >> for a certain delay, we can't have public access to live data. Suitable >> licensing options of the data would probably be CC0 or CC-BY-SA. >> >> (3) Should we require a revocation feature? >> >> That is, allow the user to "delete" the data they submitted from the server. >> This was also suggested by Martin F, and is technically possible without >> compromising anonymity. >> >> (4) Should we define limits on how long we store the raw data? >> >> Brought up by Bhushan. >> >> (5) Should we require an "audit log" feature? >> >> Thas is, allow the user to see a detailed record of what has been submitted >> so far? Martin S suggested this (and it has been meanwhile implemented in >> KUserFeedback). >> >> Not from the previous thread, but from a discussion in Randa: >> (6) What is the "lower bound" of where we consider this policy to apply? >> >> That is, does checking for application updates/news (and possibly tracking >> that on the server) already count as "telemetry" in this context? See e.g. >> the current practice in Akregator or KDevelop. >> >> >> Allowing (1) might conflict with (2) allowing publication, unique >> identification brings us in personal data territory. Publication might also >> conflict with (3) and (4). >> >> So, what's your view on those issues? :) >> >> Thanks! >> Volker > -- regards, Jaroslaw Staniek KDE: : A world-wide network of software engineers, artists, writers, translators : and facilitators committed to Free Software development - http://kde.org Calligra Suite: : A graphic art and office suite - http://calligra.org Kexi: : A visual database apps builder - http://calligra.org/kexi Qt Certified Specialist: : http://www.linkedin.com/in/jstaniek
Re: Telemetry Policy - Remaining Questions
Let's try to finally get this finished :) The only remaining blocker is the unique identification used by Kexi. There was some discussion about this around QtWS, and it seemed like there was consensus on having a strong policy on this topic would be a good thing for KDE, as opposed to e.g. turning this into just recommendations, or opening it up to unique identification. The suggested solution for Kexi was to add a special exception for it to the "These rules apply to all products released by KDE." statement of the policy. That would still leave us with a strong policy on this subject, while solving the conflict with Kexi's current way of collecting telemetry. Would that work for everyone? Regards, Volker On Thursday, 14 September 2017 00:20:57 CET Volker Krause wrote: > Hi, > > as not everyone follows long threads, let's start again for the remaining > issues. > > https://community.kde.org/Policies/Telemetry_Policy > > The following questions were left unanswered in the previous thread (see > there for the full arguments if needed): > > (1) Should we allow opt-in tracking of unique identifiers? > > This was requested by Jaroslaw, as Kexi has this right now and the policy as > written right now would thus conflict with it. > > (2) Should we require/allow/forbid publication of the raw data? > > Publication was suggested by Martin F. Practically, this would have to allow > for a certain delay, we can't have public access to live data. Suitable > licensing options of the data would probably be CC0 or CC-BY-SA. > > (3) Should we require a revocation feature? > > That is, allow the user to "delete" the data they submitted from the server. > This was also suggested by Martin F, and is technically possible without > compromising anonymity. > > (4) Should we define limits on how long we store the raw data? > > Brought up by Bhushan. > > (5) Should we require an "audit log" feature? > > Thas is, allow the user to see a detailed record of what has been submitted > so far? Martin S suggested this (and it has been meanwhile implemented in > KUserFeedback). > > Not from the previous thread, but from a discussion in Randa: > (6) What is the "lower bound" of where we consider this policy to apply? > > That is, does checking for application updates/news (and possibly tracking > that on the server) already count as "telemetry" in this context? See e.g. > the current practice in Akregator or KDevelop. > > > Allowing (1) might conflict with (2) allowing publication, unique > identification brings us in personal data territory. Publication might also > conflict with (3) and (4). > > So, what's your view on those issues? :) > > Thanks! > Volker signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy - Remaining Questions
On Saturday, 16 September 2017 07:54:48 CEST Nicolás Alvarez wrote: > 2017-09-15 4:27 GMT-03:00 Volker Krause : > > On Friday, 15 September 2017 05:23:44 CEST Nicolás Alvarez wrote: > >> From Mozilla documentation: "So when you say '63% of beta 53 has > >> Firefox set as its default browser', make sure you specify it is 63% > >> of *pings*, since it is only around 46% of clients. (Apparently users > >> with Firefox Beta 53 set as their default browser submit more > >> main-pings than users who don't)." > > > > That is something else though, that's the participation ratio on opt-in. > > Measuring that and determining its bias on the submitted data is indeed a > > challenge, but I don't see how unique ids help with that? > > It has nothing to do with participation ratio; Firefox betas have > opt-out telemetry. > > 63% of Firefox Beta 53 telemetry records (which Mozilla calls "pings") > say it was set as the default browser. If you deduplicate using client > ID, it turns out 46% of distinct Firefox Beta 53 clients had it set as > the default browser. Thus, for some reason users who set it as the > default browser send a more frequent telemetry than those who didn't, > perhaps because they use the browser more. Ah, sorry, I misunderstood this then. Deduplication in should work in this case with the time-based approach too I think. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy - Remaining Questions
2017-09-15 4:27 GMT-03:00 Volker Krause : > On Friday, 15 September 2017 05:23:44 CEST Nicolás Alvarez wrote: >> From Mozilla documentation: "So when you say '63% of beta 53 has >> Firefox set as its default browser', make sure you specify it is 63% >> of *pings*, since it is only around 46% of clients. (Apparently users >> with Firefox Beta 53 set as their default browser submit more >> main-pings than users who don't)." > > That is something else though, that's the participation ratio on opt-in. > Measuring that and determining its bias on the submitted data is indeed a > challenge, but I don't see how unique ids help with that? It has nothing to do with participation ratio; Firefox betas have opt-out telemetry. 63% of Firefox Beta 53 telemetry records (which Mozilla calls "pings") say it was set as the default browser. If you deduplicate using client ID, it turns out 46% of distinct Firefox Beta 53 clients had it set as the default browser. Thus, for some reason users who set it as the default browser send a more frequent telemetry than those who didn't, perhaps because they use the browser more. -- Nicolás
Re: Telemetry Policy - Remaining Questions
On Friday, 15 September 2017 05:23:44 CEST Nicolás Alvarez wrote: > 2017-09-14 15:56 GMT-03:00 Albert Astals Cid : > > El dijous, 14 de setembre de 2017, a les 0:20:57 CEST, Volker Krause va > > > > escriure: > >> The following questions were left unanswered in the previous thread (see > >> there for the full arguments if needed): > >> > >> (1) Should we allow opt-in tracking of unique identifiers? > >> > >> This was requested by Jaroslaw, as Kexi has this right now and the policy > >> as written right now would thus conflict with it. > > > > I missed this, what's the usecase of unique id data? > > Without a unique ID, each time the app sends telemetry, the record is > independent and not correlated to previous records. Generating a > random "client ID" and persisting it in some file in $HOME, and > including it in the uploaded data, lets you calculate statistics per > client, which is more useful than per telemetry record. > > It's hard to know how what percentage of users users have a setting > enabled if we don't have a client ID, since some users may send more > telemetry reports than others (for multiple reasons, including using > the app more often). If we have one, we can avoid double-counting > multiple reports from the same client. That is true is you send telemetry per application start. That's not the only way to do it though. Quoting myself from the earlier thread: > The implementation in KUserFeedback addresses this by fixed interval data > submission. If you then aggregate the received data by the same interval, > you can see e.g. how ratios of application versions develop over time. > > This does have limits of course, you can't distinguish between the same > person using the application every sampling interval, or two people using > it every other interval for example. With a sufficiently long sampling > interval the result should nevertheless be sufficiently accurate I think. and in a bit more detail here: https://mail.kde.org/pipermail/kde-community/ 2017q3/003917.html Ie. I think we can do the de-duplication by other means than unique identification. > From Mozilla documentation: "So when you say '63% of beta 53 has > Firefox set as its default browser', make sure you specify it is 63% > of *pings*, since it is only around 46% of clients. (Apparently users > with Firefox Beta 53 set as their default browser submit more > main-pings than users who don't)." That is something else though, that's the participation ratio on opt-in. Measuring that and determining its bias on the submitted data is indeed a challenge, but I don't see how unique ids help with that? Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy - Remaining Questions
2017-09-14 15:56 GMT-03:00 Albert Astals Cid : > El dijous, 14 de setembre de 2017, a les 0:20:57 CEST, Volker Krause va > escriure: >> The following questions were left unanswered in the previous thread (see >> there for the full arguments if needed): >> >> (1) Should we allow opt-in tracking of unique identifiers? >> >> This was requested by Jaroslaw, as Kexi has this right now and the policy as >> written right now would thus conflict with it. > > I missed this, what's the usecase of unique id data? Without a unique ID, each time the app sends telemetry, the record is independent and not correlated to previous records. Generating a random "client ID" and persisting it in some file in $HOME, and including it in the uploaded data, lets you calculate statistics per client, which is more useful than per telemetry record. It's hard to know how what percentage of users users have a setting enabled if we don't have a client ID, since some users may send more telemetry reports than others (for multiple reasons, including using the app more often). If we have one, we can avoid double-counting multiple reports from the same client. >From Mozilla documentation: "So when you say '63% of beta 53 has Firefox set as its default browser', make sure you specify it is 63% of *pings*, since it is only around 46% of clients. (Apparently users with Firefox Beta 53 set as their default browser submit more main-pings than users who don't)." -- Nicolás
Re: Telemetry Policy - Remaining Questions
On Thursday, 14 September 2017 20:56:49 CEST Albert Astals Cid wrote: > El dijous, 14 de setembre de 2017, a les 0:20:57 CEST, Volker Krause va > escriure: > > (1) Should we allow opt-in tracking of unique identifiers? > > > > This was requested by Jaroslaw, as Kexi has this right now and the policy > > as written right now would thus conflict with it. > > I missed this, what's the usecase of unique id data? IIUC Kexi submits telemetry on each startup (opt-in, of course). That does not allow you to distinguish between one user starting the application multiple times or many users starting it once (which has a lot of implications on how to interpret/weight the data). Look for Jaroslaw's contributions to the previous thread for the full picture. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy - Remaining Questions
El dijous, 14 de setembre de 2017, a les 0:20:57 CEST, Volker Krause va escriure: > Hi, > > as not everyone follows long threads, let's start again for the remaining > issues. > > https://community.kde.org/Policies/Telemetry_Policy > > The following questions were left unanswered in the previous thread (see > there for the full arguments if needed): > > (1) Should we allow opt-in tracking of unique identifiers? > > This was requested by Jaroslaw, as Kexi has this right now and the policy as > written right now would thus conflict with it. I missed this, what's the usecase of unique id data? > > (2) Should we require/allow/forbid publication of the raw data? > > Publication was suggested by Martin F. Practically, this would have to allow > for a certain delay, we can't have public access to live data. Suitable > licensing options of the data would probably be CC0 or CC-BY-SA. I'd say forbid, making a read/write system is much more complex than what we want to do. > > (3) Should we require a revocation feature? > > That is, allow the user to "delete" the data they submitted from the server. > This was also suggested by Martin F, and is technically possible without > compromising anonymity. It'd be nice, but I see that as maybe a second step if we can do it nicely (which calls to make sure we have proper versioning in place so we can update stuff) > > (4) Should we define limits on how long we store the raw data? > > Brought up by Bhushan. If it doesn't identify anyone, i don't see the problem of having raw data (other than raw disk space). > > (5) Should we require an "audit log" feature? > > Thas is, allow the user to see a detailed record of what has been submitted > so far? Martin S suggested this (and it has been meanwhile implemented in > KUserFeedback). I'd say so yes, it's important to be transparent about what we submit. > > Not from the previous thread, but from a discussion in Randa: > (6) What is the "lower bound" of where we consider this policy to apply? > > That is, does checking for application updates/news (and possibly tracking > that on the server) already count as "telemetry" in this context? See e.g. > the current practice in Akregator or KDevelop. I think lower bound is "we store things with the aim to use it", when you check for updates, you can or can not store things (and no a apache log doesn't really count as "storing with the aim to use it"), if we do, it's telemetry, if we don't it's not. Cheers, Albert > > > Allowing (1) might conflict with (2) allowing publication, unique > identification brings us in personal data territory. Publication might also > conflict with (3) and (4). > > So, what's your view on those issues? :) > > Thanks! > Volker
Re: Telemetry Policy - Remaining Questions
On Thursday, 14 September 2017 09:02:07 CEST Adriaan de Groot wrote: > On Wednesday, September 13, 2017 6:20:57 PM EDT Volker Krause wrote: > > as not everyone follows long threads, let's start again for the remaining > > issues. > > Thanks for pulling the threads back together again. > > > (1) Should we allow opt-in tracking of unique identifiers? > > > > This was requested by Jaroslaw, as Kexi has this right now and the policy > > as written right now would thus conflict with it. > > I think it's acceptable if it is (a) opt-in (b) the wording is sufficiently > clear (c) no functionality is dependent on it. This would essentially mean removing the Anonymity section from the current policy draft though. > > (2) Should we require/allow/forbid publication of the raw data? > > Forbidding is easier on the policy and on the admins. Forbidding means we do > not have to a priori figure out what can be published and arm ourselves > against de-anonymisation attacks. Also, I think this could be changed > later: *if* there is no PII in the data, *and* we can publish in a sensible > fashion, then there's nothing for individuals to object to. I'd be fine with not regulating this aspect for now, until we actually have some data to base the decision on. > > (3) Should we require a revocation feature? > > What is the narrative here? (I guess I could go back to the other thread to > look) It's mainly about the control aspect. I.e. giving the user control to delete submitted data again if they change their mind. Nice to have, but IMHO not something that would need to be mandatory, especially since it gets hard to communicate in combination with publishing. > > (4) Should we define limits on how long we store the raw data? > > Yes. Something dependent on how often we publish (even if just publishing > internal collations of data) the aggregated data. > > > (5) Should we require an "audit log" feature? > > > > Thas is, allow the user to see a detailed record of what has been > > submitted > > so far? Martin S suggested this (and it has been meanwhile implemented in > > KUserFeedback). > > Is that based on what the client knows, or what the server knows? This ties > in to (3), above. The current implementation is the client view. A server view could be implemented like (3) indeed, without compromising anonymity. Regards, Volker signature.asc Description: This is a digitally signed message part.
Re: Telemetry Policy - Remaining Questions
2017-09-13 19:20 GMT-03:00 Volker Krause : > (1) Should we allow opt-in tracking of unique identifiers? > > This was requested by Jaroslaw, as Kexi has this right now and the policy as > written right now would thus conflict with it. My view is that we need opt-out telemetry with unique identifiers to get useful conclusions out, but from what I saw in the big thread I know this is an unpopular opinion. > (2) Should we require/allow/forbid publication of the raw data? > > Publication was suggested by Martin F. Practically, this would have to allow > for a certain delay, we can't have public access to live data. Suitable > licensing options of the data would probably be CC0 or CC-BY-SA. FWIW, Mozilla does not publish raw data. Mozilla employees can run custom analyses on raw data (for cases where the public aggregated data isn't enough), but I think even them can't just look at individual records. (Then again, Mozilla raw data contains unique identifiers, which can make their privacy requirements stricter) I also wouldn't want to "require" publication of raw data for practical/technical reasons: until we implement some minimal pseudo-telemetry pings, we don't even know how many active users we have, so we can't estimate what's the total volume of raw data we will end up collecting. It may end up needing extra server resources to store and aggregate. I wouldn't want to also make said giant raw data publicly available. Maybe it's technically possible, but I don't want to already require/promise that we will do it. -- Nicolás
Re: Telemetry Policy - Remaining Questions
On Wednesday, September 13, 2017 6:20:57 PM EDT Volker Krause wrote: > as not everyone follows long threads, let's start again for the remaining > issues. Thanks for pulling the threads back together again. > (1) Should we allow opt-in tracking of unique identifiers? > > This was requested by Jaroslaw, as Kexi has this right now and the policy as > written right now would thus conflict with it. I think it's acceptable if it is (a) opt-in (b) the wording is sufficiently clear (c) no functionality is dependent on it. > (2) Should we require/allow/forbid publication of the raw data? Forbidding is easier on the policy and on the admins. Forbidding means we do not have to a priori figure out what can be published and arm ourselves against de-anonymisation attacks. Also, I think this could be changed later: *if* there is no PII in the data, *and* we can publish in a sensible fashion, then there's nothing for individuals to object to. > (3) Should we require a revocation feature? What is the narrative here? (I guess I could go back to the other thread to look) > (4) Should we define limits on how long we store the raw data? Yes. Something dependent on how often we publish (even if just publishing internal collations of data) the aggregated data. > (5) Should we require an "audit log" feature? > > Thas is, allow the user to see a detailed record of what has been submitted > so far? Martin S suggested this (and it has been meanwhile implemented in > KUserFeedback). Is that based on what the client knows, or what the server knows? This ties in to (3), above. > Not from the previous thread, but from a discussion in Randa: > (6) What is the "lower bound" of where we consider this policy to apply? > > That is, does checking for application updates/news (and possibly tracking > that on the server) already count as "telemetry" in this context? See e.g. > the current practice in Akregator or KDevelop. There's two sides to this: application intent, and what is done on the server- side. Checking for updates has no telemetry attempt, unless there's something arranged server-side. [ade] signature.asc Description: This is a digitally signed message part.
Telemetry Policy - Remaining Questions
Hi, as not everyone follows long threads, let's start again for the remaining issues. https://community.kde.org/Policies/Telemetry_Policy The following questions were left unanswered in the previous thread (see there for the full arguments if needed): (1) Should we allow opt-in tracking of unique identifiers? This was requested by Jaroslaw, as Kexi has this right now and the policy as written right now would thus conflict with it. (2) Should we require/allow/forbid publication of the raw data? Publication was suggested by Martin F. Practically, this would have to allow for a certain delay, we can't have public access to live data. Suitable licensing options of the data would probably be CC0 or CC-BY-SA. (3) Should we require a revocation feature? That is, allow the user to "delete" the data they submitted from the server. This was also suggested by Martin F, and is technically possible without compromising anonymity. (4) Should we define limits on how long we store the raw data? Brought up by Bhushan. (5) Should we require an "audit log" feature? Thas is, allow the user to see a detailed record of what has been submitted so far? Martin S suggested this (and it has been meanwhile implemented in KUserFeedback). Not from the previous thread, but from a discussion in Randa: (6) What is the "lower bound" of where we consider this policy to apply? That is, does checking for application updates/news (and possibly tracking that on the server) already count as "telemetry" in this context? See e.g. the current practice in Akregator or KDevelop. Allowing (1) might conflict with (2) allowing publication, unique identification brings us in personal data territory. Publication might also conflict with (3) and (4). So, what's your view on those issues? :) Thanks! Volker signature.asc Description: This is a digitally signed message part.
