Re: Telemetry Policy - Remaining Questions

[Jaroslaw Staniek]

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

[Lydia Pintscher]

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

[Lydia Pintscher]

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

[Jaroslaw Staniek]

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=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 

Re: Telemetry Policy - Remaining Questions

[Ben Cooksley]

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=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 

Re: Telemetry Policy - Remaining Questions

[Volker Krause]

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

[Jaroslaw Staniek]

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=
> > > 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

[Jaroslaw Staniek]

​​


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=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 

Re: Telemetry Policy - Remaining Questions

[Volker Krause]

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=
> > 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

[Ben Cooksley]

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=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

[Jaroslaw Staniek]

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=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

[Lydia Pintscher]

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=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

[Jaroslaw Staniek]

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=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

[Lydia Pintscher]

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

[Volker Krause]

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

[Jaroslaw Staniek]

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

[Sebastian Kügler]

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

[Volker Krause]

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 

Re: Telemetry Policy - Remaining Questions

[Volker Krause]

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

[Albert Astals Cid]

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

[Jaroslaw Staniek]

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

[Volker Krause]

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

[Volker Krause]

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

[Nicolás Alvarez]

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

[Nicolás Alvarez]

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

[Volker Krause]

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

[Albert Astals Cid]

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

[Volker Krause]

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

[Nicolás Alvarez]

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

[Adriaan de Groot]

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.