Trust at UNMASK

Who is responsible for what

UNMASK is a tool. The organisation that uses it decides who is researched, why, and what happens with the results, and is the controller of that personal data. The operator of this service runs the software and its security. Where your organisation self-hosts UNMASK, it is both.

Responsible-use safeguards

• No case without a basis. A case can't be created without an authorisation note and a lawful-basis confirmation. The database itself rejects a case without them, so no code path can skip the check. Both appear at the top of every report.
• Terms accepted per person. Every user accepts the Terms and Acceptable Use Policy before using the service, and again when they change. The version and time are recorded.
• Findings are presented as leads. Every finding carries a score, the sources that reported it, a source-reliability grade and the reasons behind its score. Reports lead with a human-written assessment and are only produced once one exists.
• Humans decide. The software confirms nothing on its own. "Same person" and "Not them" are decisions made by a named analyst, and each one is logged.
• Everything is attributable. Sign-ins, failed sign-ins, opening a case, every decision, note, snapshot, export, share and share-link view is written to an audit log with the user and time. Audit records survive case deletion.
• Access is per case. Only the owner and the people they share a case with can open it. Only the owner can share it, create external links or delete it.
• Sample data for learning. New users can practise on a sample case about an invented person, which can't be scanned.

How data is protected

• Encryption at rest. Target values, findings and their details, notes, notifications, snapshots, relation explanations and Slack webhooks are encrypted in the database with Fernet (AES-128 in CBC mode with an HMAC-SHA256 authentication tag) before they are stored. Lookups use a keyed HMAC "blind index" with a separate key, so identifiers are never stored in the clear to be searchable. Keys can be rotated without downtime.
• Passwords are hashed with Argon2id. Repeated failed sign-ins are throttled and logged.
• In the browser. A strict Content Security Policy allows only the application's own scripts; every script is self-hosted, so analysts' browsers make no third-party requests while working a case. Pages are protected against cross-site request forgery and clickjacking, and no referrer is sent to outside sites.
• Search engines may index only the public pages (the home page and these legal pages). Everything behind sign-in is marked not to be indexed, and so are share links.
• Share links for people without an account are read-only, expire within at most 30 days, can be revoked at once, and only a hash of each link is stored. Every view is logged.
• Page snapshots are stored byte-for-byte with a SHA-256 fingerprint recorded at capture, so their integrity can be checked later. Captured pages are shown as plain text and never rendered inside the application. The service refuses to fetch any address that isn't on the public internet, at every redirect.
• Notifications sent by email or Slack say only what happened and link back in. They never include case names, targets or findings.
• Tools run as separate processes with time limits. Credentials such as proxy passwords reach them through the environment, never on a command line where other processes could read them.
• API keys entered on the Integrations page are encrypted like case data, shown back only as their last four characters, and can be changed only by administrators. Every change is logged, without the key itself.

What leaves the platform

To find anything, UNMASK must ask other services. When a scan runs, the identifiers in the case (a username, email address, name, domain, phone number or IP address) are sent to some or all of:

• websites whose sign-up, profile or recovery pages are checked to see whether an account exists (via open-source tools such as Sherlock, Maigret and Holehe);
• web search providers configured by the operator (for example Serper, SerpAPI, Google Programmable Search, Brave Search or DuckDuckGo);
• public profile APIs (GitHub, GitLab, Keybase, Hacker News and Gravatar; Gravatar receives a hash of the email address);
• breach-notification services (LeakCheck's public API, and Have I Been Pwned or h8mail's sources where keys have been configured);
• email, phone and IP intelligence services where keys have been configured (EmailRep, Hunter, Numverify, IPinfo and Shodan);
• domain registration, archive, certificate transparency and DNS sources (for example RDAP, the Internet Archive, crt.sh, VirusTotal, SecurityTrails, theHarvester, Amass and SpiderFoot); and
• any outbound proxy the operator has configured, which carries that traffic.

Those services receive the identifier and the server's (or proxy's) network address, under their own terms and privacy policies. Some may log the request, and a site could in principle notice that an account was looked up. Decide whether that is acceptable for each case before you scan. The data is otherwise hosted by the hosting provider the operator has chosen; UNMASK sends no analytics or telemetry anywhere.

Retention and deletion

• Each case has a retention period (90 days by default, adjustable per case). The period restarts when the case is scanned again, not when it is merely viewed. The Home page warns before a case is due to be deleted.
• When the period ends, the case and everything in it (targets, findings, notes, snapshots, share links) is permanently deleted. The owner can also delete a case at any time. Sample cases are kept for 30 days.
• Audit records are kept after a case is deleted, without the case's contents, so that past access can still be accounted for.
• Database backups follow the operator's backup schedule, and deleted data leaves them as backups expire.

Known limits

We would rather you knew these than discovered them:

• Scores are estimates. A common name or handle can match many people, and sites change in ways that make their pages look like profiles when they aren't. Verify before you rely on anything.
• Some sites block requests from cloud servers, so results can be incomplete; the app reports which tools failed rather than showing an empty result as "nothing found".
• Data you export or download leaves UNMASK's controls. Its security and deletion are then your responsibility.
• The address check on page snapshots resolves names before fetching; a hostile site could in theory change its DNS between the check and the fetch. Routing fetches through a proxy moves that resolution off the server.
• Encryption at rest protects the database and its backups. It does not protect against someone who has signed in with a valid account, which is why access control, the audit log and your account security matter.

Reporting a vulnerability

If you believe you have found a security vulnerability, please tell us, with enough detail to reproduce it. Please do not access other people's data, degrade the service or publish the issue before it is fixed. We will not pursue legal action against good-faith research that follows these rules. This permission covers only this service and only research conducted in line with this section.