TL;DR
Browser and OS signals are great in the EU for saying “no,” but they’re not enough to give a valid, informed, granular “yes” under GDPR and ePrivacy Directive. The media-services carve-out in the leaked Omnibus makes the whole promise weaker because the biggest trackers can just ignore the signal. And we still need first-party CMPs to actually enforce, log, and prove what the user decided.
This is for DPOs, privacy lawyers, policy people, and anyone maintaining a compliant CMP who now wonders “do we still need this?” (short answer: yes).
Most people are ready to celebrate: “finally, browser signals will kill consent banners.” But, I'm not celebrating yet.
The leaked “Digital Omnibus” draft finally says the quiet part out loud: yes, the EU wants browsers and mobile OSs to send a machine-readable privacy choice - and yes, websites should respect it. Good. That’s long overdue.
But in the same text we see three moves:
- more terminal-equipment access gets pulled into GDPR logic instead of staying in the very clear ePrivacy Directive 5(3);
- there is a specific exemption for media services from having to honour those machine-readable signals;
- and nothing actually solves the hardest EU problem: how to express an explicit, informed, granular “yes”.
So let’s unpack it.
Browser signals are perfect for “no”
What California and Colorado have done is smart: one signal → global opt-out. California even goes further and now requires all browser makers and mobile OS suppliers to support these signals. That’s powerful because it blocks processing at the point of origin - before AdTech, before SDKs, before sharing.
That logic also fits perfectly in the EU context for rejection:
- ePrivacy Directive 5(3): don’t store/read on the device without consent.
- Browser signal says: “don’t.”
- Site doesn’t load anything = compliant.
So far, so good.
But browser signals cannot express a valid EU “yes”
The current and proposed approaches are category-based - “marketing”, “analytics”, maybe “personalisation.” That is not what EU law calls “freely given, specific, informed and unambiguous” consent.
Why?
- it’s too coarse: a real site has 10–20 different third parties and purposes;
- it’s not contextual: GDPR consent is for this controller and this purpose, not a generic “marketing on the whole internet”;
- it has no information layer: a signal can’t show what will actually be loaded.
Even if, in the future, a browser/OS standard tried to define more granular signals, it still can’t magically know every script, SDK, tracker or conditional load a specific website might trigger at runtime. Consent has to be tied to the actual controller’s stack at that moment - something only a site-level, first-party CMP can present.
So a browser signal that says “accept marketing” would not meet GDPR + ePD 5(3) standards for an explicit, informed, granular yes. In Europe, browser signals are a great “no” - they are not (yet) a lawful “yes.”
“Browser signals are an excellent EU ‘no’. They are not a lawful EU ‘yes’.”
Consent categories were invented by CMPs, not by law
Somewhere along the way we all started acting as if EU law said “ask for functional / analytics / marketing.” It didn’t. CMP vendors did, to make banners look tidy.
Also: “consent for technically necessary technologies” is not a legal requirement. If it’s truly necessary under ePD 5(3), you don’t need consent. Asking for it is UX theatre.
So if anyone now imagines that a machine-readable “accept analytics” header suddenly equals valid EU consent, that’s backwards. The law never asked us to group everything into 3 boxes.
“Consent categories were invented by CMP vendors, not by EU law.”
Processing starts at device access - anonymising later doesn’t fix it
We still see this pattern in “privacy-friendly” analytics:
- the script accesses the device → processing has started
- the data is sent off
- the vendor anonymises / pseudonymises / aggregates
- the vendor says: “now it’s compliant”
But the legal issue was in step 1–2. If you accessed terminal equipment without valid consent, you can’t wash that away later. This is exactly where browser signals are useful: they can stop step 1 entirely.
The media-services exemption is the giveaway
The leaked text says: everyone should honour the machine-readable choice… except media services (with a vague nod to journalistic freedom) as seen in the leaked draft.
Since when did journalistic freedom include the right to collect and share our data with AdTech, data brokers and BigTech?
This is exactly the sector that currently shows “we need consent for our 895 partners so you can read this article.” Under the draft, that sector would be allowed to ignore a browser/OS “no.” That’s not simplification - that’s a lobby carve-out.
“If media can ignore the signal, we didn’t simplify - we just wrote the lobby carve-out into law.”
Where this leaves first-party CMPs
Even if the EU ships browser/OS signals:
- many users will never set a signal;
- controllers will still need granular consent for multiple vendors/purposes;
- media may be allowed to ignore the signal;
- and someone still has to enforce, record, and prove the choice.
That’s exactly why our data model for consent is first-party; and we already support GPC: so when the browser says “no,” we can actually stop processing; and when the user really wants to say “yes,” we can do it in a way that is contextual, informed, explicit and auditable.
Browser signals don’t kill first-party CMPs - they kill the bad habit of loading everything before consent.
“This is still the right direction - device-level signals + first-party enforcement - but it has to bind everyone.”
If you’re a DPO / privacy counsel looking at this leak: treat browser/OS signals as an excellent rejection mechanism, not as a magic “user accepted everything” flag. Keep your first-party CMP as the authoritative, contextual, auditable layer
Ronni K. Gothard Christiansen
Technical Privacy Engineer & CEO, AesirX.io
