Community Bans — Privacy

v1.0 · effective 2026-05-27

The Community Bans feature aggregates BAN reports from unmask installs and republishes them as a community-curated list. This document covers what the hub stores, how long it keeps it, and what your rights look like under GDPR-style regimes.

What we collect from submitting installs

An anonymous token id (32 random bytes, generated client-side). The hub stores only the SHA-256 hash; the raw token never persists.
A derived handle name (HN) (= "swift-otter-a3f7" style). This is a deterministic function of the token (HN = adjective + noun + 4 hex chars). The hub displays the HN next to each entry so submitters can be referred to by a stable pseudonym; the underlying token cannot be reversed from the HN.
Country code (= ISO 3166-1 alpha-2) — derived from the install's IP via GeoLite2 on the hub side and shown next to the HN. Default ON so the feed reflects the geographic spread of contributing deployments; operators can opt out at any time (publish_country: false). Turning it off stops new requests from carrying the country code; existing rows keep whatever they had until they age out.
The IP address and JA4 fingerprint of the client your install banned. These belong to the third party your install observed, not to you.
The reason and comment fields you chose to attach (free text, ≤ 280 chars for comments).
The timestamp of the submission.
A per-day salted hash of the submitting install's IP (= SHA-256(server_secret ‖ "YYYY-MM-DD" ‖ submitter_ip)). Used for abuse detection only. The raw IP is never stored; the day-salt rotates daily so cross-day correlation of the same install is intentionally difficult. The hash is scrubbed on a short rolling window so the reporter-side identifier cannot tie new submissions back to a specific install indefinitely.

What we collect from comments and votes

The browse UI lets registered installs attach 👍 / 👎 votes and text comments to other installs' submissions. For each vote / comment we store the same fields as a submission (token's HN, opt-in country, per-day salted IP hash), the parent submission id, and the vote kind ("like" / "bad") or comment text (≤ 280 chars).

What we do not collect

No email, no name, no account. No PII about the operator of an unmask installation.
No URL paths, headers, cookies, or request bodies from the banned traffic.
No third-party analytics or trackers on the hub or this site.
No raw submitter IPs — only the per-day salted hash, scrubbed on a short rolling window.

What we publish

Public endpoints:

https://unmask.sh/api/feed/list.json — the single feed. Every aggregated entry is included, both promoted rows (= aggregate trust score ≥ 3) and reports-only rows (= score 1-2 that did not reach the BAN threshold). Each entry carries match kind, IP and/or JA4, confidence, score, a short reasoning string, aggregated vote / comment counts, and the reporting deployment count. Subscribers decide how aggressively to act on the feed via their local AutoBanMinScore setting; the hub no longer pre-filters to a separate BAN-only file. Individual submission IDs are not exposed; only the (ip, ja4) aggregate.
https://unmask.sh/api/feed/aggregate?ip=&ja4= — per-pair detail. Returns the list of submissions, comments, and voters for that pair so users can audit the verdict. HNs, opt-in country codes, reasons, comment text, and submission timestamps are all visible here. Raw IP hashes are never returned.

Retention

Two separate windows apply:

Public feed window. An entry only appears on /api/feed/list.json while it is relevant to the feed's accuracy. Older entries rotate out automatically, so a one-off report from a long time ago does not keep showing up. An (ip, ja4) pair stays on the feed as long as at least one of its reports is still within this window; once the most recent report ages out, the pair disappears from the public feed. Subscribers see entries rotate naturally as the window slides.
Reporter anonymity. The per-day salted hash that ties a submission back to a reporting deployment is scrubbed on a short rolling window, independent of the public-feed window. After scrubbing, no record on the hub can be traced back to the install that submitted it -- this is the line that guarantees reporter anonymity even when the underlying submission record itself is kept longer for aggregate-score integrity and audit purposes.
Internal record. Submission bodies (target IP / JA4 / reason / comment / aggregated counts) may be retained beyond the public feed window for score integrity, long-term bot-pattern analysis, and the takedown audit trail. They never re-appear on the public feed once rotated out. Reported parties who want a row removed from the hub entirely can request it via the removal form.
Comments and votes cascade-delete with their parent submission when a takedown removes one.

The aggregate score

The hub assigns each (ip, ja4) pair a 1-5 trust score based on how many distinct installs reported it, vote ratio, and presence of dissenting comments. Optionally, an LLM judge may be configured (= currently OpenAI- compatible chat completion) to re-evaluate the same signals. When the AI judge is consulted, its short reasoning string is published in the feed; the underlying API call sends only the structured signals listed above (no raw IPs, no operator metadata).

About reported IPs

Reported IPs are network identifiers that may correspond to natural persons. Under GDPR-style regimes, the operator submitting the report is the controller of that data in their own logs; unmask.sh processes it on the operator's behalf solely for the purpose of running the community feed. Default action is captcha_only, not hard block, so humans behind shared IPs are still served a challenge rather than refused outright.

Your rights and deletion

If you are a submitter:

Flipping submit_enabled off in your unmask config stops further submissions immediately.
You can delete your own submissions, comments, and votes individually from the Bans page in your admin UI (= the inline × buttons in the detail panel).
To delete every row associated with your token at once, use the removal request form with the HN your install displays.

If you believe a reported IP is yours and should not be on the feed: use the removal request form with the IP. We will remove it from the feed. Reports for the same IP from new submissions are deprioritised after a takedown so the entry does not immediately bounce back.

Legal basis (GDPR mapping)

Art. 5(1)(b) purpose limitation — data is used only for the Community Bans feature and abuse detection.
Art. 5(1)(c) data minimization — raw IPs are not stored, country is operator-controlled (default ON, opt-out at any time), no operator PII is collected.
Art. 5(1)(e) storage limitation — public-feed entries rotate out on a relevance-driven window; the per-day salted reporter hash is scrubbed on its own short window so reporter anonymity is preserved independent of any internal-record retention.
Art. 5(1)(f) integrity — server salt rotates daily, HN derivation is not reversible from public data.
Art. 6(1)(f) legitimate interest — Recital 49 explicitly recognises network security and abuse prevention as a legitimate purpose.
Art. 15 access / Art. 17 erasure — supported via the inline delete buttons and the removal request form address above.
Art. 25 privacy by design — hash-and-rotate IP handling, operator-controlled country (default ON, opt-out anytime), default-OFF submission, default-captcha enforcement.

Contact

the removal request form

This document is not legal advice. unmask is an open-source project run by individuals; before relying on these policies for compliance in your jurisdiction, consult counsel. We welcome corrections via the contact address above.