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