Telemetry Policy - Remaining Questions

Volker Krause vkrause at kde.org
Thu Sep 14 09:41:39 BST 2017


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


More information about the kde-community mailing list