Article 88b can make digital rights operational.
ADPC is the rights-first implementation path. Not a narrow opt-out flag, but an open communication layer for consent, refusal, withdrawal and objection, designed around the legal grammar of the GDPR and ePrivacy framework.
Where Article 88b
stands now.
Article 88b is part of the European Commission’s Digital Omnibus proposal, COM(2025) 837 final. It is proposed legislation, not yet enacted law.
The provision would insert a new GDPR article on automated and machine-readable indications of data subjects’ choices with respect to processing of personal data in the terminal equipment of natural persons.
The EDPB and the EDPS strongly welcomed the idea of Article 88b, while recommending important improvements on defaults, scope, standards, SME browser providers, media-service exceptions and enforcement.
ADPC should therefore be understood as an existing implementation ecosystem for the Article 88b era, while Article 88b itself should be described accurately as proposed legislation.
Commission proposal
COM(2025) 837 final. Digital Omnibus proposal introducing Articles 88a, 88b and related changes.
Article 88b
Proposed GDPR provision for automated and machine-readable consent, refusal and objection.
Joint Opinion 2/2026
EDPB-EDPS strong support, with targeted safeguards and clarifications on defaults, scope and enforcement.
Why Article 88b
is needed.
Not human-compatible
The current model asks people to manage fundamental rights through thousands of service-specific banners. It assumes users can repeatedly read legal notices, compare purposes and resist manipulative interface design across many services and devices.
Real costs for organisations
Controllers, publishers and SMEs must repeatedly design, maintain and defend consent interfaces that still often produce legally fragile or user-hostile outcomes.
Architectural weakness
Rights such as consent, refusal, withdrawal and objection are largely exercised through interfaces controlled by the very actors requesting access to data. Users rarely have durable records, consistent controls or practical support tools.
What proposed Article 88b
would do.
Proposed Article 88b would require controllers to make their online interfaces capable of receiving automated and machine-readable choices. People should be able to give consent, decline a consent request and exercise the right to object through a technical mechanism rather than through a fresh banner on every site.
Controllers would have to respect those choices. The Commission would request European standardisation organisations to draft harmonised standards for interpreting machine-readable indications of choice. Interfaces that comply with those standards would benefit from a presumption of conformity.
The proposal is technologically neutral. It refers to communication from browsers to websites and from mobile applications to web services. Read together with proposed Article 88a, Article 88b is not just cookie-banner simplification. It is a pathway from rights, to standards, to implementation.
Article 88b covers:
- —Automated and machine-readable consent
- —Automated refusal of consent requests
- —Automated and machine-readable objection
- —Controller obligation to respect expressed choices
- —European standards for interpreting machine-readable indications
- —Presumption of conformity for harmonised-standard-compliant interfaces
- —A future-ready legal opening for browsers, apps, wallets, operating systems, CMPs and AI-assisted tools
How ADPC fulfils what the Commission
expects from Article 88b.
The Commission’s materials point to a clear set of expectations: reduce cookie fatigue, preserve user control, enable automated machine-readable choices, support standards and keep strong GDPR-level protection. ADPC maps onto each of these expectations.
| Commission expectation | What it means for Article 88b | How ADPC fulfils it |
|---|---|---|
| Reduce cookie-banner fatigue | Users should not have to repeat the same privacy choices through thousands of banners. | ADPC moves the interaction into a reusable user-side communication layer. A browser, extension, assistant or other user-trusted tool can remember and resend valid choices rather than forcing fresh banner clicks. |
| Keep people in control | Simplification must not weaken rights. People must still be able to decide what happens to their devices and data. | ADPC supports explicit consent, refusal, withdrawal and objection. It helps users see, store, revise and communicate decisions through user-side tools rather than relying only on controller-controlled interfaces. |
| Enable one-click choices and central settings | The Commission expects easier yes/no choices and central preference management, for example through browser settings. | ADPC is designed for browser and comparable user-agent interaction. It can support simple choices where appropriate while preserving more specific purpose-level choices where EU law requires them. |
| Use automated and machine-readable indications | Choices should be encoded so that services can receive and process them consistently. | The ADPC specification defines a machine-readable consent-requests resource, HTTP-header based interaction and an equivalent JavaScript interface for communicating data-protection decisions. |
| Require controllers to respect choices | A signal must have operational consequences. It cannot be merely symbolic. | ADPC creates structured choices that controllers, CMPs and CMSs can actually apply. The WordPress implementation and CMP integrations show how ADPC signals can suppress unnecessary banners and pipe consent states into existing consent infrastructure. |
| Create a standards pathway | European standardisation organisations should define how machine-readable indications are interpreted. | ADPC is an open public specification and a concrete starting point for harmonised standards. It reduces the risk that Article 88b remains a placeholder for an undefined future mechanism. |
| Work across browsers, websites, mobile apps and future tools | Article 88b should not be limited to one interface pattern or one dominant browser. | ADPC began with web technologies but is conceptually transport-agnostic. Implementation work already extends the same rights logic to WordPress, CMPs, IoT, children, mixed reality and AI-assisted digital protection. |
| Preserve the GDPR’s legal grammar | The EU framework requires more than a binary do-not-track or do-not-sell signal. | ADPC was designed around the GDPR/ePrivacy logic of prior consent where required, refusal where consent is not given, withdrawal after earlier consent and objection where objection applies. |
| Lower compliance costs | Simplification should help organisations, especially SMEs, comply without repeated bespoke interface engineering. | ADPC gives controllers and CMPs a reusable communication layer. The WordPress plugin and CMP pathways make adoption possible without rebuilding a whole consent stack from scratch. |
| Prepare for future digital environments | Rights communication must work in wallets, IoT, immersive environments and AI-mediated services where banners are unrealistic. | ADPC is a rights layer, not a banner design. Its logic can be carried by other protocols and interfaces, including local device communication, guardian-mediated flows and AI-assisted explanation tools. |
Why ADPC is the best match
for Article 88b.
Article 88b should not be implemented through the thinnest possible signal. Europe needs a rights-first communication mechanism that can replace repeated interface-level consent with meaningful user-side control.
Rights-first
ADPC starts from consent, refusal, withdrawal and objection, not from advertising convenience.
Bidirectional
Services can request. User-side tools can decide, remember and respond with structured decisions.
Purpose-sensitive
Choices can be tied to specific purposes, request identifiers and domains rather than a single binary flag.
Opt-in compatible
ADPC can carry affirmative consent as well as refusal and objection, matching the full EU legal structure.
Implementation-ready
ADPC has an open specification, web implementation paths, WordPress tooling and CMP support already in place.
Future-ready
The same architecture extends to IoT, children, mixed reality and AI-assisted digital protection tools.
Article 88b requirement
by requirement.
A good Article 88b implementation must satisfy the legal text and the practical purpose of the reform. ADPC fits because it turns legal choices into structured communication without reducing them to a single binary preference.
| Article 88b functional requirement | ADPC capability |
|---|---|
| Give consent through automated and machine-readable means | ADPC can communicate consent for one or more specific request identifiers, allowing affirmative choices to be expressed in structured form. |
| Decline a request for consent | ADPC can communicate refusal by returning no consent for requested purposes and can support reject-all patterns where appropriate. |
| Withdraw earlier consent | ADPC includes withdrawal signals, including withdrawal for specific purposes and broader withdrawal where the user chooses. |
| Exercise objection rights | ADPC supports objection to processing where objection is legally relevant, including direct-marketing contexts. |
| Respect choices in practice | ADPC signals can be applied by controllers, CMPs and CMSs to purpose categories, scripts and vendor behavior. |
| Use harmonised standards | The ADPC specification gives standardisation work an existing, rights-first technical basis rather than starting from a blank page. |
| Support user-side tools | ADPC is designed for user-agent interaction and can be extended to browsers, operating systems, assistants, wallets and other user-trusted software. |
| Move beyond websites | ADPC’s communication logic is not conceptually limited to classical websites and can be transported through other protocols in IoT, immersive and AI-mediated contexts. |
What the EDPB and EDPS said,
and how ADPC responds.
The EDPB and the EDPS strongly welcomed proposed Article 88b because technical means can simplify compliance, support data subjects in making online choices, make those choices effective in practice and address cookie fatigue. Their opinion is not an argument against Article 88b. It is an argument for implementing it correctly.
ADPC is valuable precisely because it answers many of the concerns identified in the Joint Opinion. It does not remove the need for legislative refinement, standardisation governance or enforcement. It gives Europe a rights-first mechanism through which those refinements can become operational.
| EDPB-EDPS comment | Why it matters | How ADPC helps | What policymakers should still do |
|---|---|---|---|
| Clarify the link between Article 88a and Article 88b | Machine-readable choice must be connected to the substantive rules on terminal-equipment access and subsequent processing. | ADPC is built around structured consent requests and responses. It can link a request to a purpose and make the choice machine-readable. | Add explicit cross-references and ensure request vocabularies reflect Article 88a purposes. |
| Clarify that controllers includes third-party actors | If only the visible website is bound, much of the tracking ecosystem remains outside the rule. | ADPC can carry purpose- and actor-specific requests and responses rather than relying on one banner controlled by the first-party interface. | Ensure all relevant controllers and embedded third parties must respect valid machine-readable choices. |
| Standards must apply to all actors involved | The signal only works if controllers, user agents, CMPs and relevant software interpret it consistently. | ADPC is an open specification that can provide common semantics and implementation behavior for multiple actors. | Use harmonised standards with clear conformance requirements for services, CMPs, browsers and other software. |
| No consent by default | A browser-level or software-level mechanism must not recreate manipulation by silently accepting by default. | ADPC does not require default consent. It can be implemented through explicit onboarding, refusal histories and user-side rules chosen by the user. | Prohibit consent-by-default configurations and require meaningful first-use choice. |
| Set a timeframe for standards development | Article 88b will fail if standardisation drifts or remains privately defined. | ADPC shortens the path because Europe already has a public specification and implementation experience to build on. | Set deadlines, publish references in the Official Journal and maintain the standard as a living process. |
| Do not exclude SME browser providers | Excluding smaller browser providers risks concentrating rights infrastructure in dominant platforms. | ADPC is open and implementable beyond large browser vendors, helping lower barriers for smaller user-agent providers. | Apply obligations proportionately without excluding SMEs from the core rights layer. |
| Extend beyond web browsers to other software | Users make choices through apps, operating systems, wallets, devices and assistants, not only through browsers. | ADPC’s architecture is not limited to browsers and can be transported through other protocols and user-side tools. | Include relevant software classes such as operating systems, mobile apps, wallets and assistants. |
| Reconsider the media-service-provider exception | Broad exceptions could preserve one of the main sources of banner fatigue and tracking pressure. | ADPC can support nuanced, purpose-sensitive interactions for media services without exempting entire sectors from respecting valid choices. | Narrow or remove broad exceptions and support rights-compatible media business models. |
| Provide effective fining powers and enforcement | Signals without consequences become symbolic, as the history of Do Not Track shows. | ADPC creates structured, auditable interactions: what was requested, what was sent and whether the system applied the choice. | Ensure supervisory competence, sanctions and auditable compliance duties for controllers and relevant software providers. |
What Europe must avoid.
Article 88b can become a major step toward digital protection by architecture. It can also fail if implemented too narrowly. The implementation choice is therefore decisive.
The goal should be replacement of dysfunctional banner logic, not duplication. ADPC is the best current candidate because it has enough legal and technical richness to replace the banner layer where a valid machine-readable choice exists.
- ✕A symbolic signal that controllers can ignore
- ✕A binary opt-out-only mechanism that cannot express the EU’s opt-in legal logic
- ✕A browser setting configured to consent by default
- ✕A system that leaves banners in place and merely adds another layer beside them
- ✕A standard captured by a few dominant browsers, platforms or advertising frameworks
- ✕Broad carve-outs that recreate the same consent fatigue in important sectors
- ✕A mechanism without logs, accountability and enforceable duties
DNT, GPC and ADPC:
the right lesson for Europe.
Do Not Track showed that a technical signal without legal force and institutional support does not change market practice. Global Privacy Control shows that legally recognised signals can matter, especially in an opt-out environment such as California. But Europe should not import the wrong legal grammar.
The GDPR and ePrivacy framework often require prior, specific and informed consent. They also require refusal, withdrawal and objection to remain meaningful. A single global opt-out signal is too thin for that structure. ADPC keeps the useful idea, machine-readable rights communication, while making it compatible with EU law.
| Mechanism | Basic logic | Fit with Article 88b |
|---|---|---|
| Do Not Track (DNT) | A simple tracking-preference signal. | Historically important, but too weak because it lacked binding legal consequences and rich rights semantics. |
| Global Privacy Control (GPC) | A legally recognised opt-out signal in some jurisdictions, especially for sale or sharing of personal information. | Useful lesson on enforceability, but too narrow as the main EU implementation because Article 88b must support consent, refusal, withdrawal and objection. |
| Advanced Data Protection Control (ADPC) | A bidirectional communication mechanism for structured requests and responses. | Best current fit because it is rights-first, purpose-sensitive, opt-in compatible and designed for GDPR/ePrivacy-style choices. |
Why Article 88b needs a
future-ready implementation.
The banner model is already weak on websites. It becomes unworkable in connected devices, robotics, mixed-reality environments, smart spaces, wallets and AI-mediated services. A sensor, headset, robot or AI agent cannot rely on a conventional cookie banner to make rights meaningful.
ADPC’s advantage is that it is a communication architecture, not a visual banner template. The same legal logic, request, understand, decide, remember, communicate, respect, can be carried by different interfaces and protocols.
That makes ADPC the right candidate not only for today’s Article 88b debate, but for the broader EU digital-policy stack: AI Act governance, digital identity wallets, data spaces, connected devices, pervasive environments and future user-side digital protection assistants.
ADPC extends to
Adopt Article 88b and implement it
through a rights-first standard.
A strong Article 88b should be adopted and improved. It should be implemented through a standard that reflects EU law, not through a thin opt-out mechanism imported from a different legal environment.
ADPC is the strongest current candidate for that role. It makes rights communication operational while preserving the difference between consent, refusal, withdrawal and objection. It gives controllers, CMPs, CMSs and user agents a concrete technical path. It directly answers the EDPB-EDPS demand for meaningful, enforceable, non-default, broadly applicable machine-readable choices.
- ✓Use ADPC as the immediate reference implementation for Article 88b standardisation
- ✓Require standards to support consent, refusal, withdrawal and objection, not only opt-out
- ✓Prohibit consent by default and require meaningful onboarding in user-side tools
- ✓Bind all relevant actors, including third-party controllers and software providers
- ✓Extend beyond classical browsers to operating systems, mobile apps, wallets, assistants and relevant device environments
- ✓Keep standards open, interoperable, accessible, multilingual and maintainable as living standards
- ✓Ensure effective supervisory powers, sanctions and auditability
Key sources for this page
Make Article 88b operational.
Policymakers can use ADPC as a concrete reference point for Article 88b standardisation. CMPs and CMSs can prepare by adding ADPC support. Controllers can pilot machine-readable choices today.