On Thu, Nov 9, 2017 at 1:11 PM, Nathaniel McCallum
Turning it into a hash doesn't solve the tracking problem. It
prevents the attacker from knowing a list of serial numbers. I suspect
keeping hashes of identifying information will likely cause
What is the nature of the tracking problem? A single entry for a
single machine is not tracking to me. Tracking requires at least two
points in space-time. What's being stored by the Fedora Project? IP,
Geolocation, date and time? Those are the things I associate with
tracking more than a serial number or a hash of a serial number.
Let's say you don't store serial number or a hash, but you do store
model information, date/time, and an IP address. If there's no
mechanism to avoid duplicate entries, you've got a bigger tracking
problem the less common that particular model is. More models will
make the data noisy. But if it's a sufficiently rare model, the
duplicate entries can be assumed to be representing just a few
distinct machines or even just one machine, and now you can track a
person even if you don't have any serial number or hashing.
So I think necessarily you need a way to eliminate duplicates from
entering the data set. Some way of anonymizing the entry in the Fedora
Project's data, but also a way to track duplicates.
How about two different data sets stored by the Fedora Project?
Dataset 1 contains only the hash of the serial number of the device.
If that hash is not present in dataset 1, then sanitized device data
is added to dataset 2. If the hash is found in dataset 1, then it's
not added to dataset 2. But there is no correlation between dataset 1
and dataset 2?