Skip to content
Subset

User guide

What the law actually requires

The three rules behind every consent banner, why default-deny is not a preference, and what a consent record has to contain.

This page is about the rules rather than about our plugin, and none of it changes when the software ships. It is also not legal advice — we are engineers, and a sentence about your specific site is a question for somebody qualified to answer it.

Two different laws, doing two different jobs

Almost all confusion about cookie banners comes from conflating these.

The ePrivacy Directive, Article 5(3), is about storage on the device. It says you need consent before storing or reading anything on a visitor’s device, with one narrow exemption: storage strictly necessary to provide the service the visitor explicitly requested. It does not care whether the stored thing is personal data. A cookie that holds a random number is covered.

The GDPR is about processing personal data, wherever it came from. It defines what consent has to look like to count — freely given, specific, informed, and an unambiguous affirmative action — and it gives people rights over the data afterwards.

So a tracking pixel engages both: ePrivacy for writing the identifier, GDPR for what you then do with it. Analytics that genuinely store nothing on the device and identify nobody engage neither, which is why a cookieless, identifier-free analytics script does not require a banner.

The three rules that follow

Consent is a prior condition, not a record kept afterwards. A banner that loads Google Analytics on page one and stops on page two if you declined has already done the thing it needed permission for.

This is what “default-deny” means, and it is the rule most implementations fail. It is also the one that is technically hard: it requires intercepting scripts before they are printed, rather than deleting cookies after they are set.

2. Refusing must be as easy as accepting

“Freely given” has been interpreted consistently: if accepting is one click and refusing is three, consent was not freely given. In practice that means a reject-all control of equal prominence, on the first layer of the banner.

3. You must be able to show what was agreed

If you rely on consent, you must be able to demonstrate it. A usable record contains:

  • When the decision was made.
  • What was agreed to — the categories, not “the cookie policy”.
  • Which banner was shown, because the wording changes over time and consent is to the wording that was on screen.
  • How it can be withdrawn, which must be as easy as giving it was.

A log with a timestamp and a boolean does not meet that, and it is what most plugins store.

Withdrawal has to be easy too

Withdrawing consent must be as easy as giving it. In practice that means a permanent way back into the preferences — a footer link, usually — and not an email address.

Regions

The rules differ by jurisdiction, and the differences are real rather than cosmetic. The EU and UK require opt-in before storage. Several US state laws are opt-out, with a “do not sell or share” signal instead of a banner. Brazil’s LGPD is closer to the GDPR than to either.

Serving one banner to everybody is legal, because the strictest rule satisfies the looser ones. It is also the option that costs you the most analytics data in jurisdictions that never required a banner, which is the actual trade being made when a plugin offers per-region rule sets.