A reviewer can confirm it in under a minute
Vague abuse reports get queued and ignored. Everything we file is independently reproduced and documented first, so the responsible provider can verify the abuse themselves rather than take our word for it.
Every notice carries the same four things
- The exact abusive URL, captured live
- The brand it impersonates, and how the page claims it
- The responsible infrastructure — registrar, host, CDN
- A one-line reproduction command the reviewer can run
The evidence behind a case
HTTP responses
Request metadata, response headers and status for each fetch, retained as the factual record of what the server returned and when.
Rendered HTML
The saved page as served — the brand references, forms and redirects that demonstrate the impersonation or harvesting.
Both cloaked variants
Where a site cloaks, we capture the decoy shown to browsers and the page served to crawlers — side by side — to prove the deception.
Integrity you can verify yourself
1 · SHA-256 hash manifest
Every artefact in a bundle — screenshot, HTML, response metadata, WHOIS/DNS/TLS snapshots — is digested, and the manifest chains the digests together. Recompute any artefact's hash and it must match: a single changed byte breaks the chain.
2 · RFC 3161 trusted timestamp
The chain digest is sealed by an independent time-stamping authority. The resulting token proves the evidence existed, in exactly this form, at capture time — we cannot back-date or alter it after the fact.
3 · Write-once (WORM) storage
Bundles are stored under S3 Object Lock in compliance mode: until retention expires they cannot be overwritten or deleted — by an attacker, or by us. The copy produced in a later dispute is provably the original capture.
4 · Independent archive
Publicly reachable pages are also snapshotted to the Internet Archive — a second record on infrastructure we don't operate, that any reviewer can open without trusting us.
A reviewer can check all four layers with standard tooling — for example, verifying the timestamp token directly:
# Inspect the token: digest covered, issuing TSA, signing time
openssl ts -reply -in evidence.tsr -text
# Verify it against the bundle's chain digest
openssl ts -verify -digest <chain-digest-hex> -in evidence.tsr -CAfile tsa-cacert.pemStep-by-step instructions for desks and panels reviewing our material: Verifying a ClearPhish evidence bundle.
Retention, disclosure & limits
Retention & sharing
We retain the captured responses for each case for as long as necessary to pursue and document the takedown, and we provide them to the reviewing registrar, host, CDN or other party able to act on the abuse, on request. We report only what we can independently reproduce.
What we never do
We only observe what any visitor or search engine would see. We do not attempt to access, alter or disrupt third-party systems, we never ask a recipient for credentials, payment or account access, and we do not try to defeat any provider's security controls. Our notices ask the responsible provider to assess a URL against their own acceptable-use policy — nothing more.
Verifying a notice from us?
Genuine notices come only from abuse@clearphish.org. Confirm our identity and request the underlying evidence on the Abuse & Reports page.