Telemetry Policy - Remaining Questions

Tue Oct 31 10:04:36 GMT 2017

On Monday, 30 October 2017 11:27:58 CET Jaroslaw Staniek wrote:
> On 30 October 2017 at 09:56, Volker Krause <vkrause at kde.org> wrote:
> > 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?
> 
> Hello
> Thanks for pushing this forward Volker.
> In the meantime I got an inspired idea to behave no different than KDE
> web browsers do with unique cookies e.g. wrt the KDE Identity
> accounts.
> Namely there would be zero logic for IDs in Kexi itself but a cookie
> feature with its standard behavior. As it's the case, it's opt-in.
> For now I hope this is technically feasible and the result equivalent
> of the previous solution if not even more flexible.
> I would appreciate pointing flaws in my assumption. Timeline for that
> can be connected to development of sign-in features.
> 
> Unless there is desire to discuss exceptions for a range of KDE
> software that implements client side for web technologies maybe there
> is no need for adding specific exception for Kexi or having it
> communicated by Kexi itself.

We can obviously drop the exception as soon as it's no longer necessary. I'm 
not sure I fully understand the proposed implementation, but I do see local 
storage (via cookies or otherwise) as a way to address some of the unique 
identification use-cases, such as aggregating data from the same user.

The comparison to KDE Identity is a bit confusing though, as the objective of 
that is unique identification for authorizing access, which inherently conflicts 
with anonymity.

> I'd like to also mention apparent lack of clarity for the outside user
> wrt what "products released by KDE" mean. What are the defaults in
> deployed software is a decision of those who deploy the software;
> legal modifications are allright. KDE "only" releases the source code.
> So I would not place such a stamp "These rules apply to all products
> released by KDE" e.g. in About boxes because this has low info value
> for the actual user or can truly confuse.
> I am mentioning this here to emphasize that I see telemetry more as a
> part of the software deployment and support, not a part of the actual
> "source code product". Decoupling any logic from the source code is
> part of that.

Right, we cannot ultimately enforce this due to the free software licenses. 
While we can only ask external distributors to follow the same rules, we are 
also a distributor in a number of cases (Windows, Android, Linux app bundles, 
Neon, etc), and can apply the rules there too.

I agree that there is a communication/marketing aspect to this as well, and a 
policy document is not the right tool for that, especially when things get 
complicated.

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/bd845ab9/attachment.sig>