How browser extensions can query the user's consent state via a standard protocol

The problem: privacy tools that can't talk to each other

The browser extension ecosystem has ad blockers, cookie managers, fingerprint protectors, and VPN clients. Each makes decisions about user privacy independently. None of them knows what the others are doing, and none of them knows what the user actually wants at the purpose level.

If an ad blocker wants to know whether the user has allowed analytics on a given site, there's no way to ask. If a cookie manager wants to check whether the user has denied ads, it has to implement its own consent model. Every privacy extension reinvents the same wheel, and the user has to configure each one separately.

A read-only consent API

ProtoConsent exposes an inter-extension API that lets other browser extensions query the user's consent state. The protocol uses chrome.runtime.sendMessage with ProtoConsent's extension ID as the target. The API is read-only: consumer extensions can read preferences but never modify them.

Two message types are supported:

• Capabilities discovery: the consumer asks what the provider supports (protocol version, available purposes).
• Consent query: the consumer asks for the user's consent state on a specific domain. The response contains all six purposes as booleans, plus the active profile name.

A consent query looks like this:

// Query
{ "type": "protoconsent:query", "domain": "example.com" }

// Response
{
  "type": "protoconsent:response",
  "domain": "example.com",
  "purposes": {
    "functional": true,
    "analytics": false,
    "ads": false,
    "personalization": true,
    "third_parties": false,
    "advanced_tracking": false
  },
  "profile": "balanced"
}

One domain per request. No bulk queries. The response contains only the fixed six-purpose schema, a profile name, and a version string.

Trust on first use

The API is disabled by default. The user must explicitly enable it in ProtoConsent's settings. Even then, each consumer extension must be individually approved.

On first contact from an unknown extension, ProtoConsent stores a pending authorization request and responds with a need_authorization error. The user can then approve or deny the extension from the settings UI. This is a TOFU (Trust on First Use) model: no extension gets access without the user's explicit approval.

• Approved extensions are stored in an allowlist.
• Denied extensions are moved to a denylist. Future messages from denied extensions are silently dropped, giving no signal that ProtoConsent is active.
• The pending queue is capped at 10 entries to prevent flooding.
• A global cooldown limits new unknown extension IDs to 3 per minute.
• Approved extensions are rate-limited to 10 requests per minute.

Why this matters

Privacy tools today are silos. Each one has its own model of what the user wants, its own configuration UI, and its own enforcement rules. The result is duplication, inconsistency, and cognitive load for the user.

An open consent API changes this. A cookie manager could check whether the user has allowed analytics before deciding what to clean. A content blocker could query purpose preferences before applying its rules. A fingerprint protector could adapt its behavior based on whether the user has denied advanced tracking on a given site.

The user configures their preferences once, in one place. Other tools read those preferences and adapt. That's composable privacy: tools that work together instead of side by side.

Security by design

The protocol is designed to be safe by default:

• Read-only: there is no code path from external messages to storage writes or rule changes.
• Sender verification: sender.id is provided by the browser and cannot be forged.
• No intrusive prompts: authorization requests are queued silently and reviewed at the user's discretion. No popup windows, no clickjacking vectors.
• Observable: all inter-extension events (successes, errors, rate limits) are visible in the extension's log, timestamped and color-coded.

Cross-browser compatibility

The protocol works identically on Chrome and Firefox. Both support chrome.runtime.onMessageExternal and runtime sender verification. ProtoConsent omits externally_connectable from the manifest, giving open access on both browsers. Security is enforced at runtime (opt-in, allowlist, rate limiting), not at the manifest level.

Try it

A minimal test consumer extension is available in the source repository under examples/test-consumer/. It sends capabilities queries, consent queries, invalid inputs, and rate-limit tests, and logs responses in a popup panel.

ProtoConsent is free and open source (GPL-3.0+). The inter-extension protocol is part of the draft specification and open to feedback.