On Sunday, 13 August 2017 12:56:27 CEST Martin Flöser wrote: > Am 2017-08-13 11:47, schrieb Volker Krause: > > Hi, > > > > during the KUserFeedback BoF at Akademy there was quite some interest > > in > > collecting telemetry data in KDE applications. But before actually > > implementing that we agreed to define the rules under which we would > > want to > > do that. I've tried to put the input we collected during Akademy into > > proper > > wording below. What do you think? Did I miss anything? > > To me it looks good! > > I have some additional requests: > * the collected data must be made available to the public (mostly > thinking of research institutes here)
This has come up before, not in the context of 3rd parties like research organisations, but for transparency towards our users. There is a practical limitation of making raw data available live, as that would create a publicly readable and writable system, with similar abuse potential as e.g. pastebin. But I don't think that is the requirement you have in mind here, it's more about sharing the raw data after review/eventually, right? In the currently envisioned setup anyone with a KDE contributor account would have access, so the remaining questions would be about the practicalities and processes to review and release the data to the general public I think. > * data must be made available under a CC license (CC0?) Interesting point, I hadn't thought about that yet :) Can we even license the data, as we didn't create it? Do we need to ask our users to license their telemetry contributions? > * maybe allow the user to delete the dataset again (difficult as that > conflicts with making the data public and would require authentication > which is the opposite to anonymity). As discussed on kde-core-devel a while ago, I think this would be doable technically, without compromising anonymity. The server would generate a unique unpredictable token for each submitted sample and return that to the client. The client collects those and can use them as part of a deletion request. However, this does only work as long as we have full control over the data, we can't recall data that has already been extracted from our systems. So I think this conflicts with the first two requirements you mentioned. How do we want to resolve that? Regards, Volker > > # Telemetry Policy Draft > > > > Application telemetry data can be a valuable tool for tailoring our > > products > > to the needs of our users. The following rules define how KDE collects > > and > > uses such application telemetry data. As privacy is of utmost > > importance to > > us, the general rule of thumb is to err on the side of caution here. > > Privacy > > always trumps any need for telemetry data, no matter how legitimate. > > > > These rules apply to all products released by KDE. > > > > ## Transparency > > > > We provide detailed information about the data that is going to be > > shared, in > > a way that: > > - is easy to understand > > - is precise and complete > > - is available locally without network connectivity > > > > Any changes or additions to the telemetry functionality of an > > application will > > be highlighted in the corresponding release announcement. > > > > ## 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 > > > > In order to ensure control over the data after it has been shared with > > KDE, > > applications will only transmit this data to KDE servers, that is > > servers > > under the full control of the KDE sysadmin team. > > > > 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. > > > > ## Anonymity > > > > 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 > > - data is stripped of any unnecessary detail and downsampled > > appropriately > > before sharing to avoid fingerprinting > > - network addresses (which are exposed inevitably as part of the data > > transmission) are not stored together with the telemetry data, and must > > only > > be stored or used to the extend necessary for abuse counter-measures > > > > ## Minimalism > > > > We only track the bare minimum of data necessary to answer specific > > questions, > > we do not collect data preemptively or for exploratory research. In > > particular, this means: > > - collected data must have a clear purpose > > - data is downsampled to the maximum extend possible at the source > > - relevant correlations between individual bits of data should be > > computed at > > the source whenever possible > > - data collection is stopped once corresponding question has been > > answered > > > > ## Privacy > > > > We will never transmit anything containing user content, or even just > > hints at > > possible user content such as e.g. file names, URLs, etc. > > > > We will only ever track: > > - system information that are specific to the installation/environment, > > but > > independent of how the application/machine/installation is actually > > used > > - statistical usage data of an installation/application > > > > ## 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. > > > > Received data is regularly reviewed for violations of these rules, in > > particular for data that is prone to fingerprinting. Should such > > violations be > > found, the affected data will be deleted, and data recording will be > > suspended > > until compliance with these rules has been established again. 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.
signature.asc
Description: This is a digitally signed message part.