How a scan is performed, what each test measures, what the statuses mean and where the method stops being reliable. Part of ConsentVeil Monitor.
Methodology 0.3.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.3.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 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 and disputed. Every report states the methodology version it was produced under, and this document is versioned alongside the scanner. A more detailed technical description of the scanner's internal controls is available to customers on request.
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 only against websites the customer is responsible for, and the scanner does not run until exactly one way of establishing that is recorded. The report names it:
| Method | What it means |
|---|---|
dns_txt |
a token we issued is found in a DNS TXT record on _consentveil.<host> |
well_known_file |
the same token is found at /.well-known/consentveil-verify.txt |
domain_email |
the order came from an address at the site's own domain; the domain match is checked, the message itself was confirmed by our staff |
written_order |
a documented order from the organisation, recorded by reference; nothing was checked technically |
Before every scan the target is also checked against our domain-exclusion register; a domain owner who asked not to be scanned is never scanned.
The scanner does not modify source code, CMS content or server configuration. Ordinary page loads and interactions with consent controls may create server or CDN logs, cookies, consent records, analytics events or similar operational records on the site's side. The scanner does not sign in, create accounts, complete business forms or place orders, and it does not authenticate into, circumvent or bypass paywalled or otherwise access-controlled areas. It does activate consent controls, and a site may implement such a control as a form button; that is the only form interaction that can occur. All observation happens in the scanner's own browser.
The scanner's connections are restricted to the ordered website and the public destinations its
pages call: local, private and infrastructure addresses are refused, a navigation of the page to
another website is refused, and browser side channels that bypass these controls (WebRTC and
media capture among them) are disabled in every scanner browser and verified at start-up; the
scanner refuses to run if they are not. Two websites are distinguished by their registrable
domain, so two tenants of a shared host are two different sites. The browser identifies itself
with its own User-Agent plus ConsentVeilMonitor/<version> (+https://www.safeandinformed.com/monitor),
printed in every report, so a site owner can recognise and rate-limit it.
Two tests read site state that only the scanner may read: the IAB TCF consent string through
__tcfapi, and Google Consent Mode commands from the page's dataLayer. One test opens the
banner's settings layer and presses keys to measure keyboard reachability; no accept, reject,
save or close control is ever used by these probes, and every toggle is read, never changed. The
free ConsentVeil browser extension does none of this and shares nothing with the scanner.
Supported browsers: Chromium (headless) and WebKit; Firefox only where available, included in the Order and able to pass the required start-up checks.
| Recorded | Detail |
|---|---|
| Network requests | URL, method and resource type, the stage of the scan in which each occurred, classification |
| Cookies | name, domain, path, expiry, flags, value length and whether the value looks like a token; the value itself is never written |
| localStorage and sessionStorage | key, value length, same rule: the value is never written |
| 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 | the count and a sample of browser console errors, visible text length, scrollability, named expected elements |
| Screenshots | the state of the page at each stage |
Before anything is written, redaction is applied to every output: credential-bearing headers are replaced, query parameters other than a short list of flags and labels are replaced (consent strings included, since they can carry identifiers), path segments that look like e-mail addresses or identifiers are replaced, and every URL, e-mail address and token-like value found anywhere in a report is redacted by the same rules. Header values, cookie values and storage values are not included in reports at all. The redaction is pattern-based: it does not claim to recognise every possible secret, and a value that matches none of the patterns is kept as text.
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 reloaded once in the same browser context to measure persistence. No further navigation is made. |
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.
Twenty 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 any request to a known tracking host follows the reject control in the same page view (the verdict). In addition, whether entries of known tracking providers written before the choice are still present after it: if so, a pass becomes a warning that names them; if storage could not be read, the pass stands and says "requests only". Other storage is listed, not judged | critical |
reject-control-reachable |
Whether a reject control exists at the same click depth as accept | medium |
refusal-persists |
Whether any request to a known tracking host follows one reload of the same page in the same browser context, immediately after the refusal. No further navigation, other page, later visit or other device is tested | 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 any request to a known tracking host follows the withdrawal in the same page view (the verdict). In addition, whether entries of known tracking providers present under consent are still present after the withdrawal: if so, a pass becomes a warning that names them; if storage could not be read, the pass stands and says "requests only" | 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 |
page-consistency |
Whether the same banner and the same pre-consent behaviour are observed on every page scanned (home, article, checkout) | medium |
tcf-signal-matches-choice |
On sites using the IAB TCF API: whether the consent string carries no consents after a rejection and the described consents after acceptance | high |
consent-mode-default-denied |
On pages using Google tags: whether a Consent Mode default of denied for ad_storage and analytics_storage is present, whether it precedes the first Google tag entry in the order of the dataLayer entries (the network load order is not measured), and whether an update follows the choice |
high |
banner-accessible |
Whether the banner has a dialog role and a name, whether every control is reachable with the keyboard, and whether Escape is treated as acceptance | medium |
second-layer-preselection |
Whether non-essential categories or legitimate-interest toggles are pre-selected in the settings layer, read without changing them | medium |
Each test carries its own limitations into the report. They are reproduced with the finding, not hidden in an appendix.
The primary page is scanned in every agreed browser-and-locale combination; each additional page is scanned once, in the primary combination that ran. In Re-scans and Monitoring, each report is compared only with its same-named report of the previous scan of the same scope under the same methodology version; a report that is missing or not like-for-like is reported as a lost result, never as a regression.
| 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.
Severity is fixed per test and does not vary by customer or service. 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. The score
therefore describes only the included results: a scan in which one eligible test passed and every
other test was unsupported or not requested scores 100, so a high score does not demonstrate broad
coverage. Inconclusive results stay in the denominator and are reported separately, so a test that
did not complete lowers the score rather than being ignored. Every report shows, beside the score,
how many tests were included, inconclusive, unsupported and not requested.
The score is not a grade, not a certification and not comparable between sites or between scans with different configurations. A report that lists the configuration is the real result; the score is a summary for people who read one number.
These apply to every scan and appear in every report:
Additional limitations specific to a test are printed with that test's 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.
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.
Newest first.
| Version | Date | Change |
|---|---|---|
| 0.3.0 | 2026-10-20 | reject-all-effective and withdrawal-stops-tracking gain a storage part: entries of known tracking providers still present after the choice turn a pass into a warning; the request verdict is unchanged. refusal-persists described as what it is: one reload in the same context. Consent Mode "before any tag" described as dataLayer entry order. Redaction extended to every string in every output. Test count corrected to twenty. |
| 0.2.0 | 2026-10-20 | Five tests added: page consistency, TCF consent string, Google Consent Mode default, banner accessibility, second-layer pre-selection; cookie and storage inventory table added to reports. |
| 0.1.2 | 2026-10-19 | Verification made mandatory with four named methods; exclusion register; evidence list corrected. No test or status changed. |
| 0.1.1 | 2026-10-19 | Connections checked before they are made; off-site navigations refused; values never stored; consent-string parameters and identifier-like path segments redacted; ownership method recorded; scanner User-Agent token; browser and locale matrix. No test or status changed. |
| 0.1.0 | 2026-10-19 | First published methodology: 15 tests, five flows, six statuses, the score formula above. |