The moment Dick Hardt stood on stage at OSCON in 2005 and compared digital identity to a driver’s licence — something you own, you carry, you show only to whom you choose — the framing felt clean. You were in control. The site learned only what you disclosed. The rest stayed with you.
That vision did not survive contact with the market. Social login aggregated identity into a handful of platforms. Tracking infrastructure moved beneath the login layer entirely. And the closest thing we now have to “user-controlled disclosure” is the consent banner that loads before you can read a website.
That banner is worth understanding precisely. Not the dark-pattern version — the one designed to maximize Accept clicks — but what the law actually requires. Because when GDPR consent works correctly, it is the nearest thing in current infrastructure to the original Identity 2.0 promise: you decide what gets shared, with whom, before processing starts.
This article explains what valid consent requires under GDPR, where most implementations fail, and what a compliant consent flow actually looks like. Aimed at site operators, not lawyers — though legal requirements are stated carefully.
What Consent Has to Do With Identity
The Identity 2.0 critique of centralized authentication was that it concentrated power: one provider learned about every site you visited, every time you authenticated. Login concentrating in platforms made this worse, not better. Facebook Connect was convenient and ubiquitous, but every authentication event fed back into Facebook’s data infrastructure.
What nobody fully anticipated was that tracking would decouple from authentication entirely. You do not need to log in for a website to build a detailed profile of you. Third-party cookies, pixel fires, device fingerprinting, and cross-site ID graphs construct a behavioral identity without any login event. This is what GDPR — and the consent requirement specifically — is aimed at disrupting.
Consent under GDPR is not a checkbox. It is a legal gate on processing. Before a website can fire a tracking pixel, drop an advertising cookie, or pass your data to a third-party analytics provider, it must have a lawful basis. Consent is one of six lawful bases under Article 6. For most commercial tracking, it is the only realistic one.
The Four Conditions: What GDPR Actually Requires
Article 7 of GDPR sets out the conditions for consent. Recital 32 fills in the detail. The legal standard is four-part, and all four conditions must be met simultaneously. A consent mechanism that satisfies three of them is still unlawful.
Freely given
Consent must be freely given. This means the user must face no penalty for refusing. If the only options are “Accept all cookies” or “Leave the site,” that is not free consent — it is a take-it-or-leave-it contract, which GDPR Recital 42 explicitly excludes. The same applies to cookie walls that block content unless consent is granted.
Freely given also means refusal cannot be bundled with a cost that is disproportionate to the service. Charging a fee to access a site without consent (the “consent or pay” model) is contested in several jurisdictions; some data protection authorities have rejected it, others have permitted it under specific conditions. The area remains unsettled as of 2025.
Specific
Consent must be specific to each purpose. A single checkbox for “marketing, analytics, and personalisation” does not meet the standard. The user must be able to consent to analytics tracking independently of advertising tracking, and independently of functional cookies. Granularity is not optional.
This is why purpose-stacking in consent banners — where “accept all” covers a dozen purposes simultaneously — is problematic. Accepting all is only lawful if the user has been clearly informed of each purpose and had a genuine opportunity to accept or refuse each one.
Informed
Consent must be informed. The user must know, at the time of consenting, who is processing their data and for what purposes. A banner that says “we use cookies to improve your experience” without naming the third parties involved is not informed consent. The identity of data processors, the nature of the processing, and any international data transfers must be disclosed.
This creates a practical problem for sites running standard ad networks: real-time bidding systems can involve hundreds of vendors. GDPR does not exempt this complexity. The Transparency and Consent Framework (TCF) maintained by IAB Europe is the industry’s attempt to manage this at scale — and it has been the subject of enforcement action by the Belgian DPA precisely because the disclosure mechanism was held to be insufficient.
Unambiguous
Consent must be indicated by an unambiguous affirmative action. Recital 32 states clearly: pre-ticked boxes do not constitute valid consent. Continued browsing does not constitute valid consent. Scrolling past a banner does not constitute valid consent.
The user must actively do something — click a button, toggle a switch — that signals agreement. The action must be clearly distinguishable from other interactions on the page.
Where Most Banners Fail
Most consent banners fail on at least one of the four conditions. The failure modes cluster around a few common patterns:
| Failure pattern | The problem | GDPR violation |
|---|---|---|
| No “Reject All” button at top level | Refusal requires more clicks than acceptance | Not freely given |
| Pre-ticked vendor checkboxes | Default is opt-in, not opt-out | Not unambiguous |
| Single “I accept cookies” button | All purposes bundled together | Not specific |
| Vendor list hidden behind multiple clicks | User cannot see who processes their data | Not informed |
| Scripts fire before consent is given | Processing precedes the legal basis | Art. 7 breach — consent must be prior |
| No withdrawal mechanism | User cannot reverse a consent already given | Art. 7(3) breach |
| “Legitimate interest” pre-selected for tracking | Legitimate interest is not a valid basis for tracking cookies | Misuse of Art. 6(1)(f) |
The last row is worth emphasis. Many consent management platforms allow vendors to claim “legitimate interest” as a basis for processing, bypassing the consent mechanism entirely. The European Data Protection Board has stated clearly that behavioural advertising cannot rely on legitimate interest. Several DPAs have acted on this. It is not a grey area.
Consent Must Be Prior to Processing
This is a point that causes practical problems for many implementations: consent must be obtained before processing begins. Not “approximately at the same time.” Not “before the second page loads.” Before.
This means no third-party scripts can fire on page load — not even in a deferred or asynchronous state — until the user has actively consented to the purpose those scripts serve. A Google Analytics tag that fires 500 milliseconds after page load, before the banner has even appeared, is not covered by any consent the user later gives.
The technical implementation requires a consent management platform that genuinely blocks script execution, not one that fires scripts immediately and then retroactively checks a consent state. The difference matters. Some CMPs use a “soft block” approach that sends data and then discards it on refusal — this is not compliant.
The Right to Withdraw
Article 7(3) of GDPR states that the data subject has the right to withdraw consent at any time, and that withdrawal must be as easy as giving consent. If it took one click to accept, it must take one click to withdraw.
In practice this means:
- A persistent link to consent preferences in the site footer (or equivalent accessible location)
- The preferences panel must allow full withdrawal of all previously granted consent, not just opt-out of future tracking
- Withdrawal must trigger deletion or halting of processing that was based on that consent — it does not apply retroactively to processing already completed, but it stops future processing immediately
- The UX for withdrawal should not use confirmatory bias techniques (i.e., “Are you sure? You’ll miss out on personalisation” dialogs are arguably non-compliant)
Most consent banners have a footer link. Most of those links go to a panel where withdrawal requires toggling each purpose individually and clicking a separate “Save” button. Whether this satisfies “as easy as giving consent” depends on how easy acceptance was. If acceptance was one click, withdrawal via a five-step panel process is not equivalent.
What a Compliant Consent Flow Looks Like
A compliant consent flow is not complicated in principle, though it requires discipline in implementation.
- No scripts fire before the banner appears. This requires a CMP that genuinely blocks execution, not just defers it.
- The banner presents Accept and Reject at the same level of prominence. Both options in the same visual weight, same number of clicks.
- Purposes are listed individually. Analytics, advertising, personalisation, and functional cookies are separate categories with separate toggles.
- Vendors are named. Not “our partners” — the actual vendor list, accessible without leaving the banner interface.
- International transfers are disclosed. If data leaves the EEA, the basis for that transfer (adequacy decision, Standard Contractual Clauses, etc.) must be stated.
- Consent is recorded. The timestamp, IP (hashed), consent version, and purposes accepted must be stored — this is your proof of consent if challenged.
- Withdrawal is accessible. A footer link, one click to reach preferences, one click to withdraw all.
- Consent expiry is managed. GDPR sets no fixed expiry, but many DPAs and consent platforms use around 12 months as common practice; re-consent should be requested after that period or when purposes change.
If you are not sure which of these apply to your site — or which jurisdictions you need to comply with based on your audience geography — check which consent your site needs using the wizard, which walks through jurisdiction, audience size, and data types to give you a requirement set.
The Identity Parallel
When the Identity 2.0 movement talked about the value of single sign-on to real users, the argument was that the value was control: knowing what a site would receive about you, giving only what was necessary, being able to revoke access. The consent framework under GDPR is the same structure, built into regulation rather than protocol.
The failure mode is also similar. SSO standardized on platforms that served their own interests, and the user-control promise dissolved into a different kind of centralization. Consent management has standardized on CMPs that serve their publisher clients’ interests — maximizing consent rates, not maximizing user understanding. The gap between formal compliance and genuine user empowerment is wide.
What shifts this is the same thing that would have had to shift in the identity space: enforcement. GDPR enforcement has been slow and uneven, but it has accelerated. The Belgian DPA’s ruling against the IAB TCF, the French CNIL’s enforcement against Google and Facebook, the Irish DPC’s fines — these are not isolated events. The direction is toward stricter interpretation of what “freely given” and “informed” mean.
Site operators who are watching the pattern closely are not waiting for enforcement to land on them. They are building consent infrastructure that would hold up under a DPA audit — not because the fine risk is existential, but because it is the right architecture. You can self-assess your compliance posture against the current enforcement standards before you need to.
The Cluster Context
This article sits in a series that starts with the structural question: how online identity became a privacy problem. The consent banner is not the end of that story, but it is the current practical battleground. The questions the Identity 2.0 movement was asking — who controls what gets disclosed, who profits from your identity, what recourse do you have — are all present in the consent layer. They are just answered, imperfectly, in legal text rather than protocol specifications.
The imperfection is not permanent. Privacy law is young. Enforcement is learning. The technical infrastructure for consent is still maturing. The direction is toward something that actually gives users meaningful control over the data flows that constitute their online identity — even if the current implementation falls well short of that goal.
FAQ
Does GDPR consent apply to analytics cookies, or only advertising?
GDPR consent requirements apply to any processing based on consent as the lawful basis. For analytics cookies that set a persistent identifier and send data to a third-party server (such as Google Analytics), consent is required. For strictly necessary functional cookies, consent is not required. The line is drawn by whether the cookie is technically necessary for the service the user has requested — not by whether the cookie benefits the user in some general sense.
Can a cookie wall (blocking access unless consent is given) be compliant?
The European Data Protection Board has issued guidance stating that cookie walls do not constitute freely given consent, because access to the service is conditional on accepting data processing. Several national DPAs have acted on this. The “consent or pay” alternative model is contested and varies by jurisdiction. As a general rule, requiring consent to access content is high-risk.
How long is GDPR consent valid?
GDPR does not specify an expiry period for consent. GDPR itself sets no maximum; many European DPAs and consent platforms use roughly 12 months as a common refresh point, after which re-consent should be obtained. Consent should also be renewed when the purposes of processing change in a material way.
What is the penalty for non-compliant consent?
Fines under GDPR Article 83(5) — which covers violations of the conditions for consent — can reach 4% of global annual turnover or €20 million, whichever is higher. In practice, fines against smaller operators have been proportionate to scale; the multi-hundred-million euro fines have been levied against large platforms. The more immediate risk for smaller sites is a formal warning or remediation order from a DPA, which requires fixing the implementation within a set timeframe.