Blocking Modes: Automatic vs Manual

MineOS CMP can block cookies, scripts, and trackers on your website in two complementary ways:

• Automatic blocking (default) — MineOS automatically blocks the specific scripts and elements identified by the website scanner, with no changes required to your site's HTML.
• Manual blocking — You add data-cookieconsent attributes to elements in your HTML, telling MineOS exactly which elements to block and which categories they belong to.

These two modes are not mutually exclusive — by default they run side by side, and you can mix them however you need. This article explains how each works, when to use each, and how to switch between them.

📘

TL;DR

Start with automatic blocking. It works out of the box on most sites. Use manual blocking (data-cookieconsent) to fill in any gaps the scanner couldn't reach — and use data-cookieconsent="ignore" to explicitly exempt a script you never want blocked.

Automatic blocking (default)

When you install MineOS CMP on your site, automatic blocking is on by default. There's nothing to configure in your HTML — the CMP uses the results of your most recent website scan to know what to block.

How it works

1. The Website Scanner crawls your site and identifies every cookie, script, iframe, image, and other tracker.
2. Each cookie and tracker is classified into a consent category (Essential, Functional, Analytics, Marketing).
3. When you Publish your configuration, MineOS bakes the scanner's findings into the configuration delivered to your visitors' browsers. This includes a list of CSS selectors for the elements that need blocking.
4. On every page load, MineOS CMP intercepts script and element creation. When it sees an element that matches a tracker in your published configuration, it holds the element back until the visitor grants consent for that category.
5. As soon as consent is granted (via the banner), the held elements are released and execute normally.

What gets blocked automatically

• <script> tags loaded from a known tracker URL
• <iframe> tags from known tracker domains
• <img> tracking pixels
• <link>, <embed>, and <object> tags pointing to known trackers
• HTTP cookies with names matching the known-cookie dictionary (cleaned up if they appear before consent)

This covers elements added in the original HTML, elements inserted dynamically with JavaScript (document.createElement, appendChild, innerHTML, etc.), and elements injected via document.write().

Pros and cons

Pros

• Zero code changes. No edits to your site's HTML or templates.
• Always in sync with the scanner. As your scan results change, the blocking list updates automatically on the next publish.
• Comprehensive. Catches dynamically inserted trackers, not just static ones.

Cons

• Only blocks what the scanner found. Trackers that only appear after specific user actions (e.g. completing a checkout) may not be in the scan results.
• Selector-based. If a third-party tracker changes the URL of its script, the existing blocking selector may stop matching until the next scan.

Manual blocking with data-cookieconsent

Manual blocking gives you explicit control: you mark elements in your HTML with a data-cookieconsent attribute, and MineOS blocks them based on whatever you specify. This works whether automatic blocking is on or off.

Syntax

Add a data-cookieconsent attribute with a comma-separated list of cookie categories. The element will be blocked until the visitor grants consent for all the listed categories.

<!-- Block until Analytics consent is given -->
<script src="https://example.com/analytics.js" data-cookieconsent="Analytics"></script>

<!-- Block until BOTH Marketing AND Analytics consent are given -->
<iframe src="https://example.com/widget" data-cookieconsent="Marketing, Analytics"></iframe>

<!-- Block a tracking pixel until Marketing consent is given -->
<img src="https://tracker.example.com/pixel.gif" data-cookieconsent="Marketing">

Behavior details

• Categories are case-insensitive and whitespace-tolerant. Analytics, analytics, and ANALYTICS are all valid.
• Multiple categories use AND logic. If any category in the list is not consented, the element stays blocked.
• Valid categories: Necessary, Preferences, Analytics, Marketing, Unclassified.
• Manual markup takes precedence over automatic blocking. If you mark an element with data-cookieconsent, the categories you specify are used — not whatever the scanner inferred.
• Necessary and Unclassified are never blocked. Tagging an element with these categories has no effect (the element loads immediately).
• Inline scripts (no src attribute) cannot be blocked. Use external script files if you need them gated by consent.

Excluding an element with data-cookieconsent="ignore"

If you have a script that you never want blocked — for example, a critical first-party script that automatic blocking is incorrectly catching — add data-cookieconsent="ignore":

<!-- This script will always load, regardless of consent state -->
<script src="https://your-site.com/critical.js" data-cookieconsent="ignore"></script>

