Talk:Policies/Telemetry Policy

Jump to: navigation, search


Thread titleRepliesLast modified
Web applications and cookies108:37, 3 April 2018
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

Web applications and cookies

Question about disallowing OPT-IN ID and allowing web application technology with cookies (or even with stored accounts). Explanation needed how these are different wrt the ANONIMITY requirement. Among them I see KDE identity implementation with its web interface, it uses the ID behavior, which in turn can't even be OPT-IN - either you share the ID or can't use that KDE project. Any KDE projects like wikis or educational sites are potentially in this group too, they all tend to offer accounts for well-defined and known and accepted user convenience.

19:50, 2 April 2018

The policy does not imply that everything else is already perfect ;-)

Also, some applications might need user identification for valid reasons (anything involving communication or authorship attribution for example), telemetry is not such an application though.

08:37, 3 April 2018

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 explains how KUserFeedback works without unique identification.

08:29, 3 April 2018

Strong requirement to share the data widely

This is a strong requirement: "In order to enable reviewing of the data, every KDE contributor with a developer account will have access to all telemetry data gathered by any KDE product."

I miss a reason for this precedence exactly for telemetry data and not other categories of KDE's data.

For me it's almost "the data is public", given the policy of becoming a contributor (contributors are not identified in any reliable way). Requiring disclosing the data this way can be called a factor limiting freedom of KDE projects compared to other FOSS projects. It's clear to me that even GNU projects do not use such policy to share project's kind-of-internal data they to so relatively public groups.

It's also a matter of limiting risks.

I would propose alternative: applying for access to the data, with a simple and clear rules codified. Minimum: give a reason and level of affiliation with the project. Project members would be involved in the approval but would not be the only ones that "approve".

Limiting number of people accessing the data would be increase confidence within the user groups and would also help to track the access in case of accidents.

20:15, 2 April 2018

Yes, de-facto publishing the data is indeed the desired result (see e.g. 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

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 already.

07:03, 3 April 2018

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.