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]
signature.asc
Description: This is a digitally signed message part.