Prior blocking: stopping trackers before consent

The strictest requirement in EU consent law is also the most technical: non-essential trackers must not run until the visitor has agreed. Not “run but don't report”, not “load quietly and wait”, but actually not execute. Regulators have repeatedly found sites non-compliant because analytics or advertising tags set cookies before anyone clicked “accept”. Prior blocking is the engineering that makes “ask first” literally true.

The problem is that a browser is eager. The moment it parses a script tag it fetches and runs it; the moment it meets an image or an iframe it makes the request. By the time your banner appears, a normally-written analytics or advertising snippet has already executed and written its cookies. To block prior to consent, you have to intervene before the browser acts, not after.

The core technique is deceptively simple: change the script's type. A browser only executes a script whose type it recognises as JavaScript. If you rewrite type="text/javascript" to type="text/plain" — and record the real category in a data attribute — the browser downloads nothing and runs nothing; the tag is neutralised while still sitting in the page. When consent for that category arrives, the CMP builds a fresh script element, restores the source, and re-injects it so the browser runs it exactly as its author intended, just later.

Inline scripts, external scripts and tag-manager loaders are all handled the same way, but they have to be caught early. A blocker that runs after the page has loaded is already too late, so the CMP script must execute first — synchronously, in the head, ahead of everything it intends to govern. This ordering is the single most important detail in a prior-blocking setup and the most common thing people get wrong.

Scripts are not the only trackers. Tracking pixels are image tags, embeds are iframes, and both fire a network request from their source the instant they are parsed. Prior blocking neutralises these by moving the address into a placeholder attribute — the src is stashed in a data-cookieblock-src attribute and removed — so no request is made until consent restores it. Video and social embeds are handled the same way, which is why a blocked YouTube embed shows a placeholder until the visitor allows it.

A static page is easy; a dynamic one is not. Modern sites inject scripts and iframes after load — a tag manager adds tags, a single-page app mounts a widget, an A/B test rewrites a section. A blocker that only processed the initial HTML would miss all of it. The answer is to watch the DOM as it changes: Cookie Munch intercepts DOM insertion and runs a MutationObserver so new script, image and iframe nodes are caught and neutralised before they can act, however late they appear.

There are two ways to decide what to block, and good blocking uses both. The explicit way is tagging: you mark each script with the category it belongs to, and the CMP releases it when that category is consented. The automatic way is pattern matching: the CMP recognises known third-party domains — analytics, ad networks, social widgets — from a maintained list and blocks them even if you never tagged them, which catches the trackers a tag manager pulls in without your knowledge.

Some things resist clean blocking and deserve honesty. A script that uses document.write, a deeply obfuscated loader, or a first-party bundle that mixes essential and non-essential code in one file can be awkward to neutralise; the fix is usually to load trackers through a tag manager or to defer them, not to bury them in critical code. Recognising these cases is part of doing prior blocking properly rather than pretending everything is coverable.

This is also where prior blocking and Google Consent Mode differ, and why they are complementary rather than interchangeable. Consent Mode does not stop Google's tags from loading; it tells them to behave in a restricted, cookieless way until consent. Prior blocking actually prevents execution. In practice a good setup lets the Google Tag Manager container itself load and governs it through Consent Mode, while blocking the long tail of other third parties that have no consent signal of their own.

The categories are the contract. Every blocked tag belongs to a category — statistics, marketing, preferences — and consent is granted or withheld per category, so releasing tags is just a matter of unblocking each category the visitor allowed. A tag that lists more than one category is released only when all of them are granted. This is also what makes withdrawal work: when someone revokes a category later, the trackers tied to it stop being served on the next load.

Getting this right is what separates a banner that merely looks compliant from one that is. A cookie declaration, a preference centre and a tidy design mean little if the tags fired before the visitor answered. Prior blocking is the unglamorous layer underneath that makes the rest true, and it is the part auditors actually test — by loading the page and watching the network before clicking anything.

Cookie Munch does prior blocking by default. It loads first, rewrites non-essential script types to hold them, moves iframe and pixel sources into placeholder attributes, and intercepts DOM insertion with a MutationObserver to catch dynamically injected tags — releasing each category the instant its consent is granted and re-blocking it on withdrawal. Known third-party trackers are recognised and blocked automatically, and Google's tags are driven through Consent Mode v2, so trackers really do wait for “yes”, which is the whole point.