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