European Union is on a route to simplify the notorious rule that is annoying every EU citizen. Namely, the ever present “consent popups”. You know them for sure as most people need to go through lots of clicks that are simply a waste of time.

This analysis is based on the leaked GDPR/ePrivacy proposal. Be careful - this is subject to change.

I know what I’m talking about, being “in the business” for long. I was also advising on the previous attempt (ePrivacy Regulation change; which failed). It implements fully what I recommended several years ago - use the web browser as the means trusted by the user, to mediate consent.

Hot take: this is really promising!

The closed list when identifiers are OK

The draft moves personal data processing on or from terminal equipment (i.e. a web browser) into GDPR through a four purpose list (Article 88a). If an operation fits exactly one of these four purposes, consent prompt (e.g. for cookie or other identifiers) are not necessary explicitly. No need for being overcautious, or giving in to some flawed GDPR advice. The text says that processing is permitted if it is necessary solely for one of the following purposes:

• Transmission.
• Providing a service explicitly requested by the data subject.
• Creating aggregated information to measure the audience of an online service where it is carried out by the controller solely for its own use.
• Maintaining or restoring the security of the controller service or the terminal equipment used for the provision of this service.

The draft also draws a red line on further use. When the controller collects personal data solely for the above-mentioned purposes it cannot reuse it for any other purpose.

Cookie/ID consent notices

The current “Cookie law” (ePrivacy article 5) would not apply where personal data is processed on or from terminal equipment in accordance with Article 88a of GDPR (i.e. previous point). Consent stays if the information does not constitute and does not result in processing of personal data. Security updates do not need consent. If it is personal data and the purpose does not fit 88a then consent may be needed.

• When consent is needed: storage or access on terminal equipment i.e. web browser; access that does not involve personal data; there is no valid machine readable consent signal already set for the same purpose.
• When it is not needed: operation is strictly limited to transmission; a service explicitly requested by the person; the controller’s own aggregated audience measurement; security with no repurposing; when a compliant machine readable consent signal already covers the same purpose.

Silly consent user experience is GONE

If consent is necessary, then the draft mandates two design rules. The user must be able to give consent or refuse requests for consent in an easy and intelligible manner with a single click button or equivalent means. The controller must respect the choice to give consent or refuse for at least six months and must not make a new request for the same purpose in that period.

The draft introduces a new duty to recognise standardised signals that encode consent or refusal and the right to object to direct marketing. The text says that the data subject shall be able to give consent or refuse a request for consent and exercise the right to object through automated and machine readable means.

Controllers (e.g. web sites) must be able to interpret and respect those indications.

The means can be implemented in the settings of a web browser or in the terminal equipment that defines the rules for software applications such as mobile phone operating systems or in the EU Digital Identity Wallet or any other adequate means.

I need to cite it in verbatim: “(39) Data subjects should have the possibility to rely on automated and machine-readable indications of their choice to [consent or] refuse a consent request or object to the processing for direct marketing. Such means should follow the state of the art. They can be implemented in the settings of a web browser, in the terminal equipment where such terminal equipment defines the rules for software applications collecting personal data through the use of that terminal equipment (e.g. mobile phone operating systems) or in the EU Digital Identity Wallet as set out by Regulation (EU) 2024/1183, or any other adequate means.”

That’s great, though it is unclear why the EU Digital Identity Wallet is included here. Why would the EU Digital Identity Wallet should be interacting with, say, online ads infrastructure…?

There is a limited carve out. The text says that the obligation shall not apply to controllers that are media service providers when providing a media service. Perhaps we can pay this price for having the rest of the web browsable in peace.

What this means in practice

If a website would set a session cookie or otherwise use an ID, for example strictly to use a shopping cart, consent is not needed.

If the website is measuring own audience using aggregated information and keep it solely for own use then the website is OK - no consent needed.

If third party analytics or ad technology that builds cross service profiles is in use, it would be outside the 88a territory. Consent may be required. The website would have to respect any standardised consent ot refusal signals once the standards exist and the six month grace has passed.

How to deliver machine-readable, automatic consent signal

This means that web browser extensions or browser implementations that deliver consent signals are necessary, and would have a full support of applicable law. This means that the long-mocked W3C Do Not Track, or more precisely, Tracking Preferences Expression, would become relevant. Those, or their varieties. It is unclear if the California GPC would be a proper choice in the European Union. Most likely a local standard will be favored, as things stand now. But there’s a lot of room for creativity here.

For example, it could be a HTTP header like that:

GDPR-Consent: ver=1; action=refuse; purposes=ads,third_party_analytics; scope=global; exp=2026-05-09T00:00:00Z; source=browser; policy=eu-88b-2026; comment=byebye

Ignoring a valid machine readable consent or refusal signal can be fined up to €20,000,000 or 4% of worldwide annual turnover.

Summary

The draft narrows banner use to a small first party lane and replaces many prompts with device level signals. Consent is not eliminated, but the implementation is rationalised. It could be granted directly via an operating system, a web browser, a web browser extension, etc. Standards need to be developed for this purposes. Websites would need to accept it in order to comply. That would be the job for technology layer. Consent would be less about a legal obscurity or paper work, and more about the user interface. Finally. Let’s hope this gets delivered the proper way.

I’ll keep a close eye on this.

Comments, queries, or maybe contract offers? ;-) Contact me at me@lukaszolejnik.com. Let’s talk!