Hide methodology

Public scan coverage

Clear currently checks public address and mail routing, DNSSEC delegation, SPF and DMARC policy, MTA-STS discovery and HTTPS policy coverage, SMTP TLS reporting, DNSSEC-authenticated DANE TLSA records, CAA restrictions, validated HTTPS responses, HSTS, Content Security Policy, technology disclosure and the standard security.txt location.

Every finding includes the public source, access time, observed value and current scanner-method version.

Verdict definitions

Action

The observation supports a specific change. The report explains the evidence and a bounded next step.

Pass

The tested requirement was present and met the method's documented threshold at scan time.

Observed

A fact was visible, but presence alone is not enough to call it secure or insecure.

Unverified

A source timed out or could not be checked safely. Clear does not convert missing evidence into a pass or failure.

Safety boundary

The public scan does not scan ports, send exploit payloads, attempt sign-ins, test credentials or simulate attacks. It rejects IP targets and blocks domains that resolve to private, local, reserved or documentation networks.

For MTA-STS, Clear checks the DNS discovery marker, required HTTPS policy endpoint, policy syntax and coverage of published MX hosts. For DANE, it checks DNSSEC authentication and whether published TLSA parameters are usable for SMTP. It does not connect to mail servers, test live STARTTLS or compare TLSA values with mail-server certificates, so it does not prove that SMTP transport is secure. Employee-account and leak details are not part of the public scan. Company-scoped information requires exact-domain ownership verification.

Personal outcome proof

A personal case moves through five explicit stages: found, removal requested, source responded, removal verified and monitoring. Hide does not count a queued or sent request as a successful removal. Before delivery, the account owner reviews the exact request and confirms the recipient. Hide then makes a bounded request to the supplied public privacy, legal or contact page and verifies that the exact recipient address appears there; it does not retain that page text. Statutory-register sources enter a specialist queue because the correct route may be correction, restriction or objection rather than erasure. The operation stores approval time, recipient, delivery-provider identifier, response deadline and approved follow-up state. Every outgoing subject carries an exact Hide case reference. A scheduled Strato sync considers only recent messages with that reference, removes quoted request text before applying conservative acknowledgement, verification, claimed-completion and refusal rules, and submits a signed event containing fingerprints rather than raw correspondence. The imported category creates a human-review checkpoint; it is not evidence that the source's statement is true. If that checkpoint indicates an identity-verification request, the owner sees and separately approves one fixed response asking the source to explain reasonable doubt, minimise evidence, allow redaction and provide a protected channel. Delivery follows the same provider-event proof and bounded retry rules as the removal request. A later inbound message does not unlock completion automatically: a Hide operator must review the original reply and publish a bounded summary of the protected route and minimum requirements into the private case. Hide stores that summary, task state and dates, not identity documents; the owner completes any necessary check directly with the source and confirms only completion. Message-body hashes make outbound and recorded inbound events comparable without placing request bodies in analytics.

Before and after source captures record the final public URL, HTTP status, selected response headers, byte length, access time, a SHA-256 content hash and a SHA-256 source fingerprint. Redirects are bounded and every destination is checked against private and reserved networks before it is fetched. For an account-owned monitored case, Hide repeats that bounded capture every 30 days. An unavailable source is retried without claiming a change. A different fingerprint creates a change review. A page moving from HTTP 404 or 410 to a successful response creates a possible-relisting review. Neither automatically changes the case to relisted: the person must inspect the source and confirm the outcome.

A fetched record means Hide observed the source response. A person-confirmed record additionally means the person stated what was visible in that response. A fingerprint makes two observations comparable, but it cannot independently prove whose information appeared, whether a legal duty was satisfied or why content changed. Downloadable outcome proof preserves these distinctions.

How Hide Verify reaches a result

Hide Verify separates evidence by basis instead of producing a single opaque score. It reads message requests and payment destinations, parses supplied original-header fields, compares visible and reply identities, interprets supplied mail-authentication results, checks referenced DKIM keys and public SPF and DMARC policy, reviews public registration age and certificate history, detects encoded or mixed-script domain presentation and counts earlier matching indicator hashes.

For screenshots, Hide downloads a self-hosted English and German OCR runtime and language data from hidedata.app. Recognition runs in the browser; the image does not leave the device. The user sees and can correct the bounded extracted text before submitting it. OCR output is not proof that an image is authentic, complete or unaltered, and recognition errors can change indicators.

Phone, bank and wallet indicators are treated as destinations to verify, never as proof of identity. Hide separates IBANs from phone numbers, checks the IBAN checksum and known national length, and recommends the bank's beneficiary-name check where available. For wallet destinations it validates mixed-case EIP-55 checksums, Bitcoin Bech32 or Bech32m witness rules, Bitcoin Base58Check and Tron Base58Check where the format supports them. A valid checksum can catch some copying errors; it never identifies the owner, balance, purpose or network. Some addresses can exist on several EVM-compatible networks.

When commercial threat intelligence is configured, Hide sends up to three submitted public URLs to Google Web Risk and asks whether they match malware, social-engineering or unwanted-software lists. A match is a strong warning, not infallible proof. No match means only that the provider returned no known listing at check time; Hide never turns absence from a list into a safe verdict. Provider errors and unavailable configuration remain unknown.

For up to three public links, Hide performs HEAD-only requests through no more than four redirects. It validates each hostname and its public addresses before requesting it, rejects credentials, non-standard ports and private or reserved destinations, and records only derived hostnames and response status codes. The result distinguishes a completed same-host HTTPS route from cross-domain handoffs, unencrypted routes, loops, unavailable destinations and traces stopped at the redirect limit. An incomplete trace remains unknown or needs verification; it cannot become reassuring. Hide does not load a page body, attachment, script or form. Confidence reflects the number of independent evidence bases available; it is not a probability that the message is malicious. Missing evidence remains unknown, and no automated check can label a message safe.

What the report does not prove

A result is a dated snapshot of a limited public surface. It is not a penetration test, internal security review, legal opinion, compliance assessment or certification. Systems can change immediately after collection.

Inspect the personal outcome metrics, inspect the identity discovery benchmark, inspect the Hide Verify benchmark, review the method changelog or inspect the Clear benchmark.

Corrections

If a result is inaccurate or a public source behaved unexpectedly, email info@hidedata.app with the report link and finding name. Reports expire after 90 days.