How Airlock decides what is a leak.
Published in full, because a measurement nobody can check is a marketing claim. Everything below is what the scanner actually does, including the parts where it refuses to answer.
The four states
Every tag found on a storefront is sorted into exactly one of these. Three of them are not your problem, and saying so is the point.
| State | What it means | Whose problem |
|---|---|---|
| Blocked | The tag carries a genuine blocking attribute — a consent platform's own type
or data- convention that stops the browser fetching it. |
Nobody's. It works. |
| Managed | Present in the markup, but a consent platform is gating it through Shopify's Customer Privacy API. Static analysis cannot see this; only a live scan can. | Nobody's. It works. |
| Leaking | Ungated, and reachable — it lives in your theme or your tag manager, where a consent manager can intervene. | Yours, and fixable today. |
| Unreachable | Ungated, and no client-side consent manager can stop it. | Structural. See below. |
Why "unreachable" exists
Shopify renders theme app blocks into the HTML on the server. By the time the browser has the document, the tag is already in it, and the browser's preload scanner begins fetching subresources before the main thread has executed a single line of JavaScript.
A consent manager is JavaScript. It runs after that. It can gate a tag you pasted into your own theme, because it can be placed ahead of it. It cannot gate a tag a different app told Shopify to emit, because there is no moment at which it runs first. This is not a defect in any consent platform, and Airlock does not report it as one.
The only fix is to change what the server emits. That is what the Airlock gate does: it
re-emits the captured block with every fetching tag inert — type="text/plain", real
URL parked in data-src — and swaps them for live tags when, and only when, Shopify's
own Customer Privacy API reports consent for that category.
Attribution is by emitter, never by destination
Asking "which vendor does this request go to?" is the wrong question, and answering it is how a scanner gets fooled. Vendors increasingly serve from first-party subdomains of the merchant's own domain, so the destination looks like the store itself.
Airlock attributes by which block of markup emitted the tag. It indexes the byte offsets of every app block in the served HTML and asks which block a given tag falls inside. A tag cloaked behind a first-party CNAME is still emitted by a specific app's block, and that is the fact worth reporting. Where two blocks overlap ambiguously, Airlock refuses to attribute rather than guess.
The consent protocol: five states, each verified
The scan on the front page is what happens before anyone answers. The consent protocol asks the harder question — whether answering changes anything.
- Pre-consent. A fresh browser, no prior cookies, nothing clicked.
- Accept.
- Refuse. The state most cookie enforcement decisions turn on.
- Withdraw. Consent granted, then revoked. Traffic after the revocation instant is measured separately, because Art. 7(3) makes withdrawal as easy as granting.
- Global Privacy Control. California has required a response to this signal since 1 January 2026.
Each state runs in its own fresh browser context. The answer is imposed through the store's own Customer Privacy API — the store's real machinery runs, listeners fire, queued tags release — and then it is read back. If the readback does not agree with what was demanded, that state is excluded from the report entirely rather than reported with a caveat.
n/a and names the
excluded state instead of printing a figure it does not stand behind.Vantage: every runtime number is a statement about one place
Consent platforms geolocate by IP and ignore browser locale. A scan that presents as
en-GB but egresses from Virginia measures what a visitor in Virginia sees — not what
a European sees — and Airlock says so on the report, in those words, every time.
It also asks the storefront where it thinks you are, through the same Customer Privacy API. If the store's own answer is that no banner is required for this visitor, then the absence of a banner is the store behaving correctly, not a finding. That single check is the difference between a report that survives a technical review and one that gets refuted in the first sales call.
What Airlock will not tell you
- Whether you are compliant. That depends on your configuration, your geo-gating, and how you document consent. Airlock reports what it measured. It is not a lawyer and does not pretend to be one.
- What happens on pages it cannot reach. Public pages only. Nothing is clicked, no banner is answered, no account is created.
- Anything it did not observe. A static scan says "present and ungated", not "fired". Only a live scan converts that into an observation, and when the live scan fails, the report says the live scan failed rather than quietly falling back.
- Global Privacy Control acknowledgement, with confidence. That one check is a text search of the rendered page. A store may satisfy the duty in wording it does not anticipate. Not finding an acknowledgement is not proof there is none, and the report says so wherever it appears.
Evidence you can hand to somebody else
Every finding is reproducible from the report: the vendor, the block that emitted it, the millisecond it fired, the vantage it was measured from, and the consent state in force. For findings that need to survive a dispute, Airlock can produce a Proof Pack — the exchanges content-addressed by SHA-256, a canonical JSON manifest, an Ed25519 signature, and an RFC 3161 timestamp from a public authority, so the measurement can be shown to have existed at a time neither party controls.
← RUN A SCAN