Telemetry Policy

[Volker Krause]

On Monday, 14 August 2017 22:40:28 CEST Ingo Klöcker wrote:
> On Monday 14 August 2017 19:28:06 Volker Krause wrote:
> > On Monday, 14 August 2017 14:16:12 CEST Bhushan Shah wrote:
> > > 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.
> 
> For most purposes (e.g. which parts of the software are used how often)
> it should be possible to aggregate the raw data monthly and then throw
> away 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.
> 
> With respect to the considerations to make the collected raw data public
> I ask you to contact a data protection officer
> (Datenschutzbeauftragte/r) to get her/his opinion. Quoting
> https://en.wikipedia.org/wiki/General_Data_Protection_Regulation: "Valid
> consent must be explicit for data collected and the purposes data is
> used for (Article 7; defined in Article 4)." Since you cannot state the
> purposes the data is used for (because once made public it could be used
> for any purpose), I cannot see how you could get the users' consent for
> this.

That is true, as long as we deal with personal data. When we discussed this 
for the deployment in GammaRay regarding GDPR compliance we came to conclusion 
that the collected data is not personal data, which makes this considerably 
easier. 

For illustration, the following JSON data is what a random GammaRay instance 
on this machine would submit right now if I would opt-in to the maximum 
telemetry level:

{
    "applicationVersion": {  "value": "2.8.50"  },
    "compiler": { "type": "GCC",  "version": "7.1" },
    "opengl": {
        "glslVersion": "1.30",
        "renderer": "Haswell Mobile ",
        "type": "GL",
        "vendor": "Intel",
        "vendorVersion": "Mesa 17.1.4",
        "version": "3.0"
    },
    "platform": {
        "os": "linux",
        "version": "opensuse-tumbleweed"
    },
    "qtVersion": { "value": "5.9.2" },
    "startCount": { "value": 34 },
    "toolRatio": {
        "objectinspector": { "property": 0.7619047619047619 },
        "quickinspector": { "property": 0.23809523809523808 }
    },
    "usageTime": { "value": 12113  }
}

The server would add a timestamp to that. That's also the level of detail we 
are looking at for telemetry in KDE I think.

The policy kinda implies that we do not want to track anything that common 
sense or laws/regulations would classify as personal data, I'll make that 
explicit to be sure.

The only personal data item we get in touch then is the IP address I think, 
therefore the early separation from telemetry data is crucial. Then the 
telemetry data is just "non-personal" data, and GDPR etc wouldn't apply (in my 
understanding, IANAL).

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