Version: 1.4
Last Updated: February 18, 2026
Under the European Union's GDPR and other select regulations (e.g., Africa, Asia and Canada), explicit consent is required for any cookies that are not related to the functionality of the Website. Essentially, this means any cookies should be blocked on the user's browser if it does not fall under the category of strictly necessary cookies and until the user has given their explicit consent to use them.
If the user has given no prior consent or chooses to reject the use of all cookies that are not strictly necessary/required, then all these cookies should be blocked and data should not be collected from the user.
The CCM Auto-block feature enables you to block the HTML tags that can potentially drop cookies on your Website until the users have given consent. This feature blocks non-required 1st Party and 3rd Party tags (also referred to as Trackers) from firing until the user opts-in to any cookie category or vendor. This requires a user's consent before execution. The CCM Auto-block feature supports script, iframe, and img tags.
In cases where these 3rd party tag types: script, iframe, and img, do not have an src attribute, a Manual Block Implementation is provided to allow our customers to identify and add these other tags to the Auto-block functionality.
The following sections in this document provide the steps on how to set up the Auto-block functionality.
Below is a user flow chart based on how Auto-block works. Upon initial load, the Auto-block feature identifies whether a 1st Party or 3rd Party Tag is set for Manual Block or Auto-block. Here is how it works:
The next sections of this guide outline the steps on how to set up the Auto-block feature and validate its intended function.
This section covers the steps on how to set up the Auto-block feature for your domain. Please reach out to your Technical Account Manager to acquire the Autoblock scripts.
To set up Auto-block, follow these steps:
core.min.js – This script contains the Auto-blocking core functionalities which can block script, img, and iframe tags from being executed or loaded. This script must be placed before the blocklist.min.js.
<script src="https://consent.trustarc.com/autoblockasset/core.min.js?domain=<DOMAIN-NAME>&country=<COUNTRY-CODE>"></script>
blocklist.min.js – This script contains the customer's list of categories and domains. Once this script is loaded, it will kickstart the process of Auto-blocking.
<script src="https://consent.trustarc.com/autoblockoptout?domain=<DOMAIN-NAME>&country=<COUNTRY-CODE>"></script>
Example:
<!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Cookie Auto Blocker Test Page</title> <!-- These script tags will NOT be detected by the auto-blocker --> <script></script> <script src="https://consent.trustarc.com/autoblockasset/core.min.js?domain=truste.com&country=gb"></script> <script src="https://consent.trustarc.com/autoblockoptout?domain=truste.com&country=gb"></script> <script src="https://consent.trustarc.com/consent.trustarc.com/notice?domain=truste.com&c=teconsent&js=nj¬iceType=bb&pcookie"></script> <!-- This script tag will be detected by the auto-blocker and will be checked if it needs to be blocked --> <script></script> </head> </html>
This section covers the steps on how to set up the Manual block feature for your domain.
This feature was provided to allow the customers the additional option to block 3rd party tags without an src attribute in the declaration.
In order to manually block a tag with src, set the script type of the tag script to ta-blocked. This only blocks scripts that you select to be blocked and suspends the load of the tag on your website until consent is given. Note that this script should be placed below the Auto-block script.
<!-- This is a manually blocked script tag with src and will not be executed until the user opts-in for the domain google.com --> <script type="ta-blocked" src="https://google.com/script.js"></script> <!-- This is a manually blocked script tag without src and will not be executed until the user submits a consent --> <script type="ta-blocked"></script>
If you want to set a domain for a script tag that has no src attribute so that it can be unblocked if the user opts-in for that domain, then set the domain to the attribute data-ta-domain. Note that this script should be placed below the Auto-block script.
<!-- This is a manually blocked script tag with a domain and will not be executed until the user opts-in for the domain, for example, google.com --> <script type="ta-blocked" data-ta-domain="google.com"> // some code here </script>
If you want to block a CSS from executing via a link tag, you can do the following
<link href="https://example.com/style.css" rel="stylesheet" />
Replace with
Result:
<script type="ta-blocked" data-ta-domain="example.com">
(function() {
var link = document.createElement('link');
link.rel = 'stylesheet';
link.href = 'https://example.com/style.css';
document.head.appendChild(link);
})();
</script>
Auto-block can automatically unblock tags when a user consents, but a page reload is needed to block tags.
Page reload after submitting consent choice from Modal window and Banner
Include the following script along with your CCM script to induce a page reload when the customer opts out via the modal popup window or from the cookie banner. This can reside in the HEAD tag or can be loaded via a tag manager.
<script>
window.addEventListener("message", function(event) {
var eventDataJson = null;
// We only care about TrustArc Events at this point. And TrustArc's even it encoded in JSON
try {
eventDataJson = JSON.parse(event.data);
} catch (e) {
// Some other event that is not JSON.
// TrustArc encodes the data as JSON
// console.log(event.data);
}
// Safeguard to make sure we are only getting events from TrustArc
if (eventDataJson && eventDataJson.source === "preference_manager") {
// Means that the user has submited their preferences
if (eventDataJson.message === "submit_preferences") {
setTimeout(function() {
window.location.reload();
}, 20);
}
}
}, false);
</script>
The AutoBlock Strict Mode introduces an additional layer of proactive privacy protection by applying a deny-by-default approach to unfamiliar or non-approved domains.
When enabled, Strict Mode automatically blocks any domain that has not been explicitly approved or categorized in your Consent Manager's tracker list. This ensures that newly introduced or unknown technologies do not execute until they are formally reviewed and classified.
When disabled (default behavior), AutoBlock continues its standard behavior:
Strict Mode can be enabled at the Location Settings level:
This allows you to apply stricter enforcement rules based on jurisdictional requirements. Reach out to your Technical Account Manager (TAM) to enable this.
Below outlines how Strict Mode behaves based on your AutoBlock configuration.
1. AutoBlock Setting: Enable (Default Opted-In) [Standard Load – Strict Mode Enabled]
Before Consent:
After Consent:
2. AutoBlock Setting: Enable (Standard) [Zero Tracker Load – Strict Mode Enabled]
Before Consent:
After Consent:
3. AutoBlock Setting: Custom Selection [Strict Mode Enabled]
Before Consent:
After Consent:
4. AutoBlock Setting: Enabled (Default Opted-In) [Standard Load – Strict Mode Disabled]
Before Consent:
After Consent:
5. AutoBlock Setting: Enabled (Standard) [Zero Tracker Load – Strict Mode Disabled]
Before Consent:
After Consent:
This implementation is to provide an option to suppress verbose messages, enabling more efficient logging during production or in less critical environments. A mechanism is created where verbose logging only occurs when a specific flag is set in the localStorage. This flag can be set manually by the client or Technical Account Managers (TAMs) when they want to enable detailed Autoblock logs.
Clients or TAMs can enable verbose logging by manually setting the flag in the console. To do this, use the following command:
localStorage.setItem('autoblock:debug', 'true');
This section covers the steps on how to validate the Auto-block feature functions as intended.
To ensure that the cookies are blocked after Auto-block is configured for your domain, follow these steps.
core.min.js?domain=<domain-name>
autoblockoptout?domain=<domain-name>
Blocked Tags
Unblocked Tags
• For script tag, the type is set to "ta-blocked".
Example:
<script src="https://google.com/script.js" type="ta-blocked" data-ta-blocked="1"></script>
• For img tag, the actual src of the image is set to data-ta-src and the src will be empty.
Example:
<img src="" data-ta-src="https://google.com/image.png" data-ta-blocked="1" />
• For iframe tag, the actual src of the image is set to data-ta-src and the src will be empty. The srcdoc is also set to "<div></div>".
Example:
<iframe src="" srcdoc="<div></div>" data-ta-src="https://google.com/iframe.html" data-ta-blocked="1"></iframe>
If a user opts in to Functional Cookies or Advertising Cookies, then tags for these cookies should be unblocked or fired immediately. If a user opts out of Functional Cookies or Advertising Cookies, the tags will be blocked after the page is reloaded/refreshed.
Please refer to the User Flow section to see the complete control flow for testing purposes.
Below are some of the known limitations of the Auto-block feature.
<head> tag of the Website code. If it is installed under any other script, img, or iframe, the above script, img, or iframe cannot be blocked before loading.script, img, or iframe.• If a tag/tracker is listed in 2 buckets and one bucket selects opted-in for that exact tracker, then the default would be opted-in for all categories. It must be an exact match for this scenario to occur. The CCM will reflect the default settings of the opt-in or opt-out status of the vendor from the CCM UI regardless of the status of the Auto-block functionality in this case.
For example:
A user provides consent for Functional Cookies, but opts out of Advertising Cookies.
linkedin.com is in the Functional bucket, opted-in.
linkedin.com is in the Advertising bucket, opted-out.
ads.linkedin.com is in the Advertising bucket, opted-out.
linkedin.com will be opted-in because it has been double-listed.
ads.linkedin.com is opted out because it is single listed in the Advertising bucket and will adhere to the opted-out consent.
The CCM UI will reflect opted-in for linkedin.com (Functional bucket is opted-in if you only list bucket opt-outs) and opted-out for Advertising bucket.