Consent before cookies: what enforcement actually means in the browser

The gap between asking and enforcing

On a typical site, the consent banner and the trackers load in parallel. The banner asks; the analytics script, the ad pixel and the session recorder do not wait for the answer. By the time a visitor clicks anything, _ga and _fbp are usually already set.

Opt-in regimes, GDPR and ePrivacy in Europe, DPDPA in India, do not ask whether you displayed a banner. They ask whether non-essential processing happened before consent. A banner that fires trackers while it asks is consent theatre, and regulators have been treating it that way.

What enforcement takes

Enforcement means the consent layer loads first and physically stands between the page and everything that follows. In CookieGate’s SDK that is four interception points inside the runtime interceptor, working together:

• Script creation: createElement is wrapped, so known trackers created dynamically are held before they get a src.
• Cookie writes: document.cookie is intercepted; non-essential writes are held until consent releases them.
• Network: fetch and XHR calls to known tracking endpoints are held.
• The DOM itself: a MutationObserver catches what slips past the wrappers: injected iframes park at about:blank, tracking pixels collapse to a transparent GIF.

The runtime interceptor is one of three enforcement surfaces. The markup you rewrite and a service worker on your own domain are the other two, as the platform page shows.

Two consequences of doing it this way matter more than the mechanism:

1. Reject means never loaded: not “loaded but supposedly inactive”. And cookies that already existed from earlier visits are deleted.
2. Unknown scripts default to blocked under opt-in regimes. If the classifier has not seen a script before, it waits at the gate rather than getting the benefit of the doubt.

Why the regulation is resolved server-side

One more piece is easy to get wrong: which law applies should not be decided by JavaScript in the visitor’s browser, where it can be tampered with or simply fail. CookieGate resolves the regulation on the server: by default from the site’s own country, or from each visitor’s location when visitor-location rules are switched on. With visitor-location rules, Mumbai gets the DPDPA, Munich gets the GDPR with ePrivacy, San Jose gets the CCPA/CPRA with the Global Privacy Control signal honoured, and where several laws overlap, the strictest value is kept for each dimension.

The decision, and the regulation in force at that moment, is then frozen into a hash-chained, HMAC-signed consent receipt. That last part is the point of the whole exercise: when a regulator asks what happened, “here is the signed chain” is a very different conversation from “here is a screenshot of our banner”.

The test worth running on your own site

Open a private window, load your site, and open the cookie inspector before touching the banner. If anything non-essential is already there, you have a banner, not a gate.