404 Audit · Our process
Audit Methodology
What remains recognizable when your team changes how it browses?
We agree on a test plan, guide participants through repeatable sessions, compare what the browser and connection reveal, and explain which changes would reduce your team's exposure.
Before collection
Start with the work your team needs to protect.
A useful audit needs a specific question. For example: can separate research sessions remain recognizable after staff switch to a VPN and private browsing?
Your team brings the context
- The work and exposure you are concerned about.
- The browsers, devices, networks, and privacy tools staff actually use.
- Who will participate and which environments can be tested.
- Constraints on third-party services, collection, and operational disruption.
404 turns it into a test plan
- Define the baseline and each changed condition.
- Agree on session labels, run order, and repeat runs.
- Identify which measurements are available and which need additional collection.
- Agree on scope, quote, data handling, and deliverables before testing begins.
Example scope: three staff members, their usual browser, a private-window run, and a VPN comparison. The exact participants and runs are agreed for your engagement.
Inside one session
An invitation. Four familiar tasks. A receipt.
Participants open an audit invitation in the agreed browser and network condition. The current flow takes a few minutes per run; the number of runs depends on the test plan.
Label the environment and review collection.
Enter a name or agreed alias and an environment label. Mark whether VPN, private browsing, and privacy tools are active. These are participant claims that we compare with observations. Starting the session runs request checks before the first task.
- 01
Read
Read a short article and scroll through it naturally.
Time on the task, scroll depth, pauses, and interaction patterns.
- 02
Respond
Complete a short form using your usual input tools. Use nonconfidential answers.
Field interactions, focus changes, completion timing, and form behavior.
- 03
Watch
Play part of a short video. Pause or mute as you normally would; a blocked video can be skipped.
Playback interactions, available media capabilities, and resource timing.
- 04
Type
Copy the supplied passage at your natural pace, including corrections.
Typing timing, key intervals, corrections, and progress through the supplied text.
Submit and wait for confirmation.
The flow collects final browser measurements and sends the capture to 404 for review. A receipt confirms that the session was saved. Your audit contact then guides any additional runs and the findings review.
Collection, third-party checks, and blocked features
Browser and rendering signals, request observations, task summaries, and the name and environment labels are stored for audit analysis. This is an assessment session with data collection; it is not a local-only demonstration.
The current media task loads YouTube. A best-effort TLS check contacts BrowserLeaks. We discuss restrictions during scoping. Participants can skip a blocked video and keep their protections enabled; unsupported or blocked measurements are recorded as unavailable.
Interaction measurements concern the audit tasks. This flow is not a recorder of the participant's entire browsing history. Use the supplied typing passage and avoid credentials, source material, confidential client information, or regulated data in the sample form.
The comparison plan
Change a condition. Repeat the session. Compare the evidence.
We keep the participant and task sequence consistent where practical, record the setup, and change a defined condition. Repeated baseline runs help distinguish a stable trait from a value that varies naturally.
| Run | Environment | Condition tested | Question |
|---|---|---|---|
| A | Your usual browser and network | Baseline | Which signals repeat within the usual setup? |
| B | Same browser, private window | Browsing context | Which values persist when the storage context changes? |
| C | Same browser, private window, VPN | Network route | Which browser traits remain after the observed exit changes? |
| D | An agreed alternate browser or profile | Browser environment | Which signals differ, overlap, or conflict with the new setup? |
A control changed this observation. We check whether other surfaces still connect the sessions.
A value returned across runs. We examine stability, shared configurations, and corroborating evidence.
A check was blocked, unsupported, or failed. We retain that gap rather than turning it into a reassuring result.
Browser updates, device changes, and collection failures can affect comparisons. Each finding identifies the sessions and conditions it rests on.
What we measure
The browser, the request, and the way the tasks unfold.
We retain the underlying observations as well as comparable hashes and individual signals. A compact fingerprint helps group captures; the actual values help explain why they matched or differed.
Browser & rendering
Browser properties, Client Hints available to JavaScript, language, timezone, screen, storage capabilities, and supported features. Canvas, WebGL, and audio measurements show how rendering outputs behave across runs.
Does the exposed configuration repeat? Do its claims agree?
Connection & protocol
Received headers and request metadata, network provider and location fields where available, HTTP protocol, and available TLS evidence. Edge metadata and an external TLS check have different observation points.
What arrived at the observer after the route changed?
Interaction & workflow
Reading, scrolling, form, playback, pointer, and typing summaries from the guided tasks. We compare these with the environment and run conditions, including automation indicators and missing measurements.
Which patterns recur, and which depend on the task or setup?
What network coverage depends on
The standard web collector sees what the application and hosting edge expose. Available TLS and JA4 fields depend on the deployment and connection. Headers seen by the application may have passed through normalization at intermediaries.
A full TCP/IP stack fingerprint requires an appropriate packet observation point and additional collection agreed in scope. Browser JavaScript, a latency estimate, or an edge HTTP field cannot substitute for a capture of TCP option order, window values, and packet behavior.
We identify the source of each measurement. A signal from an external test endpoint is evidence about the connection to that endpoint, and may differ from the path to another destination.
From evidence to findings
Explain the match before assigning the risk.
We review repeated signals, changes, inconsistencies, and collection gaps together. Several related browser outputs may share a cause, so they do not automatically count as independent evidence.
A matching hash supports a comparison between captures. Connecting that comparison to a person or organization requires context, such as an account, a common deployment, or an identifiable workflow. Population uniqueness cannot be established from a handful of audit runs.
Priorities reflect the strength of the evidence, how repeatable it is, which observer could see it, and the consequences for the work in scope. Automated flags help direct review; the report explains the reasoning and uncertainty behind the recommendation.
The route changed. A rendering output repeated.
- Observed
- The network exit differed between two runs; a canvas output matched.
- Interpretation
- The output could support recognition across those tested sessions.
- Check next
- Repeat the runs and compare independent browser and request evidence.
- Action
- Test a different browser or profile and review the workflow's account exposure.
- Limit
- The match alone does not establish personal identity or uniqueness.
What you receive
A report your team can use to change its working environment.
- Executive summary
- The main exposures and the decisions they support.
- Technical evidence
- The tested environments, comparison results, supporting observations, missing coverage, and confidence limits.
- Prioritized changes
- Browser, network, account, and workflow recommendations fitted to the agreed risk scenario.
- Findings review
- A discussion of the results and practical next steps. Training or a follow-up comparison can be scoped where useful.
Sources and technical references
Apply the methodology
Let's scope your team's audit.
Tell us about your organization, the environment you use, and the exposure you're concerned about. We'll agree on scope and a quote before testing begins.
Please keep credentials, confidential client information, source material, and regulated data out of this public form.
Delivered by email. No mailing-list signup. Cloudflare provides spam verification. Privacy policy.