API Version

Blocking Cookies and Scripts

Overview

In an ideal world, the user accepts the purposes and 3rd parties a vendor uses, and the choices are made effective immediately.

Signatu provides a banner to provide these choices to the user (see Cookie Banner). When the user has made their choice, Signatu sends the consent event to the website, both within the user’s browser and server-side. So far so good.

However, what happens then is more complicated. The way website load scripts differ wildly. Some website uses a CMS such as Wordpress to inject some scripts on the server side, some load scripts directly in the Web browser using e.g., a Tag Manager or custom scripts, others use both server-side and client-side injection.

Signatu deploys several strategies to help you unload and/or block scripts based on the user choices. This page describes these strategies, and their limitations. Be aware that to achieve full cookie consent compliance may require you to make changes to your website.

Signatu will postMessage the current Consent Event to the main window when loaded from the Consent API, retrieved from browser cache, or the user makes a change to their settings. Websites can use this event to evaluate which resources it can load. For most small websites, designing custom code for this is not feasible, so an automated (but limited, see below) approach can be deployed instead.

DOM Controller

The Document Object Model (DOM) is the internal structure of a web page, which contains instructions to the browser on what scripts, iframes and pixels to load. Signatu will monitor changes to the DOM. When a script, iframe or pixel is injected into the DOM that is is not allowed according to the Signatu Consent Engine (e.g., because the user has refused), Signatu will try to prevent the script from loading. We use two methods for this - overriding the browser’s createElement method, and listening to DOM changes using MutationObserver.

The observant reader will notice that the Signatu DOM Controller code must be active before it can do any blocking, and any resources loaded before Signatu is active can potentially send data to 3rd parties. So in order to ensure that all scripts are being controlled Signatu must be allowed to fully load before any other scripts in the user’s browser. This may or may not be possible in practice, depending on your website implementation. It will also introduce a delay while the Signatu code initializes and evaluates the Consent status for the user.

Startup

When the DOM Controller runs it will initialize by analyzing the DOM resources and tag resources. If resources found should be blocked, Signatu will try to unload the tag by removing it from the DOM and re-injecting it with the blocked flag(s) set. Depending on the browser implementation this may or may not disable the script in the current session.

Tagger

When the DOM Controller detects requested changes in the DOM, e.g., a new script, it does not block it directly. Instead, it allows the resource to exist in the DOM, but will annotate the element with tags and change or remove the src and type tags to prevent loading. If the user makes changes to their setting Signatu will reverse this process, allowing the resource to load again.

Blocker

The Signatu Blocker will evaluate the user’s Consent event against a Cookie specification created by Trackerdetect, and determine whether a resource (script, iframe, pixel) can be loaded. If blocked, the blocker will mark up the resource with data-* tags, and move the src tag to data-src to defer loading of the resource. Here’s an example for Google Recaptcha blocked by the blocker:

<script
    type="text/plain"
    data-service="googlerecaptcha"
    data-autotagged="true"
    data-blocked="true"
    data-src="https://www.google.com/recaptcha/api.js"
></script>