Fedora considers "privacy-preserving" telemetry [LWN.net]

Fedora considers "privacy-preserving" telemetry

Posted Jul 8, 2023 20:42 UTC (Sat) by NYKevin (subscriber, #129325)
In reply to: Fedora considers "privacy-preserving" telemetry by eduperez
Parent article: Fedora considers "privacy-preserving" telemetry

This is much broader than you think it is. According to GDPR Article 4(1):

> ‘personal data’ means any information relating to an identified or identifiable natural person (‘data subject’); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person;

In other words: If it is *possible* to figure out which human a given piece of data relates to, then the data is "personal" data. So if I know that somebody has a mouse with three buttons, that's not personal data. But if I know that user #12345 has a mouse with three buttons, that is personal data (assuming that it is possible to look up user #12345 in some database somewhere).

to post comments

Fedora considers "privacy-preserving" telemetry

Posted Jul 8, 2023 20:53 UTC (Sat) by wjt (subscriber, #56250) [Link] (2 responses)

In the metrics system that is being proposed here, metrics are associated not with a user ID, but only with an identifier for the originally-installed OS image, which is the same across a large number of devices. (This OS image ID is an Endless OS-specific concept; I don't know if an equivalent channel ID would be used on Fedora but running the current implementation on Fedora would associate all events with the image ID "unknown".)

So, in your example, there would be no database in which to look up user #12345, and no "user #12345" identifier on the three-button-mouse data point.

Fedora considers "privacy-preserving" telemetry

Posted Jul 8, 2023 23:56 UTC (Sat) by NYKevin (subscriber, #129325) [Link] (1 responses)

That is probably fine, but you still have to be careful. It is very easy to accidentally store personal data without intending to do so.

As an example, let's say that you have some firewall that logs incoming requests for a short time, and captures the source IP address as well as the exact time of the user's submission. Your database stores a timestamp and whatever telemetry metrics are captured. The IP address is an "online identifier," and you can time-correlate the database with the firewall log, so the whole thing is "personal data." The fact that you separate the telemetry metrics from the IP address, and store them in independent systems, is called "pseudonymization":

> ‘pseudonymisation’ means the processing of personal data in such a manner that the personal data can no longer be attributed to a specific data subject without the use of additional information, provided that such additional information is kept separately and is subject to technical and organisational measures to ensure that the personal data are not attributed to an identified or identifiable natural person;

Pseudonymous data is still considered personal data, at least until you delete the firewall log, or until you delete enough data that it is no longer possible to associate your telemetry metrics with an IP address (e.g. delete the timestamps from either the database or the firewall log). Pseudonymization is recommended as one possible practice to improve compliance with article 6, but it does not relieve you of any other obligations under GDPR, including the lawful basis requirement.

Fedora considers "privacy-preserving" telemetry

Posted Jul 9, 2023 9:21 UTC (Sun) by wjt (subscriber, #56250) [Link]

Each event is stored with a timestamp of when it occured, but not when it was submitted. They are buffered on the client and submitted in batches, and split apart before storing. So the events can't be correlated back to the load balancer logs to link them to an IP address. (I'm not sure what the load balancer logs – thanks for the idea to go and check this!)

It's actually quite annoying to not have the submission time together with each event because it makes it very hard to figure out the event submission latency. (After how many days in July can we expect the data on the server for June to be "mostly complete"?) It would be useful to store a truncated received-at timestamp on the events, but only if it is sufficiently vague to not allow associating events with one another, or with the logs of the upload.