Skip to content

Data-protection gaps in the deployed service #19

Description

@Erilla

Raised from research done for the fingerprint-discovery map (#16), which surfaced findings about what is deployed today rather than only about the proposed feature. Tracked here rather than on that map, because it sits outside that map's destination.

Full source: docs/research/data-protection-exposure.md. Research, not legal advice.

The premise. A character name is personal data under UK GDPR. The ICO's guidance is explicit that a username identifies a person "regardless of whether it is possible to link the 'online' identity with a 'real world' named individual". SlashWho is therefore an independent controller, and the following gaps exist in the live service regardless of the fingerprint effort ever happening.

The MVP's exposure is materially lower than the proposed feature's — it republishes links Raider.IO already publishes, rather than inferring hidden ones — so this is not urgent in the way the fingerprint work would be. But none of the items below depend on where the data came from.

Items

  1. The removal-request template fails Article 12 on five grounds. The worst is structural: exercising the right currently requires publicly republishing the linkage the requester wants removed, in a public GitHub issue. Anyone asking to be forgotten must first broadcast the thing they object to.
  2. /privacy is materially incomplete against Articles 13/14 — and DUAA 2025 added a mandatory public-notice duty at Article 14(7), in force since June 2026.
  3. Suppression is Article 18 restriction, not Article 17 erasure. It stops publication; it does not delete. The distinction matters for what we can honestly promise a requester.
  4. Permanent immutable snapshots conflict with storage limitation, and new Articles 84A/84B (DUAA 2025) closed the archiving exemption that might otherwise have covered them.
  5. A DPIA is mandatory before launch, not optional — the ICO's "data matching" trigger is unconditional, and SlashWho is squarely data matching.
  6. DPA 2018 s.164A (in force 19 June 2026) requires a complaint-handling route completable "electronically and by other means" — a GitHub issue template is electronic-only.

Suggested order

Items 1 and 2 are cheap, self-contained, and fix the things a real person would actually hit. Item 5 is paperwork that forces the other decisions into the open and is worth doing before any further public promotion. Items 3 and 4 are design questions and should be decided deliberately rather than patched.

Nothing here needs to block the site staying up; all of it should be resolved before it is promoted anywhere with an audience.

Metadata

Metadata

Assignees

No one assigned

    Labels

    needs-triageMaintainer needs to evaluate this issue

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions