Post-withdraw script behavior

Overview

This page documents the actual CookieShift CMP (cmp.js) behavior when a visitor grants consent, withdraws consent, or changes categories. It is operational guidance for publishers—not legal advice.

CookieShift does not claim that withdrawing consent can technically undo every already-executed third-party script in the browser.

Before consent (typical opt-in / GDPR-style)

Until the visitor decides (and for categories that remain denied):

• Non-essential scripts that CookieShift can classify and intercept are held (for example converted to type="text/plain" placeholders or queued as blocked).
• New document.cookie writes for denied non-essential categories are blocked by the CMP cookie setter override (when enforcement is active).
• Necessary / allowlisted services configured for the property continue to run.

Exact blocking depends on install order, law mode (opt-in vs opt-out), script rules, and whether tags load before cmp.js.

After consent is granted

When the visitor accepts categories (Accept all, Customize save, or equivalent):

1. Consent state is updated immediately in memory and persisted locally.
2. A new Consent ID is minted for the decision (immutable decision record style).
3. Deferred / blocked scripts for granted categories may be activated (placeholders become executable scripts; queued blocked scripts may execute).
4. Google Consent Mode / integration signals are updated when those integrations are enabled.
5. Events fire (including internal consent_given and browser CMP_CONSENT_UPDATED).
6. The decision is sent to CookieShift consent logging when telemetry is enabled for the property.

No full page reload is required for these steps.

After withdrawal or category revoke

Withdrawal means the visitor uses Reject all, turns categories off in preferences, or otherwise saves a decision that removes previously granted analytics / marketing / preferences.

What updates immediately

Known first-party cookies CookieShift attempts to expire

When analytics or marketing consent is revoked, CookieShift attempts to expire a fixed list of common first-party cookie names via Max-Age=0 on likely host/domain variants (for example analytics names such as _ga, _gid, and marketing names such as _fbp, _fbc).

In practice this is best-effort and not guaranteed:

• Only those known names are targeted—not every cookie on the site.
• After withdrawal, the CMP cookie setter also blocks new writes (including some expiry writes) for denied non-essential categories once enforcement is active, so a previously set cookie may remain in the browser until it expires on its own, the visitor clears site data, or a reload/navigation path removes it.
• Publishers should not claim that CookieShift automatically deletes all cookies on withdraw.

What CookieShift does not do on withdraw

• It does not unload or stop already-running third-party JavaScript that was activated while consent was granted. Those scripts may continue in the current page session until navigation/reload (or until the vendor’s own code stops).
• It does not delete every cookie on the domain—only the known names listed above (best-effort).
• It does not erase data already collected by third parties before withdrawal.
• It does not require a reload, but a reload is the practical way to drop in-memory trackers that already ran.

Subsequent navigation / reload

After reload or later visits, stored consent remains withdrawn for those categories, so CookieShift continues to block future non-essential loads and cookie writes according to the saved decision—until the visitor grants consent again.

Consent granted again

If the visitor later grants categories again:

• Consent state updates immediately again (new Consent ID).
• Deferred / blocked scripts for newly granted categories can activate again.
• Cookie writes for those categories are allowed again (subject to classification and rules).
• Events and consent logs record the new decision.

Publisher checklist

1. Load cmp.js early (before non-essential tags) so first-visit blocking can work.
2. Prefer Consent Mode / tag-manager consent triggers so tags honor update after withdraw.
3. Test: grant → withdraw → confirm network/cookies for new activity; confirm already-injected scripts may still be present until reload.
4. Do not claim “all scripts instantly stopped” or “all cookies automatically deleted” in customer policies unless your own stack does more than CookieShift’s CMP.

Related

• Consent Modes
• GDPR Guide
• Cookie Categories
• Google Consent Mode