Telemetry Policy - Remaining Questions

[Volker Krause]

On Monday, 30 October 2017 21:24:59 CET Albert Astals Cid wrote:
> El dilluns, 30 d’octubre de 2017, a les 9:56:52 CET, Volker Krause va
> 
> escriure:
> > 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.
> 
> I'm confused, is that a workaround so that it doesn't apply to Kexi by
> implying Kexi isn't released by KDE?

That sounds a bit convoluted to me, I was more thinking about making it a 
direct exception to the policy, e.g. like this:

"These rules apply to all products released by KDE (with the exception of 
Kexi, which uses a telemetry system predating this policy)."

Regards,
Volker

> > 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/20171031/85864e1f/attachment.sig>