ignore wins everywhere: the element is never blocked by automatic blocking, never blocked by category-based manual blocking, and never re-blocked when consent is withdrawn.

Pros and cons

Pros

• Explicit and predictable. You decide exactly what's blocked and into which category.
• Works for trackers the scanner can't see. If a tracker only fires under specific conditions, you can tag it in HTML rather than wait for the scanner to catch it.
• Survives URL changes. Blocking is based on the tag itself, not the URL — if a third-party tracker changes its CDN, your manual markup keeps working.
• Override-friendly. Lets you reclassify an element if you disagree with the scanner's category assignment.

Cons

• Requires code changes. You need to edit your site's HTML or templates.
• Easy to forget. New scripts added later won't be blocked unless you remember to tag them.
• Doesn't cover dynamically inserted third-party scripts that you don't write yourself (those still need automatic blocking).

What happens when consent changes

Whichever mode catches an element, the release flow is the same:

When consent is granted (visitor clicks Allow All, accepts a specific category, or interacts with the page in Soft Opt-in mode):

1. MineOS updates the stored consent state.
2. Blocked <script> tags are restored and re-inserted in DOM order so they execute.
3. Blocked attributes on other elements (e.g. an iframe's src) are restored.
4. Any queued cookie writes are replayed.

When consent is withdrawn:

1. The consent state is updated.
2. Elements that depend on the withdrawn category are re-blocked.
3. Cookies associated with the withdrawn category are removed.
4. The page reloads (or the visitor is prompted to reload) so the change takes effect cleanly.

When to use which mode

Disabling automatic blocking

If you want to rely exclusively on manual data-cookieconsent markup, add data-auto-blocking="disabled" to the MineOS CMP script tag in your site's HTML:

<script src="https://cmp.mineos.ai/dg-xxx/configuration.js"></script>
<script src="https://cmp.mineos.ai/cmp.js" data-auto-blocking="disabled"></script>

What stays on when automatic blocking is disabled:

• The consent banner displays normally and collects consent
• data-cookieconsent markup on individual elements is still honored — tagged elements are blocked until their categories are consented to and unblocked afterwards
• All blocking interceptors still install, so even dynamically inserted tagged elements are caught
• Consent storage, analytics events, GPC (Global Privacy Control) handling, and Google Consent Mode are all unaffected

What turns off:

• Scanner-derived blocking (the list of CSS selectors from your published configuration)
• The known-cookie dictionary
• The HTTP cookie cleanup sweep that removes pre-existing cookies after page load

🚧

Disable automatic blocking with care

When automatic blocking is off, anything you don't explicitly tag with data-cookieconsent will load freely on every page — including third-party scripts you may not control. Make sure your manual markup is complete before turning automatic blocking off.

Combining both modes (recommended)

For most websites the best setup is both modes running together, which is the default:

• Let automatic blocking handle the bulk of trackers — it's comprehensive and self-updating.
• Use data-cookieconsent to override specific elements when you need finer control, fix mis-categorized trackers, or cover scripts the scanner doesn't see.
• Use data-cookieconsent="ignore" to whitelist anything that must always load.

In this mode, MineOS uses the following precedence for each element:

1. If the element has data-cookieconsent="ignore" → never blocked.
2. If the element has any other data-cookieconsent="..." value → blocked according to the categories you specified.
3. Otherwise → blocked according to the scanner-derived configuration.

Frequently asked questions

Will tagging an element with data-cookieconsent block it even if my scanner didn't find it? Yes. Manual markup blocks the element regardless of what the scanner found — that's exactly the case it's designed for.

What if I tag an element with the wrong category? Whatever you specify wins. If you tag a Marketing tracker with Analytics, the element will only be blocked until Analytics consent is given. Double-check your tags against the actual purpose of each tracker.

Does manual blocking work with dynamically inserted scripts? Yes — as long as the script element has the data-cookieconsent attribute when it's inserted into the DOM. MineOS catches it the same way it catches statically embedded scripts.

Can I use data-cookieconsent on inline scripts (without a src)? No. Inline scripts can't reliably be categorized or paused, so MineOS doesn't block them. If you need an inline script gated by consent, move its body into an external file and reference it with a src.

Does data-cookieconsent="ignore" work even when automatic blocking is on? Yes. ignore wins everywhere — it's the simplest way to whitelist an element that the scanner is incorrectly catching.