How ProtoConsent answers consent banners without touching the DOM

The banner problem

Consent management platforms (CMPs) are used by millions of websites to show consent banners. When you visit a site, the CMP checks for a cookie that records your consent. If it doesn't find one, it shows the banner.

Most tools that deal with banners take one of two approaches: they simulate clicks on banner buttons (fragile, depends on DOM structure) or they block the CMP script entirely (breaks sites that check __tcfapi for vendor compliance). Both are reactive: they wait for something to appear, then act.

The ProtoConsent approach: declare, don't interact

ProtoConsent takes a different path. Instead of interacting with the banner after it appears, it writes the consent cookie that the CMP expects to find before the CMP script even loads.

When a page loads, a content script runs at document_start (before any page JavaScript executes). It reads the user's purpose preferences and a set of CMP signature templates from extension storage. For each applicable CMP, it generates a valid consent cookie by replacing purpose placeholders with the user's choices and writes it to the document. When the CMP script loads a moment later, it reads its own cookie, sees a valid consent record, and skips the banner entirely.

The user's preferences are enforced without ever touching the DOM, without simulating clicks, and without waiting for the banner to render.

CMP signatures

Each supported CMP is described by a JSON signature that specifies the cookie name, a value template with purpose placeholders, and optional CSS selectors for the banner. A simplified example:

{
  "cookie": [{
    "name": "consent_status",
    "template": "groups=1:1,2:{analytics},3:{personalization},4:{ads}"
  }],
  "format": { "allow": "1", "deny": "0" },
  "selector": "#consent-banner"
}

The content script replaces {analytics}, {personalization}, and {ads} with 1 or 0 based on the user's choices. The result is a cookie that the CMP treats as a valid consent record.

ProtoConsent currently supports signatures for dozens of CMPs, including both widely-deployed frameworks and platform-specific consent implementations. The full list is maintained in the source repository.

Three layers of response

Cookie injection alone doesn't cover every case. Some CMPs use server-side consent mechanisms, some use localStorage, and some load asynchronously. ProtoConsent uses three complementary layers:

• Layer 1: Cookie injection - writes the consent cookie with the user's purpose choices. This is the primary mechanism and works for the majority of CMPs.
• Layer 2: Cosmetic CSS - injects CSS rules that hide known banner selectors (display: none !important). This is a safety net for CMPs where cookie injection is late or incomplete, and the only option for CMPs with server-side consent mechanisms.
• Layer 3: Scroll unlock - removes scroll-lock classes and inline styles that CMPs apply to prevent scrolling until consent is given. A MutationObserver watches for re-locking attempts for 10 seconds.

IAB TCF v2.2 TC String generation

For CMPs that read the euconsent-v2 cookie (the IAB Transparency and Consent Framework standard), ProtoConsent generates a valid TC String. The user's six purpose preferences are mapped to TCF's 24 purpose IDs, and the result is encoded as a base64url bitfield following the TCF v2.2 specification.

This means sites that check the IAB standard for consent status see a properly formatted consent record that reflects the user's actual choices, not a blanket "accept all" or "deny all".

Purpose-level control, not binary

Unlike most consent tools that treat banners as "accept" or "reject", ProtoConsent maps its six purposes to each CMP's specific categories. If you allow analytics but deny ads, the generated cookie reflects exactly that. The CMP sees a nuanced consent record, and the site can load analytics scripts while keeping ad trackers disabled.

This is possible because the signature system knows how each CMP maps purposes to cookie values. The extension doesn't need to understand the CMP's UI; it just needs to speak its data format.

Cookie cleanup and privacy

Injected cookies are deleted after 5 seconds. CMPs read their cookies synchronously during initialization (the first 1-2 seconds of page load). Once the CMP has read the cookie and decided not to show the banner, the cookie is no longer needed. Deleting it reduces HTTP overhead on subsequent requests and minimizes the consent cookie's lifetime.

Each page visit generates a fresh random UUID (via crypto.randomUUID()) for cookies that require one, so consent cookies cannot be used to correlate visits across navigations.

Comparison with other approaches

Limitations

This approach has honest limitations:

• Server-signed cookies: some CMPs use server-generated tokens that cannot be replicated client-side. ProtoConsent falls back to cosmetic hiding on these sites.
• Server-side consent: some platforms handle consent entirely via server endpoints. Cosmetic fallback applies.
• Site-specific tokens: some CMPs use site-specific identifiers that cannot be templated. Cosmetic fallback applies.
• Consent walls: sites that tie consent to a paywall are not circumvented by design.
• TC String vendor sections: the generated TC String has empty vendor consent sections. CMPs that check for specific vendor IDs may not fully accept it, though in practice CMPs read the purpose bits.

One piece of the puzzle

CMP auto-response handles the consent interface layer. ProtoConsent also enforces purpose choices at the network level, blocking requests associated with denied purposes via declarativeNetRequest before they leave the browser. A conditional GPC signal (Sec-GPC) is sent per site when privacy-relevant purposes are denied, carrying legal weight under CCPA/CPRA. Together, they form a layered system: the banner is pre-empted, the requests are blocked, and the site receives the user's preference as a standards-based signal.

ProtoConsent is free and open source (GPL-3.0+). See the source code on GitHub.