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.
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.
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
and listening to DOM changes using
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.
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
type tags to prevent loading. If the user
makes changes to their setting Signatu will reverse this process, allowing the resource to load again.
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
defer loading of the resource. Here’s an example for
Google Recaptcha blocked by the blocker: