Telemetry Policy

[Volker Krause]

On Monday, 14 August 2017 14:16:12 CEST Bhushan Shah wrote:
> Hello Volker,
> 
> First of all thanks for working on this topic, I've some comments I
> would like to add.
> 
> On Sun, Aug 13, 2017 at 11:47:28AM +0200, Volker Krause wrote:
> > ## Control
> > 
> > We give the user full control over what data they want to share with KDE.
> > In particular:
> > - application telemetry is always opt-in, that is off by default
> > - application telemetry settings can be changed at any time, and are
> > provided as prominent in the application interface as other application
> > settings - applications honor system-wide telemetry settings where they
> > exist (global "kill switch")
> > - we provide detailed documentation about how to control the application
> > telemetry system
> 
> This is kind of technical point but here it goes,
> 
> I think we should include the point in policy that, this data is stored
> and transferred in encrypted format only, on both user's machine and the
> KDE's server. This prevents Man in middle attacks and also prevents
> unwanted/unauthorized access to user's data by third party application
> on local machine.
> 
> So how I think this should happen is,
> 
> -> Application starts
> -> Writes encrypted data to storage file
> -> Encrypted data is transferred to KDE server
> -> They are decrypted on KDE server when needed
> 
> > We will provide a designated contact point for users who have concerns
> > about the data they have shared with KDE. While we are willing to delete
> > data a user no longer wants to have shared, it should be understood that
> > the below rules are designed to make identification of data of a specific
> > user impossible, and thus a deletion request impractical.
> 
> Can we have policy on how long we can store data? It's just random idea
> but I think it makes sense to tell users that after X period of time
> your data will be invalidated?
> 
> This gives the "part-solution" to problem where user wants to delete
> their shared data.

Good point. I'm unsure on what to pick as a suitable timeframe though. It's 
hard to give a specific time right now, we don't know yet how quickly updates 
of our software are deployed, which is what is going to determine the latency 
of getting the data we want. For that question alone we are looking at years I 
think. Maybe this could be worded as "data is only kept as long as the purpose 
of the data collection hasn't been achieved yet", ie. as soon as we have the 
answer we were looking for we delete the raw data.

The bigger problem however is that this conflicts with publishing the data 
under a free license. At this point we lose any control to enforce data 
retention limits.

> > ## Compliance
> > 
> > KDE only releases products capable of acquiring telemetry data if
> > compliance with these rules has been established by a public review on
> > [kde-core-devel| kde-community]@kde.org from at least two reviewers. The
> > review has to be repeated for every release if changes have been made to
> > how/what data is collected.
> 
> In addition to kde-community/kde-core-devel there should be public
> webpage at e.g. https://telemetry.kde.org where we explain what
> application collects what data and where it is used for clear
> transperancy.

A global registry of telemetry enabled KDE apps sounds like a good idea, 
basically documenting the review results in e.g. a wiki. This would also make 
it easier to spot problematic combinations or data tracked multiple times (say 
KDevelop tracking stuff the Katepart already tracks, and/or each of them 
tracking data that in combination might enable fingerprinting).

Regards,
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/20170814/2c2a9e00/attachment.sig>