GDPR Compliance Gap in DeviceUniqueId

[grokys]

We were recently notified of a GDPR issue in the way we store DeviceUniqueId:

https://github.com/AvaloniaUI/Avalonia.BuildServices/blame/777f975b0a0cecf0311273711d56697212c558c0/BuildTask/TelemetryPayload.cs#L222

We need to look into it in more depth, but an initial AI-generated report says:

The inputs are low-entropy and guessable. MachineName, UserName, and OSVersion.Platform are all:

Predictable or enumerable values
Often available from other sources (Active Directory, logs, network scans)
Not secret — they're not cryptographic keys
This makes the hash vulnerable to pre-image attacks via brute force or dictionary lookup. An attacker (or regulator) could enumerate likely ?> combinations and reverse it, especially on Windows where OSVersion.Platform is almost always Win32NT.
Without a secret salt, this is closer to obfuscation than true pseudonymisation.

We're investigating the issue and will remedy and release a fix.

[grokys]

This may be a country-specific thing:

Where a German DPA might insist that hashed identifiers remain personal data in essentially all cases, AKI’s posture tracks the EDPB’s Opinion 28/2024 on anonymisation more closely, which accepts that sufficiently hashed and aggregated data with no realistic re-identification path can fall outside the GDPR entirely. Your privacy policy already leans into this exact position when it says telemetry data “is anonymised through hashing and does not include personal information” and that “because this data is anonymous, it falls outside the scope of personal data regulation.” That is a defensible Estonian reading. It would be a harder sell in Munich.

So the Copilot instructions are correct to be cautious, but rule 2’s “treat hashed values as still being personal data” is a German-flavoured overstatement for your context. The Estonian reality is that if you hash high-entropy inputs with SHA-256, strip the combinations that enable re-identification, and document the anonymisation approach, AKI will likely treat the dataset as anonymous and therefore outside GDPR scope. I’d soften that rule to something like “treat hashed values with caution during design; the combined payload must not enable re-identification through field correlation,” which keeps the engineering discipline without committing you to a legal position stricter than your own privacy policy takes.

We will contact the Andmekaitse Inspektsioon for further guidance and report the findings here.

[grokys]

We have contacted Andmekaitse Inspektsioon and should receive a reply within 15 days.

[grokys]

Opened #5 with GitHub Copilot instructions which should help us stay ahead of issues like this.

[grokys]

We received a reply from the Andmekaitse Inspektsioon but it wasn't very useful - it basically told us that we had to evaluate the usage ourselves. We're in the process of re-evaluating it.