Methodology 0.1.0, frozen copy. The current version is always at /monitor/methodology.
Copyright © 2026 Safe and Informed S.R.L. All rights reserved.
Methodology version: 0.1.0 · Published by Safe and Informed S.R.L. · [email protected]
ConsentVeil Monitor provides automated technical observations. It is not legal advice, a legal compliance certification or a substitute for professional legal review.
This document describes exactly how a scan is performed, what each test measures, what the statuses mean and where the method stops being reliable. It is published so that a finding can be checked, disputed and reproduced. Every report states the methodology version it was produced under, and this document is versioned alongside the scanner.
1. What a scan is
Monitor loads a public page of a website in an automated browser with a clean profile: no history, no cookies, no extensions, no stored consent. It records what the page does on its own, then performs a small number of deliberate interactions and records what changes.
Monitor runs against websites the customer is responsible for and has confirmed ownership of. It does not scan authenticated areas, does not submit forms, does not attempt to bypass any control, and changes nothing on the customer's servers. All observation happens in the scanner's own browser.
The scanner may click consent controls, because a test such as "does Reject all actually stop tracking" cannot be answered without using the control. This is the opposite of the ConsentVeil browser extension, which never clicks a consent control and never sends a choice. The two systems share no runtime code, and Monitor never receives data from extension users.
2. What is recorded
| Recorded | Detail |
|---|---|
| Network requests | URL, resource type, timing relative to the consent action, classification |
| Cookies | name, domain, path, expiry, flags, value length; values are redacted unless short and plainly non-secret |
| localStorage and sessionStorage | key, value length, same redaction rule |
| Banner presence | whether a consent dialog was found, which platform, which controls were reachable |
| Layout measurements | relative size, contrast and click depth of accept and reject controls |
| Page health | console errors, visible text length, scrollability, named expected elements |
| Screenshots | the state of the page at each stage |
Before anything is written to a report, credential-bearing headers and query parameters are
replaced. The list of redacted headers and the allowlist of preserved query parameters are in the
scanner source (monitor/src/report.js) and are part of this methodology.
3. Flows
A scan runs one or more flows. Each flow starts from a fresh browser context, so one flow cannot contaminate another.
| Flow | What happens |
|---|---|
baseline |
The page is loaded and left alone for a settle period. Nothing is clicked. This is what a visitor who does nothing experiences. |
reject |
The reject control is located and used, then the page is observed again, then navigated to measure persistence. |
accept |
The accept control is used, for comparison only. It establishes what the site does when consent is given, so "before consent" findings can be distinguished from "always". |
withdraw |
A control that reopens or revokes consent is located and used, then tracking is re-observed. |
gpc |
The page is loaded with Sec-GPC: 1 and, where the browser allows it, navigator.globalPrivacyControl set, with no interaction. |
Requests are attributed to the stage in which they occurred, using a watermark taken immediately before each interaction. A request caused by a click is attributed to that click, not to the page load.
4. The tests
Fifteen tests, each with a stable identifier that does not change between versions. The identifier is what a customer should quote when disputing a result.
| Test id | What it measures | Severity when it fails |
|---|---|---|
trackers-before-consent |
Requests to known tracking and advertising services sent before any consent signal | high |
storage-before-consent |
Cookies and storage keys written before any consent signal | high |
reject-all-effective |
Whether using the reject control actually stops tracker requests and removes non-essential storage in the same page view | critical |
reject-control-reachable |
Whether a reject control exists at the same click depth as accept | medium |
refusal-persists |
Whether the refusal survives a reload and a further navigation | high |
banner-reappears |
Whether the banner asks again after a decision was stored | medium |
gpc-respected |
Whether the Global Privacy Control signal changes what loads before consent | high |
withdrawal-reachable |
Whether a visitor can find a way to change or revoke a decision | medium |
withdrawal-stops-tracking |
Whether withdrawal actually stops tracking and clears what was stored | high |
reject-keeps-site-usable |
Whether refusing consent breaks content, scrolling or named elements | medium |
dark-pattern-asymmetry |
Measured difference in click depth, size, contrast and pre-ticked options between accept and reject | medium |
cmp-unchanged |
Whether the consent platform implementation changed since the previous scan | low |
no-new-trackers |
Whether third-party services appeared that were not present in the previous scan | medium |
browser-consistency |
Whether the same behaviour is observed in every browser that was run | low |
locale-consistency |
Whether the same behaviour is observed in every locale that was run | low |
Each test carries its own limitations into the report. They are reproduced with the finding, not hidden in an appendix.
5. Statuses
| Status | Meaning | Counts toward the score |
|---|---|---|
pass |
The test completed and the expected behaviour was observed | yes |
fail |
The test completed and the expected behaviour was not observed | yes |
warning |
The test completed and found something that needs a human decision, for example storage whose necessity cannot be decided automatically | yes |
inconclusive |
The test did not complete, for example a control was not found or a navigation timed out | yes, as a non-pass |
unsupported |
The platform or the invocation cannot perform the test, for example comparing locales from a single-locale run | no |
not_tested |
The flow needed for this test was not requested | no |
An inconclusive result is never presented as a pass, and never silently dropped. The absence of evidence is not evidence of absence, and the report says so.
Each finding also carries a confidence (low, medium, high), which describes how certain the
measurement is, separately from what it found. A fail at low confidence is an invitation to look
closer, not a conclusion.
6. Severity and score
Severity is fixed per test and does not vary by customer or plan. It describes the technical weight of the finding, never a legal consequence.
The score is a single number and is deliberately crude:
score = passes / (passes + fails + warnings + inconclusives) × 100
unsupported and not_tested results are excluded from both sides of the fraction, so a scan that
could not run half its tests cannot look clean. Inconclusive results stay in the denominator and
are also reported separately, so an incomplete scan always scores lower than a complete one.
The score is not a grade, not a certification and not comparable between sites with different scan configurations. A report that lists the configuration is the real result; the score is a summary for people who read one number.
7. Standing limitations
These apply to every scan and appear in every report:
- A scan observes public pages only. Authenticated, logged-in and private pages are not scanned.
- A scan observes one point in time, from one exit location, in the browsers and locales actually run.
- Host classification uses the packaged provider lists. An unclassified host is reported as unclassified, never as safe.
- Consent control detection is selector and label based, and English labels only in this version. A banner in another language can yield "control not found", which is recorded as inconclusive.
- An inconclusive result means the test did not complete. It is not a pass.
- Monitor reports measurable technical observations. It does not interpret law and does not assess intent.
Additional limitations specific to a test are printed with that test's finding.
8. What Monitor will not do
- It will not issue certifications, badges, seals or any claim of legal compliance.
- It will not change a finding, a severity, a score or a piece of evidence because of what a customer pays, or because a customer asks.
- It will not hide a failed check from a report. A white-labelled report may carry an agency's branding, but it may not remove findings, limitations or this methodology reference.
- It will not state that a website is lawful or unlawful. That judgement belongs to a qualified lawyer and, ultimately, to a supervisory authority.
9. Disputing a finding
Quote the test identifier, the scan timestamp and the methodology version from the report, and write to [email protected]. Where a finding is wrong, the correction is free and the scan is repeated. Where the method itself is wrong, the fix lands in the scanner and this document gets a new version number.
10. Versioning
The methodology version changes when a test is added or removed, when what a test measures changes, when a status definition changes, or when the score formula changes. Fixing a bug that made a test report the wrong result also produces a new version. Reports are not retroactively re-scored: each report states the version it was produced under, and old versions of this document remain available.
| Version | Date | Change |
|---|---|---|
| 0.1.0 | 2026-10-19 | First published methodology: 15 tests, five flows, six statuses, the score formula above. |