Technology 3 minutes read

Script blocking: why "beforehand" is the whole point

Most banner failures lie neither in the wording nor in the buttons, but in a tenth of a second: if a script starts before anyone could answer, the rest is beside the point.

The moment the browser reads a script address it opens a connection to it. At that instant the external server already learns three things: the IP address, the page being viewed, and technical characteristics of the device. All of this happens before a single line of the script has run.

The breach lies not in setting the cookie but in opening the connection. Both happen before the first click.

Three methods, one goal

From the most reliable to the retrofitted solution

  • Rewriting before executionThe blocker takes the place where the browser reads script tags and alters them: type="text/plain" instead of executable. The browser then sees mere text.
  • Marking in the sourceEvery script requiring consent is embedded as non-executable from the outset and carries a marker naming the purpose it serves.
  • Intercepting network callsThe functions scripts use to send data are temporarily replaced. Helps against stragglers, but not against the first request.
The three methods can be combined. The top layer is the most reliable because it needs no knowledge of the individual services; the bottom one is the most practical where third-party code cannot be touched.

The special case of embedded content

An embedded video or map is not a script but a window onto another site. That window, too, opens a connection when it loads – with the same consequences.

The usual answer is the two-click approach: instead of the window, a preview appears first, naming the provider behind it. Only a click on it loads the content. That is at the same time the clearest form of consent, because it happens at the moment of use and refers to exactly this one item.

The typical gaps

  • The tag manager. If it is not blocked itself, it loads whatever comes next – bypassing the block from the inside.
  • Fonts from external servers. They look harmless but transmit the same IP address as any other script.
  • Tracking pixels in e-mails and on subpages. Blocking works only where it is actually included.
  • Server-side forwarding. Reporting in the background rather than in the browser escapes any blocker – and consent is still required.

The last point deserves particular attention because it is growing. Where measurement data is forwarded from the site's own server, the browser shows nothing unusual – but the duty to obtain consent does not arise from visibility in the browser, it arises from access to the device and the processing that follows.

Published 15 August 2026 · last changed 2 September 2026

This article explains general principles and does not replace legal advice on an individual case.

Back to the overview