Telemetry Policy - Remaining Questions

[Volker Krause]

On Tuesday, 3 April 2018 18:16:10 CEST Jaroslaw Staniek wrote:
> On 3 April 2018 at 10:42, Volker Krause <vkrause at kde.org> wrote:
> > > > https://community.kde.org/Talk:Policies/Telemetry_Policy#
> > > 
> > > Thank you! Volker is probably best equipped to answer these.
> > 
> > I've commented on all points on the talk page now I think.
> 
> ​Thanks Volker,
> I must have missed the info that the concepts of intervals have been
> documented two weeks ago. Apologies.
> The concept has potential to change the game and convince people to
> "invest" in telemetry. However maybe a pilot phase with an app or two would
> be more in place to see the results. Policies would then follow reality
> even more.

The agreement at Akademy 2017 was to not do that without regulation, which is 
what got us here.

> It would be good to consider picking larger projects, e.g. part of KDE
> Applications release or Plasma itself, and with maintainers able to discuss
> during the Akademy. 

Right. That's what happened last year, that's why we are having the policy 
draft and this discussion.

> KEXI is just not in this group. Also, based on my
> knowledge, statistical KEXI users would not even have access to the KDE
> "kill switch" since Plasma is rarely used by them.

That's why the policy says "[...] where they exist.". Obviously if you are 
running on a system without such settings there is nothing you can do, so you 
just follow per-application settings there.

> In particular there is a chance that if pilot apps get released with the
> KUserFeedback telemetry, the challenge of handling access to the raw
> anonymized data would get addressed, since we would know why there is the
> interest in data and what is the purpose of collecting it. In the
> post-Akademy thread Ingo Klöcker has once provided interesting general
> observation, even it it refers to German law. Once the data "leaks" outside
> of the telemetry team (say telemetry team within a single app project), to
> people not even affiliated with the project, it is no longer possible to
> expect it (the data) is used in a way compliant with the Policy, and
> only for the needs of "legal" telemetry. KDE would still be responsible for
> all the uses of the data. Coming year stronger law comes to Poland too.

That's where the motivation to make the result "data" rather than "personal 
data" comes from. Then leaking/sharing/etc is not a problem. As soon as there 
is anything in there considered "personal data" (as defined by data protection 
regulation), you are right, we need access control, data removal procedures, 
limited storage time, etc, and come into scope of GDPR & friends. That is why 
allowing a unique identifier makes such a big difference to all of this.

> So making it harder to download the data and increasing level of its
> aggregation would make sense then to me. Long-term idea would also
> be giving access to an analysis tool and the results instead of to the data
> on which the tool operates.
> 
> 
> And then in the meantime folks like the Promo team have potential to work
> on proper messaging to improve the number users understanding and accepting
> telemetry. My example follows here. On more "human" level: KEXI offering a
> telemetry "for KDE" that is still seen as a "desktop" (regardless of a
> reason) than "for KEXI Team" would be potentially a disadvantage for the
> app's project itself. KDE contributors and fans understand the idea of an
> organization. I've learned from my group that for everyone else "Help
> improve Visual Studio" type of message tends convince more than more
> questionable "Help Microsoft" ;)

How to communicate things to the user is an important topic, and probably has 
no unified answer. I indeed can see that being different for say KEXI and 
Plasma. However, I do think it's useful for this to be able to point to strong 
regulation that ensures privacy, control and transparency.

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