Telemetry Policy - Remaining Questions

Volker Krause vkrause at kde.org
Mon Oct 30 08:56:52 GMT 2017


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

-------------- 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/20171030/75db86b7/attachment.sig>


More information about the kde-community mailing list