Data-protection exposure for publishing derived account linkage

[Erilla]

Question

Split out of the terms research (#5), which found the larger legal exposure may not be Blizzard at all.

Blizzard's Terms of Use make us warrant GDPR compliance and indemnify Blizzard without cap, while forbidding us from acting outside CCPA "Service Provider" status. Generating and publishing a novel inference — "these characters share an owner", derived from data the owner did not publish and may have deliberately hidden — arguably steps outside Service Provider status, and is arguably the creation of new personal data rather than the processing of existing personal data.

Establish the obligations that actually attach:

• Is a character-to-account linkage inference personal data under GDPR, given a WoW character is pseudonymous but frequently identifiable in practice? Does publishing it constitute profiling?
• What lawful basis could a public, anonymous-access site rely on for creating and publishing it? If the answer is legitimate interests, what does the balancing test look like when the data subject has demonstrably taken steps to hide the link?
• What rights follow — access, rectification, erasure, objection — and can a site with no accounts and no contact details for its subjects honour them? SlashWho's current suppression route is a public GitHub issue template.
• Does the existing upstream Blizzard opt-out ("Share my game data with community developers") discharge any of this, or is it irrelevant to our own obligations?
• Where does the operator's own jurisdiction sit, and does that change the answer?

This blocks the privacy stance (#8) — deciding where SlashWho stands ethically without knowing what it is legally obliged to do would be deciding blind.

Research, not legal advice. Cite primary sources — the regulation text, ICO or equivalent regulator guidance — and be explicit about where the honest answer is "this needs a lawyer, and here is the specific question to put to one".

[Erilla]

Resolution

Full findings: docs/research/data-protection-exposure.md on the throwaway branch research/data-protection-exposure (~27,000 words).

Research, not legal advice — but the load-bearing conclusions rest on primary sources rather than inference.

The pseudonymity question resolves against us

A character name is personal data. Four independent routes converge, and the decisive one is the ICO's own guidance: a username "is still sufficient to identify them … regardless of whether it is possible to link the 'online' identity with a 'real world' named individual." Recital 26's "either by the controller or by another person", Nowak and Breyer, and the ICO's motivated-intruder test — which explicitly names estranged partners and stalkers — all point the same way.

The law moved since anyone last looked at this

DUAA 2025 commenced on 5 February and 19 June 2026:

• The Article 14 disproportionate-effort exemption is now 14(5)(e), with a new mandatory public-notice duty at 14(7).
• New Articles 84A/84B close the archiving shelter that permanent snapshots would otherwise have leaned on.
• DPA 2018 s.164A (in force 19 June 2026) creates a statutory complaint-handling duty requiring a form completable "electronically and by other means".

Separately, the Upper Tribunal reversed the Clearview jurisdiction ruling in October 2025, reading Article 3(2)(b) "monitoring" very broadly.

Create, store, publish come out differently

Publication is the weak link: it fails necessity most clearly, triggers Article 17(2), and is where the risk concentrates.

Where SlashWho lands

SlashWho would be an independent UK GDPR controller for every player worldwide, with no exemption available and Article 6(1)(f) the only candidate lawful basis. Thirteen prerequisites follow. Eleven are tractable engineering and paperwork. Two are not: the balancing test and the necessity test both fail for the cohort who deliberately hid the link. Recital 47 puts the subject's interests on top where they "do not reasonably expect further processing", and a hidden-owner flag is documented evidence of exactly that contrary expectation.

Also surfaced

• DPA 2018 s.171 (re-identification) is a criminal offence whose description fits this feature almost exactly. The finding is that it probably escapes only on a drafting technicality, and appears never to have been used in eight years.
• There is no turnover-based fine cap for an individual (s.157(5)(b)).
• No regulator anywhere has decided a case on a pseudonym-to-identity site — a genuine gap, cutting both ways.

Bottom line

Enforcement probability is genuinely low. But publication is irreversible while the exposure is personal and uncapped, and the two consequences that matter — an Article 82 claim and Blizzard's uncapped indemnity — do not require the ICO to act at all. One complaint from one player who hid their alts for a reason the operator cannot see is sufficient.

The mitigations that actually move the risk are not documentary:

1. Do not publish inferred-only linkage for players who signalled a contrary preference — and that signal is detectable.
2. Do not let those pages be indexed.

That is a direct input to the privacy stance (#8), which this ticket was blocking and which is now on the frontier.

Findings that apply to the shipped MVP, not only to this effort

Flagged separately as they are about what is deployed today. Tracked in a standalone issue rather than on this map, since they sit outside its destination.

• Suppression as built is Article 18 restriction, not Article 17 erasure.
• Permanent immutable snapshots are forbidden three ways over.
• The GitHub removal-request template fails Article 12 on five grounds — the worst being that exercising the right requires publicly republishing the linkage you are asking to have removed.
• The live /privacy page is materially incomplete.
• A pre-launch DPIA is mandatory; the ICO's "data matching" trigger is unconditional.

The current MVP publishes only links Raider.IO already publishes, which is materially weaker than inferring hidden ones — so it is not the same exposure. But the rights-channel, privacy-notice and DPIA gaps do not depend on the source of the data.

[Erilla]

Mitigation status changed: the behavioural mitigation this ticket identified — not publishing inferred-only linkage where a contrary preference was signalled — was removed in #33. See the reversal note on #8 for why the signal proved unusable as decided. The indexing mitigation is unaffected.