Purpose-based consent: a missing layer in the browser

Why organizing privacy choices around purposes, not vendors, changes everything

The problem with consent today

There is no browser-level place where a user can say "I allow analytics but not ads on this site" and have it enforced consistently. Privacy choices today are scattered across per-site dialogs, each with different language, different categories, and different defaults. The result is not informed consent - it is consent fatigue.

Existing tools sit at two extremes. Content blockers operate on domains and filter lists: effective, but blunt. Consent management platforms (CMPs) operate per site and per vendor: flexible for the site, opaque for the user. There is no browser-level layer in between where you can express intent by purpose and have it enforced consistently across sites.

Why purpose-based

ProtoConsent organizes decisions around purposes of data use: functional, analytics, ads, personalization, third-party services, and advanced tracking. Not around vendors, cookies, or domains.

Purpose is the only abstraction that connects three things simultaneously:

• Regulation: major privacy frameworks organize consent around purpose limitation. GDPR, CCPA/CPRA, LGPD, PIPL, PIPA, and APPI all use purpose as the fundamental unit.
• Human comprehension: people think "I don't want ads tracking me", not "I don't want requests to doubleclick.net". Purpose maps to how users actually reason about their choices.
• Viable enforcement: purposes can be mapped to domain categories and filter rules that browser extension APIs can enforce at the network level.

A vendor-based model would fragment decisions across hundreds of entities. A cookie-based model would ignore network-level tracking. Purpose sits at the right level of abstraction.

Why browser-level

ProtoConsent places enforcement in the browser, not in the site or in a backend:

• No delegation to sites: enforcement does not depend on each site honoring preferences. The browser blocks requests before they leave your device.
• No backend: no central server, no accounts, no cloud sync. All state is local.
• Consistency: the same choice applies the same way across sites, rather than being re-negotiated per banner.

The browser is the only place where you can block requests, emit privacy signals like GPC, and show the user what happened, all without introducing new remote points of control.

Express, enforce, observe

ProtoConsent starts from a single premise: consent is only meaningful if the user can express it in understandable terms, enforce it technically, and observe its effects. If any of the three is missing, the system fails.

• Express: per-site profiles and purpose toggles let you say "on this site, allow analytics but deny ads" from a single popup.
• Enforce: the browser blocks requests associated with denied purposes before they leave your device. A conditional GPC signal is sent per site, with legal weight under CCPA/CPRA.
• Observe: blocked request counters, a real-time log, and per-domain purpose attribution show you exactly what enforcement does.

This creates a feedback loop: the user decides, the browser enforces, the user sees the result. Consent becomes a process, not a single click.

Enforcement is a means, not an end

ProtoConsent uses curated blocklists to enforce user choices, but blocking is not the goal: it is the mechanism that makes consent meaningful. The current core set is built from public blocklists, organized by purpose, with cross-source validation and an explicit safelist. Path-based precision (blocking google.com/pagead/ instead of all of google.com) prioritizes correctness over exhaustiveness.

Optional extended lists provide broader coverage with curated third-party sources for users who want it, without changing the core model.

Voluntary site cooperation

ProtoConsent supports two optional ways for websites to participate:

• Site declarations: a website publishes a .well-known/protoconsent.json file declaring its purposes, legal bases, and providers. The extension displays it alongside user preferences. It is a transparency signal, not enforcement evidence.
• SDK: websites can query the user's consent state per purpose and adapt their behavior accordingly. The SDK is read-only and returns null if no extension is present.

Both paths are optional. ProtoConsent works without any site integration. Sites that cooperate add transparency, not a requirement.

What ProtoConsent is not

• Not a full ad blocker: its goal is purpose-based consent enforcement, not exhaustive tracking coverage.
• Not a consent management platform: it does not manage consent on behalf of sites or negotiate with vendors.
• Not a VPN or anonymity tool: browser-level enforcement cannot prevent server-side processing or offline correlation.
• Not a legal compliance tool: it provides technical mechanisms for consent, not legal adjudication.

ProtoConsent adds a layer that didn't exist: a personal consent control panel in the browser, organized around purposes, that can work alongside the tools you already use.

Try it

ProtoConsent is free and open source (GPL-3.0+ for the extension, MIT for the SDK). Available on the Edge Add-ons Store. Try the live demo, or read the developer guide to integrate your site.

Source: github.com/ProtoConsent/ProtoConsent