View source for Talk:Policies/Telemetry Policy

Jump to: navigation, search

Contents

Thread titleRepliesLast modified
Making compliance OPT-IN108:32, 3 April 2018
Replacement for the OPT-IN ID108:29, 3 April 2018
Strong requirement to share the data widely108:27, 3 April 2018
Is OPT-IN ID (from KEXI) understood?107:10, 3 April 2018
Privacy as right to remove data107:03, 3 April 2018
First page
First page
Next page
Next page
Last page
Last page

Making compliance OPT-IN

Possible approach that needs to be discussed: making telemetry compliance for KDE projects OPT-IN so the whole process is incremental.

For now not many projects seem to be actively interested in the topic and even if there was voting, results can be anything, given many would just do not care.

19:56, 2 April 2018

Replacement for the OPT-IN ID

Replacements for the OPT-IN ID, if they exist, need to be explained and discussed so there's a chance for agreement.

Lydia is right that "​We need the data and we need the policy in place" but we need the data that *means* something useful for each project, quality can't be an order of magnitude inferior to the OPT-IN ID.

20:03, 2 April 2018

The FAQ on https://api.kde.org/frameworks/kuserfeedback/html/index.html explains how KUserFeedback works without unique identification.

08:29, 3 April 2018
 

Strong requirement to share the data widely

You do not have permission to edit this page, for the following reason:

The action you have requested is limited to users in one of the groups: Users, Administrators, trusted, KDEDevelopers.


You can view and copy the source of this page.

 

Return to Thread:Talk:Policies/Telemetry Policy/Strong requirement.

Yes, de-facto publishing the data is indeed the desired result (see e.g. https://mail.kde.org/pipermail/kde-community/2017q3/003808.html in the previous discussion).

There is one reason for this: transparency. This however only works if the data is free of any personal information or unique identifiers. Ie. the idea is to only track things that we are comfortable making public entirely.

08:27, 3 April 2018
 

Is OPT-IN ID (from KEXI) understood?

Referring to version https://community.kde.org/index.php?title=Policies/Telemetry_Policy&oldid=78057

There seems to be emphasis on assuring that OPT-IN unique identification (like in KEXI, OPT-IN ID in short below) is never used by compliant KDE projects. I'd like to understand a specific measure that shows opinion of our user base and our contributors. That these groups A) understood the OPT-IN ID and its scope correctly and B) the OPT-IN ID is rejected as something negative (explanation needed backed by facts)

To be able to move closer to the answer I'd like to know if OPT-IN is seen in conflict with this point or not:

ANONIMITY "We do not transmit data that could be used to identify a specific user. In particular: [..] we will not use any unique device, installation or user id"

Disclaimer: From the very beginning I started to use telemetry in KEXI with no intent to be in conflict with such policy. The ID is not based on device properties, OS properties or user identity. It's a big random number, the same technique as used by web application in cookies. Reason to have it is ONLY to compute statistics based on unique users per given pattern (such as users of a "1024" screen resolution). That's the same measurement as number of unique web visitors.

19:47, 2 April 2018

It does not matter how exactly the unique user id is generated, the relevant aspect is that it identifies a user.

Whether or not using such an id is acceptable depends on what we want (my understanding of the discussion at Akademy 2017 was that we do not want this), and the legal implications (GDPR even considers IP addresses personal data, so I assume unique ids are also moving us from "data" to "personal data" there).

07:10, 3 April 2018
 

Privacy as right to remove data

Privacy as "right to remove data" is not supported by the proposal. This is true as long as no OPT-IN ID is offered to users that want it.

22:58, 2 April 2018

Data removal can be implemented without unique user identification as outlined in https://mail.kde.org/pipermail/kde-community/2017q3/003820.html already.

07:03, 3 April 2018
 
First page
First page
Next page
Next page
Last page
Last page

This page was last edited on 2 April 2018, at 19:47. Content is available under Creative Commons License SA 4.0 unless otherwise noted.