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]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20170914/75100631/attachment.sig>