# ConsentTheater — full reference

> All handbook articles and EU law-reference pages from consenttheater.org concatenated into a single document for one-shot ingestion (RAG pipelines, IDEs, tools that do not follow links). For an index instead, see /llms.txt. For individual files, each entry below also exists at its own /handbook/<slug>.md or /law/<path>.md URL.

Generated: 2026-07-15
Source: https://consenttheater.org/llms-full.txt

---

# Handbook

## Consent & banners

### Global Privacy Control — what it is and how to turn it on

> GPC is a browser-level signal that automatically tells every website "do not sell or share my data". A plain-language guide to what it does, where it is legally binding, and step-by-step instructions to enable it on every major browser — desktop and mobile.

Updated: 2026-05-09 · Source: https://consenttheater.org/handbook/global-privacy-control/

If you have ever clicked "reject all" on twenty different cookie banners
in one day, you have already noticed that consent UX on the web is broken.
**Global Privacy Control (GPC)** is an attempt to fix that — at the browser
level, once, automatically, for every site you ever visit.

## What GPC actually is

GPC is two simple things working together:

1. **An HTTP request header**: `Sec-GPC: 1` that the browser sends with every
   request when GPC is on.
2. **A JavaScript property**: `navigator.globalPrivacyControl` that scripts on
   the page can read to learn the same signal.

If a website's server or scripts see either of those, the browser is telling
them: *the user does not consent to having their personal information sold or
shared with third parties for purposes like cross-site advertising.*

That's the whole protocol. It is intentionally narrow: it expresses a single
specific opt-out, not generic "respect my privacy" — because that turned out
to be the fatal weakness of the older Do Not Track signal, which sites simply
ignored on the grounds that it didn't mean anything legally.

GPC is currently a [W3C work-in-progress specification](https://w3c.github.io/gpc/),
adopted as an official W3C work item by the Privacy Working Group in late
2024. The pre-W3C reference is at [globalprivacycontrol.org](https://globalprivacycontrol.org/).

## Where GPC is legally binding

This is the bit that makes GPC actually useful, where Do Not Track wasn't.

- **California (CCPA / CPRA)** — the California Attorney General's office
  has [explicitly stated](https://oag.ca.gov/privacy/ccpa/gpc) that ignoring
  a GPC signal is a violation of CCPA's opt-out-of-sale right. A 2022
  Attorney-General settlement (Sephora) made this enforcement-real, not
  theoretical.
- **Colorado, Connecticut, Texas, and several other US states** — their
  consumer privacy laws now reference "universal opt-out mechanisms" by
  similar wording, and GPC is the working implementation of that.
- **EU / UK** — GPC is **not** legally recognised in EU/UK law as an opt-in
  consent expression. ePrivacy still requires explicit consent for storage
  and access, and a "do not sell" signal is not the same as "do not store
  cookies." That said, well-built consent platforms can choose to honour GPC
  as an opt-out signal voluntarily, and some do.

So GPC's legal teeth are sharpest in the US. Outside the US it's currently
"good signal of preference" rather than "do this or get fined."

## How websites should respond

A website that respects GPC and falls under a regime that recognises it
should:

- **Not** trigger any sale or sharing of the visitor's personal information
  by default. No setting up a cross-site advertising profile, no transferring
  data to ad-tech partners that would qualify as a "sale" under CCPA.
- **Not** show "click here to opt out" prompts again — the GPC signal *is*
  the opt-out. Asking the user to confirm something they've already
  signalled is a dark pattern.
- **Not** treat GPC as an excuse to break the site or refuse to serve content.
  GPC opts out of *sale/sharing*, not out of *receiving the service*.

In practice, sites that use a consent management platform (CMP) usually have
a setting to read GPC and pre-set the opt-out flags accordingly.

## How to turn it on

### Firefox (desktop, version 120 and later)

GPC ships built-in. To enable:

1. Open the menu (☰) → **Settings**
2. **Privacy & Security** in the left sidebar
3. Scroll to **Website Privacy Preferences**
4. Tick **"Tell websites not to sell or share my data"**

Firefox documents this on its
[support page](https://support.mozilla.org/en-US/kb/global-privacy-control).
The same setting appears in Firefox for Android with
[its own guide](https://support.mozilla.org/en-US/kb/global-privacy-control-firefox-android).
Firefox for iOS does not currently expose a GPC toggle (Apple-platform
constraints).

### Brave (desktop and mobile)

GPC is **on by default** — no action required. You can verify by visiting
[globalprivacycontrol.org](https://globalprivacycontrol.org/) and looking for
the green "GPC signal detected" indicator.

### DuckDuckGo Browser (desktop and mobile)

GPC is **on by default**. DuckDuckGo was a founding member of the GPC
standards effort and ships it active in the browser and the browser
extension. Their documentation: [GPC in DuckDuckGo](https://duckduckgo.com/duckduckgo-help-pages/privacy/gpc).

### Chrome / Edge / Opera

There is **no native GPC support** in any Chromium-based browser at time of
writing. Workarounds:

- **Privacy Badger** extension (from EFF) sets GPC automatically.
- **DuckDuckGo Privacy Essentials** extension does the same.
- Some other privacy extensions (e.g. uBlock Origin's privacy-focused forks)
  also expose a GPC option.

Without an extension, Chrome and Edge will not transmit GPC, regardless of
how many other privacy settings you enable.

### Safari (macOS and iOS)

Apple has not added GPC to Safari, citing existing Intelligent Tracking
Prevention as their preferred mechanism. There is currently no native GPC
toggle. A handful of Safari extensions claim to add it, but support is
patchy.

### Tor Browser

GPC is on as part of Tor Browser's privacy defaults; you don't need to
enable anything.

### Mullvad Browser, LibreWolf, Zen

All three are Firefox-based. Mullvad Browser ships with GPC on by default.
LibreWolf has it as a default-on hardened setting. Zen inherits the
standard Firefox toggle (Settings → Privacy & Security → Website Privacy
Preferences).

## Why GPC isn't perfect — yet

Two honest caveats.

**Adoption is uneven.** Plenty of sites still don't read the signal. The
ones that do tend to be in regulated industries (publishers in California,
ad networks who got fined). On the long tail of the web, GPC is invisible
to many sites. That's a softer state than the law would describe — it's
not yet "send GPC and you're protected."

**Scope is narrow by design.** GPC says one thing: "do not sell/share."
It does not say "do not track me at all", "do not set cookies", or "do not
fingerprint." Those are bigger asks that are addressed by other tools
([browser-level privacy](/handbook/privacy-friendly-browsers/), tracker
blockers, the EU consent regime). GPC is one specific, legally-anchored
signal — useful exactly because it doesn't try to do everything.

That said: enabling it costs nothing, it works automatically, and where it
*is* legally binding, ignoring it is a fineable offence. Worth turning on.

## Reading list

- **[Global Privacy Control specification](https://w3c.github.io/gpc/)** —
  the W3C work-in-progress spec, with the legal-and-implementation
  considerations [explainer](https://w3c.github.io/gpc/explainer.html).
- **[California AG — Global Privacy Control](https://oag.ca.gov/privacy/ccpa/gpc)** —
  official state position that ignoring GPC violates CCPA.
- **[MDN: Sec-GPC header](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Sec-GPC)**
  and **[Navigator.globalPrivacyControl](https://developer.mozilla.org/en-US/docs/Web/API/Navigator/globalPrivacyControl)** —
  technical references for site implementers.
- **[Firefox: Global Privacy Control](https://support.mozilla.org/en-US/kb/global-privacy-control)** —
  desktop how-to.
- **[Firefox for Android: GPC](https://support.mozilla.org/en-US/kb/global-privacy-control-firefox-android)** —
  mobile how-to.
- **[DuckDuckGo: GPC](https://duckduckgo.com/duckduckgo-help-pages/privacy/gpc)** —
  on by default in DDG products.

---

## Tracking & cookies

### Strict-necessary cookies — what actually qualifies

> The "strictly necessary" exemption is the most-misused phrase in cookie compliance. This article walks through the legal text, the EDPB's interpretation, and concrete examples of what does and does not qualify — including the popular myths.

Updated: 2026-05-09 · Source: https://consenttheater.org/handbook/strict-necessary-cookies/

If you build websites in the EU, you have probably written `consent: 'strictly_necessary'`
in some banner config. The label is everywhere, and almost nobody uses it correctly.

This guide unpacks what the law actually says, what the EDPB has clarified, and gives
concrete examples for the things people most often get wrong.

## Where the exemption comes from

The "strictly necessary" carve-out lives in the **ePrivacy Directive Article 5(3)**.
The default rule is that storing or accessing information on a user's device — cookies,
`localStorage`, `IndexedDB`, fingerprinting — requires **prior informed consent**.

Article 5(3) provides exactly two narrow exemptions:

1. **Communication exemption** — when storage is "for the sole purpose of carrying out
   the transmission of a communication over an electronic communications network".
2. **Strictly necessary exemption** — when storage is "strictly necessary in order for
   the provider of an information society service explicitly requested by the subscriber
   or user to provide the service".

Two things to notice immediately:

- The user has to **explicitly request** the service.
- The cookie has to be **strictly necessary** — not "useful", not "nice to have", not
  "industry standard", not "needed for our analytics".

## The EDPB test

The European Data Protection Board's
[Guidelines 2/2023](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en)
gave the practical test:

> *"Strictly necessary" must be read narrowly. The functionality must be one the user has
> explicitly requested, and the storage must be necessary for that functionality alone.*

If removing the cookie would only make the experience "less smooth" or "harder to
analyse", it is **not** strictly necessary.

## What qualifies — examples

These genuinely fall under the exemption:

- **Session ID** for an authenticated user. You logged into your bank — the cookie
  keeping you signed in for the next 20 minutes is genuinely necessary. Without it
  the bank can't remember it's you, and "be logged in" is exactly what you asked
  for.
- **Shopping-cart contents.** You added a pair of shoes to your cart on an
  e-commerce site. The cart cookie keeps the items as you browse to a second
  product. Without it, the cart empties on every page.
- **Load-balancer routing token** that pins the user to a backend during a
  multi-step flow. You're filling out a checkout form across three pages — the
  cookie keeps your requests going to the same server so your partial state
  isn't lost mid-flow.
- **Cookie-consent state itself** — the cookie that remembers whether the user
  has already accepted or refused. Without it you'd ask again on every page,
  which is itself a dark pattern.
- **CSRF tokens** for security on forms the user submitted. Without them,
  malicious sites could trick the browser into submitting forms on the user's
  behalf. The cookie protects an action the user just initiated.
- **Language / locale preference** when it comes from the user. That includes
  the browser's `Accept-Language` header (which the user configured in their
  OS or browser settings) and explicit on-site language switchers. It does
  **not** include IP-geolocation guesses — those are inferences about the user,
  not preferences the user expressed.

## What does **not** qualify — common myths

Commonly mis-labelled as strictly necessary:

- **Analytics, even "anonymous" or "first-party".** Google Analytics on your blog
  so you can see where readers come from. Useful for you, but the visitor did not
  ask to be counted. Plausible-as-script and Matomo with `_pk_id` sit in the same
  bucket. (Narrow exception: pure server-side counting from access logs, with no
  cookie and no device-readable state, is not in scope of Article 5(3) at all —
  though GDPR still applies to whatever IPs you log.)
- **A/B testing and feature flags.** Optimizely or VWO decides which variant to
  show you and stores that decision in a cookie. Reasonable business need, but
  the user came to read the article — they didn't ask to be a variable in
  someone's experiment.
- **Personalisation that the user didn't turn on.** An e-commerce site dropping
  a "last viewed products" cookie so it can show recommendations. Convenient,
  not necessary — the user asked to view a product, not to be remembered.
- **Marketing and conversion pixels** — Meta Pixel, Google Ads tag, LinkedIn
  Insight, TikTok Pixel. Even when these don't set a cookie of their own, they
  are in scope: loading the pixel's URL causes the third party (Meta, Google,
  etc.) to read the cookies the browser already has on its domain, which is
  "accessing information already stored" under Article 5(3). See the dedicated
  [tracking pixels](/handbook/tracking-pixels/) article for the deep dive on
  how this works and what consent rules apply across jurisdictions.

The general rule: **if the cookie's purpose is for the website operator's benefit
rather than directly fulfilling something the user asked the website to do, it
needs consent.**

## Genuinely contested — bot mitigation and fraud detection

This category is different from the myths above. There is a legitimate engineering
argument that anti-bot and anti-fraud cookies *are* strictly necessary, and that
argument has not been settled by any court ruling. Both sides have a point.

The textbook example is **`__cf_bm` from Cloudflare**. Cloudflare classifies it as
strictly necessary because without bot mitigation, sites are exposed to scraping,
credential stuffing, layer-7 DDoS — and a site that's down or compromised cannot
deliver the service the user requested anyway.

EU regulators read Article 5(3) ePD more literally:

- The cookie has to be necessary for the **service the user explicitly requested**
- The user requested "show me this page". They did not request "protect this site
  from bots"
- Bot mitigation primarily benefits the **operator**; user benefit is indirect at
  best
- Therefore the exemption does not apply, and consent is required

The French **CNIL** has made this position explicit in its guidance and
enforcement: `__cf_bm` requires consent in the EU. The **EDPB's Guidelines 2/2023**
align with the same narrow reading — operator-side performance and security
optimisations sit outside the exemption.

There is no CJEU ruling on this point. Until there is one, `__cf_bm` and similar
bot/fraud cookies live in the *contested* zone:

- **Vendor reading:** strictly necessary, no consent needed.
- **Prevailing EU regulator reading:** consent needed, even if the cookie is
  genuinely useful for security.

This is the kind of case our `consent_burden: 'contested'` value exists for — we
surface the disagreement rather than picking a side.

There is one narrower distinction worth keeping: even regulators agree that
**server-side** anti-bot work — rate limits, IP-based blocks, ASN heuristics — is
outside the scope of Article 5(3) entirely, because nothing is stored or read on
the user's device. The dispute is specifically about cookies and similar
device-side state.

## How long can a strict-necessary cookie live?

The other half of "strictly necessary" is duration. A cookie can be necessary for the
length of the user's session (closes the tab → cookie expires) but not for two years.
A typical authenticated-session cookie is bounded to a session or a short
"keep me logged in" window the user explicitly opted into.

Long-lived cookies declared as "strictly necessary" are a strong signal the
classification is wrong.

## Why this matters for ConsentTheater's catalogue

Our `consent_burden` field draws a line:

- `minimal` — genuinely strict-necessary, low ambiguity.
- `required` — needs consent under EU rules, even if the vendor's own documentation
  says otherwise.
- `required_strict` — needs consent **and** has been the subject of regulator
  enforcement or CJEU rulings against the same pattern.
- `contested` — vendors and regulators disagree; we surface the disagreement
  rather than picking a side.

Where vendors call something "strictly necessary" but the EDPB test would fail,
our catalogue sides with the regulator's reading.

## Reading list

- **[ePrivacy Directive Article 5(3)](/law/eprivacy/art-5/)** — primary text.
- **[GDPR Article 7](/law/gdpr/art-7/)** — what consent must look like *when* it is required.
- **[EDPB Guidelines 2/2023](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en)** — technical scope of Article 5(3).
- **[CJEU Planet49 (C-673/17)](https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A62017CJ0673)** — pre-checked boxes are not consent.

---

### Tracking pixels — what they are and what consent rules apply

> "We don't use cookies, just pixels" is one of the most common compliance myths. This article walks through what a pixel actually is technically, why it's still in scope of EU consent rules, and how the picture shifts under UK and California law.

Updated: 2026-05-09 · Source: https://consenttheater.org/handbook/tracking-pixels/

If you have ever heard a vendor or a marketing team say *"we don't use cookies,
we just use pixels — so consent isn't needed"*, that sentence is almost always
wrong. This article unpacks why.

## What a pixel actually is

A "tracking pixel" is not a special technology. It is just any of the following:

- A `<img>` tag with `src` pointing at a 1×1 transparent image on the third
  party's domain.
- An `<iframe>` or `<script>` tag that loads from the third party's domain.
- A JavaScript snippet that fires `fetch()` or `navigator.sendBeacon()` to the
  third party.

In all three cases the mechanic is the same: the user's browser is told to make
an HTTP request to a third-party domain — `facebook.com/tr/`, `linkedin.com/li.lms-analytics`,
`analytics.tiktok.com`, `bat.bing.com`, etc.

That's the entire pixel. It's a request, not a cookie.

## Why pixels still trigger Article 5(3) ePD

The crucial bit of EU law is in Article 5(3) of the ePrivacy Directive. It
covers **two** operations on the user's terminal equipment, and most people
remember only one of them:

1. *Storing* information — the classic "setting a cookie" case.
2. *Gaining access to* information already stored — the often-forgotten case.

Now picture what happens when a website embeds a Meta Pixel:

- The browser is instructed to load `https://www.facebook.com/tr/?id=...&ev=PageView&...`
- Browsers automatically attach all `facebook.com` cookies to any request going
  to `facebook.com` — including session cookies the user accumulated by being
  logged into Facebook earlier
- Facebook's server reads those cookies on its side
- That read is "gaining access to information already stored on terminal
  equipment" — the user's browser cookie store

**The pixel didn't store anything.** Your site didn't store anything. But
*access* did happen, and the request was caused by your site. So Article 5(3)
applies.

The European Data Protection Board's
[Guidelines 2/2023](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en)
make this explicit: storage *and* access are equally in scope, and pixels are
listed as one of the techniques covered.

In practice almost every commercial pixel also sets companion first-party
cookies on the embedding site — `_fbp` for Meta, `_gads` and `_gcl_*` for
Google, `_uetsid` for Bing — so the "we don't set cookies" claim usually isn't
even technically true. But even if it were, the access leg of Article 5(3)
would still bite.

## The pixels you'll meet in practice

| Pixel | Vendor | Typical cookies it co-sets | Purpose |
|---|---|---|---|
| Meta Pixel (`fbq`) | Meta | `_fbp`, reads `_fbc` | Ad targeting + conversion attribution |
| Google Ads tag (`gtag`) | Google | `_gads`, `_gcl_*`, `_gac_*` | Ad targeting + conversion attribution |
| LinkedIn Insight Tag | LinkedIn | `li_*`, `lidc`, `bcookie` | B2B audience building |
| TikTok Pixel (`ttq`) | TikTok | `_ttp` | Ad targeting + conversion |
| X (Twitter) Pixel | X | `personalization_id` | Ad targeting |
| Reddit Pixel | Reddit | `_rdt_uuid` | Ad targeting + conversion |
| Microsoft UET (`uetq`) | Microsoft | `_uetsid`, `_uetvid` | Bing Ads conversion |
| Pinterest Tag (`pintrk`) | Pinterest | `_pinterest_*` | Ad targeting |

All of these need consent under the EU/UK reading. None of them qualify for
the strict-necessary exemption.

## What about server-side conversion APIs?

Around 2020 every major ad platform introduced a server-side equivalent of its
pixel: Meta's *Conversions API*, Google's *Enhanced Conversions* and *server-side
GTM*, TikTok's *Events API*, and so on. The marketing pitch was usually "this is
more privacy-friendly because no pixel runs in the browser."

The reality is more nuanced.

- **From a pure ePrivacy perspective**, server-to-server transmission with no
  browser pixel and no device-side state read is genuinely outside Article
  5(3). No storage, no access on the user's terminal. So the consent rule
  doesn't trigger for that specific transmission.
- **From a GDPR perspective**, sending personal data (hashed email, IP,
  click ID, browsing history) to Meta/Google/TikTok is still processing
  personal data, and you still need a lawful basis under Article 6. For
  ad-targeting purposes the only realistic basis is consent.
- **In practice**, almost every server-side conversion implementation **also**
  runs a browser pixel for first-touch identification and to capture click
  IDs, so the ePrivacy trigger is back. The "server-side" pitch usually just
  means "the conversion event itself is sent server-to-server, but we still
  need the pixel for the front-door identification."

So server-side APIs let you keep tracking working when third-party cookies are
blocked or when ad-blockers strip the pixel, but they do **not** make the
consent question disappear.

## Under EU rules

Default position: a pixel needs **prior, informed, freely-given consent**
because it falls in scope of Article 5(3). The Planet49 ruling clarified that
pre-ticked consent boxes are not valid; consent has to be a clear affirmative
action.

There is no narrow exemption that pixels can credibly claim:

- They are not "for the sole purpose of carrying out the transmission of a
  communication" — that exemption is for routing/delivery infrastructure, not
  marketing tags.
- They are not strictly necessary for any service the user requested.

The legal position has been confirmed in formal enforcement: **CNIL**
specifically fined Meta and Google over Facebook Pixel and Google Analytics
deployment in 2022, and similar findings exist across other EU national DPAs.

If consent is refused or not yet given, the pixel must not load and must not
fire. Practical implication: pixel tags need to be wrapped in a consent gate
on the page, not just hidden.

## Under UK rules

The UK's
[Privacy and Electronic Communications Regulations 2003 (PECR)](https://www.legislation.gov.uk/uksi/2003/2426/contents)
mirror Article 5(3) of the ePrivacy Directive almost verbatim — Brexit didn't
change this part. The
[ICO's guidance on storage and access technologies](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/)
explicitly applies to pixels, fingerprinting, and similar techniques the same
way it applies to cookies.

Practical effect: same rule. Pixels need consent.

The Data (Use and Access) Act 2025 amended PECR slightly but the pixel /
device-state access regime stayed essentially the same.

## Under California rules (CCPA / CPRA)

California uses a different framework, and this is where the user's mental
model has to switch.

**It's an opt-out regime, not opt-in.** A site can run pixels by default. But
it must:

1. Provide a clear *"Do Not Sell or Share My Personal Information"* link in
   the footer (or equivalent — there are also approved opt-out icons).
2. Honor any [Global Privacy Control](https://globalprivacycontrol.org/)
   browser signal as an opt-out request, automatically.
3. For *sensitive personal information*, provide a separate *"Limit the Use
   of My Sensitive Personal Information"* control.
4. For consumers under 16, **opt-IN** consent is required for sale or sharing
   (real consent, not opt-out). For under 13, parental consent.

The reason pixels are in scope: under
[CCPA §1798.140](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5),
"sale" includes any disclosure of personal information for *monetary or other
valuable consideration*, and "sharing" specifically covers *cross-context
behavioral advertising*. When your site fires a Meta Pixel and Meta uses the
data to target ads, that almost always meets the "sharing" definition; ad-tech
arrangements often meet "sale" too.

Failure to provide the opt-out mechanism, or — increasingly enforced — failure
to honor a GPC signal, is a CCPA violation. The
[California Attorney General's GPC notice](https://oag.ca.gov/privacy/ccpa/gpc)
has been clear that ignoring GPC counts as ignoring an opt-out request.

## What good looks like

If you genuinely care about doing this right:

- **EU/UK**: don't load any tracking pixel until the user has given consent.
  Use a consent management platform (CMP) or roll your own gate. Default-deny.
  Granular categories ("Marketing" vs "Analytics") so users can pick.
- **California**: provide a "Do Not Sell or Share" link, plumb it into your
  pixel loaders so they don't fire when opted out, and parse the
  `Sec-GPC: 1` request header / `navigator.globalPrivacyControl === true`
  signal as an automatic opt-out.
- **Both**: log consent state alongside any data you do send, so you can
  prove later that the user agreed at the time. CMP integrations usually
  handle this; rolling your own means storing a timestamped consent record.
- **Don't lean on dark patterns** (pre-ticked boxes, "agree to keep reading",
  reject-all buried three clicks deep). The Planet49 ruling and post-2023
  enforcement waves are explicit: that's not consent.

## Reading list

- **[ePrivacy Directive Article 5(3)](/law/eprivacy/art-5/)** — primary EU text.
- **[GDPR Article 6](/law/gdpr/art-6/)** — lawful bases for processing personal data.
- **[Strict-necessary cookies — what actually qualifies](/handbook/strict-necessary-cookies/)** — the companion piece on what's in or out of the consent exemption.
- **[EDPB Guidelines 2/2023](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-22023-technical-scope-art-53-eprivacy-directive_en)** — confirms pixels and similar techniques are in scope.
- **[ICO PECR guidance](https://ico.org.uk/for-organisations/direct-marketing-and-privacy-and-electronic-communications/guidance-on-the-use-of-storage-and-access-technologies/)** — UK's equivalent.
- **[CCPA full text](https://leginfo.legislature.ca.gov/faces/codes_displayText.xhtml?division=3.&part=4.&lawCode=CIV&title=1.81.5)** — California Civil Code §1798.100 et seq.
- **[California AG on Global Privacy Control](https://oag.ca.gov/privacy/ccpa/gpc)** — official position that ignoring GPC is an opt-out violation.
- **[Global Privacy Control specification](https://w3c.github.io/gpc/)** — W3C work-in-progress spec for the browser signal.

---

## Privacy tools

### DNS sinkholes — taking your privacy back at the network level

> Browser-level defences only protect the browser. A DNS sinkhole blocks trackers across every device on your network — phones, TVs, IoT junk, and apps that ignore your ad blocker. This article explains how DNS blocking works, what it cannot fix, and walks through the practical options (NextDNS, ControlD, Pi-hole, AdGuard Home).

Updated: 2026-05-13 · Source: https://consenttheater.org/handbook/dns-sinkholes/

Browser-level defences are one layer of privacy protection — but only one.
They protect the browser. Your phone's apps, your smart TV, your Wi-Fi
thermostat, the random toy with a chip in it — none of those run uBlock
Origin. They all phone home to whatever servers their vendors point them
at, and many of those servers are ad networks and analytics platforms.

A **DNS sinkhole** is a way to cut off those phone-home requests one
layer below the browser — at the network's address-lookup layer. Set
once, applies to every device on the network.

## The DNS angle

When any program on your computer or phone tries to connect to
`facebook.com`, it first has to ask "what IP address is `facebook.com`?"
That question goes to a **DNS resolver**, which returns an IP. Once your
device has the IP, the actual connection happens.

If the resolver simply refuses to answer for known-tracker domains —
returns `NXDOMAIN` ("no such domain") or `0.0.0.0` — the connection
never happens. Your device tried, your network didn't help, the tracker
gets nothing.

That's a DNS sinkhole: a resolver you control (or that you trust)
configured to selectively block the lookups you don't want.

## What it gives you that browser tools don't

- **Network-wide.** Every device on your home network — phones, tablets,
  smart TVs, game consoles, IoT — gets the same blocking, with no
  per-device extensions to install.
- **App-level protection.** Mobile apps that ignore browser content
  blockers (because they aren't running in a browser) still hit your DNS
  resolver. Block ad networks at the resolver and the app's ads break.
- **Faster pages.** Pages that would have loaded twenty tracker scripts
  now just don't. On ad-heavy sites the difference is dramatic —
  sometimes 50%+ less time-to-interactive.
- **Less bandwidth.** Mobile data plans last longer.
- **Visibility.** The dashboards on hosted services show you which
  domains your devices try to reach. You'll be surprised. (Your TV is
  noisier than you think.)

## What it cannot fix

This part matters. DNS sinkholes are powerful but they aren't a complete
privacy solution.

- **First-party trackers aren't blocked.** If a site loads analytics
  from `example.com/analytics/track.js` instead of `google-analytics.com`,
  the blocklist can't catch it without breaking the whole site. CNAME
  cloaking — where a tracker domain is aliased onto the site's own
  subdomain — also evades DNS-level blocking. Browser extensions still
  matter here.
- **Encrypted DNS bypasses your sinkhole.** Many apps and browsers
  (Firefox, Chrome, iOS) now use **DNS-over-HTTPS (DoH)** by default
  with their own resolvers — Cloudflare, Google, your phone vendor.
  If you don't disable that, the app routes around your sinkhole
  entirely. Most consumer sinkhole setups include guidance for this.
- **In-page tracking still happens.** Fingerprinting via JavaScript on
  pages you *do* allow happens entirely inside the browser; DNS can't
  see it.
- **Doesn't replace consent rules for sites.** A site you run still has
  to comply with consent rules regardless of how its visitors block
  things on their end. DNS sinkholing is **user self-defence**, not a
  legal compliance pattern.
- **False positives.** Aggressive blocklists occasionally block
  legitimate functionality — login redirects, payment widgets, account
  recovery flows. You will need an "allow this domain" override
  workflow.

## The practical options

DNS sinkholes come in two flavours:

- **Hosted DNS services** — someone else runs the resolver, you point
  your device or router at it. Easy. Usually offer per-device profiles,
  encrypted DNS-over-HTTPS, dashboards, custom blocklists.
- **Self-hosted** — you run the resolver, usually on a Raspberry Pi or
  a Linux box on your home network. Free, total control, but you own
  uptime and updates.

Both work. Which fits depends on whether you'd rather pay a few
dollars a month for convenience or spend a weekend setting up a Pi.

| Service | Type | Operator & network | Cost |
|---|---|---|---|
| [NextDNS](#nextdns) | Hosted SaaS | NextDNS Inc., Delaware-incorporated (French founders); global anycast network with EU pops, optional EU-only log jurisdiction | Free tier (300k queries/mo) + paid |
| [DNS4EU](#dns4eu) | Hosted SaaS | Whalebone-led consortium across 10 EU countries, originally EU-Commission-funded; 100% EU-hosted infrastructure | Free public tier |
| [ControlD](#controld) | Hosted SaaS | ControlD, Toronto-based (Windscribe subsidiary); global anycast network | Free tier + paid |
| [Pi-hole](#pi-hole) | Self-hosted | You, on your own hardware | Free (hardware cost only) |
| [AdGuard Home](#adguard-home) | Self-hosted | You, on your own hardware | Free (hardware cost only) |

### NextDNS

[NextDNS](https://nextdns.io/) is the easiest entry point. Sign up,
create a "configuration profile" (which gets a unique ID), pick
blocklists from a long menu, point your device or router at the
endpoint. Encrypted DNS (DoH / DoT / DoQ) is supported out of the box.
Free tier covers 300,000 queries per month — enough for one phone or
laptop, not enough for a whole household; paid plans are inexpensive.

Setup is genuinely click-through. Their dashboard shows you what's
being queried and what's being blocked, in real time.

**On jurisdiction.** NextDNS Inc. is incorporated in Delaware, US — a
detail worth knowing if jurisdiction matters to you. The founders are
French (Olivier Poitrey and Romain Cointepas, both ex-Netflix Paris),
the privacy posture is EU-aware in design, and you can configure log
retention and log location independently — including EU-only options.
If you want a stricter "no US entity at all" setup, see **DNS4EU**
just below.

### DNS4EU

[DNS4EU](https://joindns4.eu/) is the EU's own public DNS resolver,
launched on 9 June 2025. It is operated by a consortium led by the
Czech cybersecurity company Whalebone with infrastructure across **at
least 14 EU member states**, all of it **100% EU-hosted**. The
initial build-out was co-funded by the European Commission (2023–2025);
the consortium is now transitioning to a self-sustaining model funded
by commercial tiers (DNS4GOV for governments / critical infrastructure),
with the free public tier kept open for individual users.

What it offers individuals:

- **Five pre-curated resolver profiles** — unfiltered, malware-blocking,
  malware + adult content, malware + ads + tracking, child-protection.
  Pick the endpoint that matches what you want filtered.
- **DoH, DoT, DNSSEC** out of the box.
- **Anonymisation at the server** — personal data is anonymised on the
  resolver before any backend processing, with retention bounded by
  GDPR and EU data-protection norms.
- **No account, no commercial relationship** — just point your device
  at the endpoint IPs or use the encrypted endpoints.

It is **less configurable** than NextDNS or ControlD — no per-device
profiles, no custom blocklists, no real-time dashboard. That's a
feature if you don't want to fiddle, a limit if you do. For EU
readers who want the simplest "DNS-level privacy, EU jurisdiction
all the way down, institutional backing" answer, DNS4EU is currently
the strongest fit.

### ControlD

[ControlD](https://controld.com/) is the most actively-developed
alternative — weekly releases, a much larger catalogue of one-click
service blocks (you can block "TikTok" or "Snapchat" as named units
across all their domains, not by manually editing lists), and the
ability to *route* traffic in addition to *blocking* it (useful for
geo-relocation). Free tier exists; paid tiers unlock more profiles
and advanced features.

Similar UX to NextDNS, similar privacy posture. Pick on
preference / feature fit.

### Pi-hole

The classic self-hosted option. [Pi-hole](https://pi-hole.net/) runs
on a Raspberry Pi (any model) or any Linux box and acts as the DNS
server for your home network. You point your router at the Pi-hole;
every device automatically goes through it.

Strengths: free, completely under your control, mature codebase, large
community of blocklists. Weaknesses: requires basic Linux
comfort, hardware to buy if you don't already have a Pi, and DoH/DoT
support isn't built-in — typical setup pairs Pi-hole with `cloudflared`
or Unbound for encrypted upstream.

The [Pi-hole documentation](https://docs.pi-hole.net/) is excellent
and walks through every step.

### AdGuard Home

[AdGuard Home](https://adguard.com/en/adguard-home/overview.html) is
Pi-hole's modern competitor. Same self-hosted model, more modern web
UI, **built-in DoH/DoT** without extra components, single-binary
install, easier on first-time users than Pi-hole. The AdGuard company
also offers a hosted public DNS at `dns.adguard.com` if you want
their blocklists without running anything.

If you're starting fresh and don't have an existing Pi-hole setup, AdGuard
Home is often the simpler first build.

## A practical tip: encrypted DNS leaks

The single biggest gotcha with any DNS sinkhole is browsers and apps
that have DoH built in and pointed at someone else's resolver:

- Firefox enables DoH-to-Cloudflare by default in some locales.
- iOS allows individual apps to configure their own DoH.
- Some smart TV apps hardcode Google DNS.

If your devices are talking to `1.1.1.1` or `8.8.8.8` directly over
HTTPS, your local DNS sinkhole never sees the lookup. There are two
realistic responses:

1. **Disable in-browser DoH** so the OS resolver (your sinkhole) is
   used. Firefox: Settings → Privacy & Security → DNS over HTTPS →
   Off (or pointed at your sinkhole). Chrome: Settings → Privacy and
   security → Use secure DNS → Off.
2. **Block the public DoH endpoints** at your sinkhole. NextDNS,
   ControlD, Pi-hole and AdGuard Home all have presets or
   instructions for this — they refuse `dns.google`, `cloudflare-dns.com`,
   and similar, forcing the device to fall back to your sinkhole.

Without one of these, the sinkhole is a paper firewall.

## Combining with browser-level tools

DNS sinkholes and browser extensions live on different layers and are
**complementary**, not redundant:

- **DNS sinkhole** catches: known-tracker domains, ad network domains,
  mobile-app analytics endpoints. Cross-device, low setup cost.
- **Browser extensions** catch: in-page scripts you didn't want loaded,
  first-party tracking that uses the same domain as the site, URL
  parameters, fingerprinting attempts, page-level CMP shenanigans.

The strongest setup runs both. A [privacy-friendly browser](/handbook/privacy-friendly-browsers/)
with uBlock Origin on, pointed at a NextDNS / ControlD / Pi-hole
resolver, covers most of what's covereable without paying for a VPN
or going full Tor.

## A note on VPNs

VPNs are sometimes pitched as "privacy tools" but they solve a
**different problem** — hiding your IP and network identity from the
sites you visit, and your traffic from your ISP. They don't block
trackers (unless the VPN bundles a tracker blocker, which a few do).
A DNS sinkhole and a VPN can coexist; they answer different threats.
Don't substitute one for the other.

## Reading list

- **[Privacy-friendly browsers](/handbook/privacy-friendly-browsers/)** —
  the complementary layer that catches what DNS can't.
- **[Tracking pixels](/handbook/tracking-pixels/)** — what DNS
  sinkholes are blocking when they refuse `facebook.com/tr/...`
- **[NextDNS](https://nextdns.io/)** — hosted DNS service with
  per-device profiles, Delaware-incorporated with French founders and
  EU log-jurisdiction options.
- **[DNS4EU](https://joindns4.eu/)** — the EU's own public resolver,
  100% EU-hosted, free for individuals, operated by a Whalebone-led
  consortium under European Commission backing.
- **[ControlD](https://controld.com/)** — actively-developed
  alternative based in Toronto, Canada, with finer service-level
  blocking.
- **[Pi-hole documentation](https://docs.pi-hole.net/)** — the
  reference self-hosted setup.
- **[AdGuard Home](https://adguard.com/en/adguard-home/overview.html)** —
  modern self-hosted alternative with built-in encrypted DNS.

---

### Privacy-friendly browsers — what is built in and where extensions help

> Some browsers ship with anti-tracking, fingerprint resistance, and Global Privacy Control already on. Others give you a clean slate that you have to harden yourself. An honest look at the spectrum, where each major browser sits, and what extensions still add value on top.

Updated: 2026-05-09 · Source: https://consenttheater.org/handbook/privacy-friendly-browsers/

The simplest, most effective privacy upgrade most people can make is to
**switch their default browser**. Defaults matter more than settings: a
browser that ships with tracker blocking on for everyone protects far more
people than one that has the option buried three menus deep.

This article walks through the current spectrum honestly — what each major
browser actually does, where the tradeoffs are, and where extensions still
fill gaps even in the privacy-first ones.

## The privacy spectrum

Browsers fall into roughly three groups:

1. **Privacy-first by default** — strong anti-tracking, fingerprint
   resistance, and often GPC on out of the box. Zen, Brave, DuckDuckGo,
   LibreWolf, Mullvad, Tor Browser.
2. **Reasonable defaults you can harden** — solid baseline, but you should
   tweak some settings or add extensions. Firefox falls here.
3. **Need help to be private** — defaults work for the vendor's business
   model, not your privacy. Chrome, Edge, and Safari to a lesser extent.

The more privacy a browser provides by default, the more likely it is to
break some sites. That's a real tradeoff, not a hypothetical one.

## Browsers with privacy baked in

### Zen Browser

**Our pick** when you want a modern, polished browsing experience without
giving up privacy. Zen is a [Firefox fork](https://zen-browser.app/)
launched in 2024 with two design priorities: a contemporary UX (workspaces,
vertical tabs, deeply customisable layouts) and privacy-aware defaults out
of the box.

What's on by default:

- All Mozilla telemetry stripped
- Standard Firefox tracking protection enabled
- DNS-over-HTTPS available
- Same Global Privacy Control toggle as upstream Firefox (Settings →
  Privacy & Security)

**Tradeoffs.** Young project. The codebase is small, the team is
volunteer-scale, and the security audit story is "trust the upstream
Firefox audits, plus our defaults." That's a reasonable bet — Firefox
does the heavy lifting under the hood — but it's not hardened in the
LibreWolf sense. Worth picking if the modern UX matters to you and
you're comfortable being on a project that's actively maturing.

**Best for**: users who want a Firefox-engine browser with a contemporary
UX, telemetry stripped, and a reasonable privacy posture from the first
launch.

### Brave

The conservative alternative if you'd rather pick a browser with more
miles on it. Brave is a Chromium fork built by Brendan Eich's team, with
[Brave Shields](https://brave.com/shields/) on by default for every site:

- Blocks third-party trackers and cross-site cookie tracking
- Randomises the browser values that fingerprinters read, so each session
  presents a slightly different fingerprint
- Strips known ad-tech URL parameters
- Built-in [Tor mode](https://brave.com/privacy-features/) — a private
  window routed through the Tor network, handy for one-off sensitive
  lookups (not a substitute for Tor Browser)
- GPC on by default

**Tradeoffs.** Brave includes its own ad/rewards ecosystem (BAT), which
is opt-in but visible in the UI. In 2020 Brave was caught
[silently injecting referral codes](https://en.wikipedia.org/wiki/Brave_\(web_browser\)#Affiliate_link_controversy)
into some cryptocurrency-related URLs; they fixed it and apologised, but
it's worth knowing if you're picking on trust grounds. Built on Chromium,
so it inherits Google's engine (with the Privacy Sandbox / Topics hooks
removed by Brave).

**Best for**: users who want a strong privacy default with a more
battle-tested codebase than Zen's.

### Firefox + Total Cookie Protection

The mainstream privacy-aware choice. Firefox's
[Enhanced Tracking Protection](https://www.mozilla.org/en-US/firefox/features/block-content/)
is on by default, and "Total Cookie Protection" — every site gets its
own cookie jar, isolated from every other site — is a strong defence
against cross-site tracking. Firefox 120+ added a built-in GPC toggle
(see [our GPC article](/handbook/global-privacy-control/) for how to
flip it).

**Tradeoffs.** Mozilla's recent corporate direction has caused some
unease — TOS updates in 2025 and the acquisition of the Anonym ad-tech
company sit awkwardly with Firefox's privacy positioning. The browser
itself remains a strong privacy tool, but Mozilla's institutional trust
is a separate question that some users weigh differently than others.
Firefox is also the only mainstream browser not built on Chromium, which
matters for engine diversity on the web.

**Best for**: users who want a fully cross-platform browser (including
iOS as Firefox or Firefox Focus / Klar) and are fine with Mozilla's
governance.

### DuckDuckGo Browser

A free desktop and mobile browser from the DuckDuckGo search team. Their
focus is making strong privacy defaults *easy* — no settings to find, no
extensions to install. Tracker blocking, link tracking protection, CNAME
cloaking protection, and GPC are
[on by default](https://duckduckgo.com/duckduckgo-help-pages/privacy/web-tracking-protections).
The mobile apps include a "Fire Button" that wipes browsing data with one
tap.

**Tradeoffs.** Smaller team than Mozilla or Brave, fewer power-user
features. Desktop versions are newer and less mature than the mobile
apps where DuckDuckGo started. Telemetry exists but is documented and
narrow.

**Best for**: less-technical users where simplicity matters more than
configurability, and mobile-first audiences.

### LibreWolf

A community-maintained [Firefox fork](https://librewolf.net/) with
privacy and security defaults set high out of the box. Telemetry
removed, Mozilla services like Pocket disabled, hardening preferences
applied, uBlock Origin pre-installed.

**Tradeoffs.** Small volunteer team, slower update cadence than upstream
Firefox in some configurations, can break sites due to aggressive
defaults. No mobile version. Auto-update story varies by platform.

**Best for**: technically inclined users who want Firefox's engine with
none of Mozilla's corporate footprint, and who are comfortable
configuring their browser when something breaks.

### Mullvad Browser

A joint project of [Mullvad VPN](https://mullvad.net/en/browser) and the
Tor Project. Best understood as **Tor Browser without the Tor network** —
all the same fingerprinting resistance and hardening, but routed through
your normal connection (or, ideally, a VPN of your choice).

- No telemetry of any kind
- Aggressive anti-fingerprinting that keeps users in a small, identical
  bucket
- Cookies wiped between sessions by default
- Same security profile as Tor Browser without the speed cost

**Tradeoffs.** Strict by design: many sites detect "non-standard"
fingerprints and may break or challenge you. Not optimised for keeping
logins, syncing across devices, or running heavy web apps. Best paired
with a VPN, which is what its makers sell — though the browser itself
is free and works without any VPN.

**Best for**: users who want Tor-Browser-grade hardening for daily
browsing, without using the Tor network itself.

### Tor Browser — for the genuinely paranoid only

The reference for "real" anonymity on the web. Built by the
[Tor Project](https://www.torproject.org/), it routes every request
through the Tor network and is hardened against virtually every known
fingerprinting technique.

This one's worth knowing exists, but be honest with yourself about
whether you actually need it. Tor Browser was built for specific threat
models: investigative journalists, dissidents under regimes that surveil
their ISPs, researchers handling topics that can't be tied to their
real identity. **For the ordinary "I don't want Meta tracking me across
sites" goal, the browsers above are sufficient and far more usable.**

**Tradeoffs.** The Tor network adds hundreds of milliseconds per
request, and many services block known Tor exit IPs entirely. Banking,
e-commerce, and any account-protected site will routinely challenge or
refuse you. Daily-driver usage requires a tolerance for friction most
people don't have.

**Best for**: cases where the threat model genuinely includes a
state-level adversary or someone who could subpoena your ISP. For
everyone else: overkill, and you'll be happier on one of the options
above.

## Browsers that need help to be private

### Chrome

Built and maintained by Google, whose core business is targeted
advertising. Chrome still allows third-party cookies by default at time
of writing; Google's "Privacy Sandbox" / Topics API is the planned
replacement, and it's a different ad-tech mechanism, not the absence of
one. No native Global Privacy Control support. Telemetry to Google is
extensive.

You *can* harden Chrome with extensions and settings, but every privacy
gain is fighting the browser's defaults rather than working with them.

**Recommendation**: if you need Chromium for compatibility reasons,
prefer Brave instead.

### Edge

Microsoft's Chromium fork. Better than Chrome on some defaults
(tracking-prevention level setting), worse on others (Bing integration,
Microsoft account telemetry). No GPC. Same general comment as Chrome:
better Chromium options exist.

### Safari

The privacy story on Apple platforms. Intelligent Tracking Prevention
(ITP) is genuinely good — third-party cookies are blocked by default,
and link decoration tracking is partially mitigated. Safari does not,
however, support Global Privacy Control, which Apple has stated is a
deliberate choice in favour of their own ITP mechanism.

The result: Safari is a *reasonable* default on Apple devices, better
than Chrome by a wide margin, but missing the explicit opt-out signal
that GPC provides. On iOS, Safari's privacy features extend to all
browsers (Apple requires WebKit on iOS), so even Firefox / Brave on
iPhone are Safari underneath.

**Recommendation**: fine as a default, but pair with an ad/tracker
blocker extension and assume the GPC layer simply isn't there.

## What extensions still add — even on privacy browsers

Even on Brave or Firefox, a small set of extensions is worth running:

- **[uBlock Origin](https://ublockorigin.com/)** — the canonical
  ad/tracker blocker. Configurable, free, open-source, far more
  effective than browser-built-in shields on edge cases. Note that
  Manifest V3 in Chromium has limited what uBlock Origin can do on
  Chrome/Edge — Firefox and Firefox-forks remain the cleanest home for
  it.
- **[Privacy Badger](https://privacybadger.org/)** (EFF) — sets GPC
  automatically on browsers that don't ship it, learns and blocks
  third-party trackers heuristically.
- **ClearURLs** — strips tracking query parameters (`utm_*`, `fbclid`,
  `gclid`, etc.) from URLs as you click them.
- **LocalCDN** or **Decentraleyes** — serves common JS libraries
  (jQuery, Bootstrap) from a local copy instead of fetching them from a
  CDN, removing one tracking surface.
- **Cookie AutoDelete** — wipes cookies for closed tabs after a delay,
  retaining only whitelisted sites.
- **[ConsentTheater](https://codeberg.org/ConsentTheater/extension)**
  (full disclosure: this is our own project) — shows what trackers and
  cookies are present on the current site and what consent burden they
  carry under GDPR. It does not block; it informs.

Extensions handle things browser engines can't or won't:
finer-grained control over what loads, awareness of new trackers as they
emerge, audit-style visibility into what a site is doing.

## Tradeoffs to keep in mind

Three honest caveats apply across all the privacy browsers above:

**Sites can break.** The more aggressive the default, the more often
something doesn't work. Mullvad and Tor will break more sites than
Brave; Brave breaks more than Firefox. Plan to have a "fallback" browser
for the rare case where something has to work and won't.

**Browsers themselves have data flows.** Even privacy-positioned
browsers ship with some telemetry, sync services, and web compatibility
infrastructure. Mullvad and LibreWolf are the strictest "no telemetry"
options; the rest sit on a spectrum. Read the privacy policy of whatever
you pick, not the marketing page.

**Migration takes effort.** Bookmarks, passwords, autofill, two-factor
secrets — moving them takes a weekend. Plan it as a project rather than
a casual afternoon. Most browsers can import from Chrome/Edge directly.

## Recommendations by use case

- **Most users, easiest upgrade:** Zen Browser. Modern UX, Firefox
  engine, telemetry stripped, privacy posture from the first launch.
- **Want something more battle-tested:** Brave on desktop and mobile.
  Mature, strong defaults, almost no configuration needed.
- **Want to stay mainstream and cross-platform:** Firefox + Total
  Cookie Protection + uBlock Origin + GPC toggle on. Available on every
  platform, including iOS.
- **Mobile-first or non-technical users:** DuckDuckGo Browser. Less to
  understand, strong defaults.
- **Strong hardening for daily browsing:** LibreWolf or Mullvad Browser
  (Mullvad is stricter; LibreWolf is closer to a "regular" Firefox).
- **Apple ecosystem and don't want to switch from Safari:** Safari with
  an ad/tracker-blocker extension and the awareness that GPC isn't
  there.
- **Threat model genuinely includes a state-level adversary or
  subpoena-grade ISP risk:** Tor Browser, accepting the friction. For
  everyone else: overkill, see options above.

## Reading list

- **[Global Privacy Control — what it is and how to turn it on](/handbook/global-privacy-control/)** —
  the companion piece on the GPC signal these browsers carry.
- **[Tracking pixels — what they are and what consent rules apply](/handbook/tracking-pixels/)** —
  what these browsers are defending against.
- **[Brave Shields](https://brave.com/shields/)** — Brave's
  documentation of what it blocks by default.
- **[Zen Browser](https://zen-browser.app/)** — modern Firefox-fork.
- **[LibreWolf](https://librewolf.net/)** — community Firefox-hardening
  project.
- **[Mullvad Browser](https://mullvad.net/en/browser)** — Tor Project
  collaboration, no Tor network.
- **[Tor Browser](https://www.torproject.org/)** — reference for
  high-threat-model browsing.

---

# Law references

## GDPR Article 5 — Principles relating to processing of personal data

> The six core principles every controller must satisfy: lawfulness, purpose limitation, data minimisation, accuracy, storage limitation, and integrity. Plus the accountability rule.

Citation: *Regulation (EU) 2016/679* · Last reconciled 2026-04-25 · Canonical: https://eur-lex.europa.eu/eli/reg/2016/679/oj · Source: https://consenttheater.org/law/gdpr/art-5/

## In plain language

Article 5 is the rulebook every other GDPR rule references back to. Six principles describe **how** personal data may be handled, and a seventh — the accountability principle — says the controller must be able to **demonstrate compliance** with all of them.

1. **Lawfulness, fairness, transparency.** Tell the user what you're doing, in plain language, and have a legal basis (Article 6) for it.
2. **Purpose limitation.** Collect data for a specific, named purpose. Don't quietly reuse it for something else.
3. **Data minimisation.** Collect only what you actually need for the named purpose.
4. **Accuracy.** Keep the data correct and up to date; correct or delete if not.
5. **Storage limitation.** Don't keep the data longer than necessary.
6. **Integrity and confidentiality.** Protect the data against unauthorised processing, loss, destruction or damage.

The accountability principle in 5(2) is the one that turns the others into operating requirements: it isn't enough to *do* the right thing, you have to be able to *prove* you did. Logs, records, documented decisions, DPIA outputs.

**UK:** Article 5 of the [UK GDPR](/law/uk-gdpr-and-pecr/) mirrors the EU text — same six principles plus accountability — and is enforced by the ICO. See the mapping page for the full picture.

## How we use this on consenttheater.org

- Our tracker observations are framed as factual reproducible measurements precisely because Article 5(2) accountability requires controllers to demonstrate compliance — observations like ours give them (and their auditors) something concrete to work with.
- The [data_leak category](/methodology/#categories) in our catalogue is essentially a flag for breaches of **5(1)(f) integrity and confidentiality**: data that flows to a third party without authorisation.

## Original text

Reproduced verbatim from *Regulation (EU) 2016/679*, published by the Publications Office of the European Union on [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2016/679/oj). The official source is authoritative; this rendering is a navigation convenience.

> **1.** Personal data shall be:
>
> **(a)** processed lawfully, fairly and in a transparent manner in relation to the data subject ('lawfulness, fairness and transparency');
>
> **(b)** collected for specified, explicit and legitimate purposes and not further processed in a manner that is incompatible with those purposes; further processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes shall, in accordance with Article 89(1), not be considered to be incompatible with the initial purposes ('purpose limitation');
>
> **(c)** adequate, relevant and limited to what is necessary in relation to the purposes for which they are processed ('data minimisation');
>
> **(d)** accurate and, where necessary, kept up to date; every reasonable step must be taken to ensure that personal data that are inaccurate, having regard to the purposes for which they are processed, are erased or rectified without delay ('accuracy');
>
> **(e)** kept in a form which permits identification of data subjects for no longer than is necessary for the purposes for which the personal data are processed; personal data may be stored for longer periods insofar as the personal data will be processed solely for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) subject to implementation of the appropriate technical and organisational measures required by this Regulation in order to safeguard the rights and freedoms of the data subject ('storage limitation');
>
> **(f)** processed in a manner that ensures appropriate security of the personal data, including protection against unauthorised or unlawful processing and against accidental loss, destruction or damage, using appropriate technical or organisational measures ('integrity and confidentiality').
>
> **2.** The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1 ('accountability').

Prefer the canonical version? [Open this article on eur-lex.europa.eu →](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

---

## GDPR Article 6 — Lawfulness of processing

> The six legal bases for processing personal data: consent, contract, legal obligation, vital interests, public task, and legitimate interests.

Citation: *Regulation (EU) 2016/679* · Last reconciled 2026-04-25 · Canonical: https://eur-lex.europa.eu/eli/reg/2016/679/oj · Source: https://consenttheater.org/law/gdpr/art-6/

## In plain language

Article 6 is the heart of the GDPR. Before any organisation processes your personal data, it has to be able to point to one of **six lawful bases**. No basis, no processing — full stop.

Those six bases are:

1. **Consent** — you said yes (and the conditions in Article 7 are met).
2. **Contract** — processing is necessary to fulfil a contract with you, or to take steps at your request before entering one.
3. **Legal obligation** — the law requires the controller to process the data (e.g., tax-record retention).
4. **Vital interests** — processing is needed to protect someone's life.
5. **Public task** — the controller is exercising official authority or a task in the public interest.
6. **Legitimate interests** — the controller's interests are not overridden by your rights and freedoms. This is the most contested basis; it requires a balancing test and explicit reasoning.

For tracking on the open web, only consent (Article 6(1)(a)) and legitimate interests (Article 6(1)(f)) realistically apply. Most ad-tech, retargeting and cross-site profiling falls outside any defensible legitimate-interest argument because the interference with the data subject is too significant and consent is the only sustainable basis. That is why *strict consent* trackers in our catalogue need explicit consent to be lawful.

**UK:** Article 6 of the [UK GDPR](/law/uk-gdpr-and-pecr/) uses identical text and the same six lawful bases. The ICO interprets legitimate-interests under 6(1)(f) similarly to most EU authorities — narrow for ad-tech, generous for genuine functional needs.

## How we use this on consenttheater.org

- [Strict consent](/methodology/#required-strict) trackers are ones for which **only Article 6(1)(a) consent** is realistic — there is no defensible legitimate-interest claim under 6(1)(f).
- [Consent required](/methodology/#required) trackers also practically need 6(1)(a) consent under prevailing EU readings, even though operators sometimes attempt 6(1)(f) arguments.
- [Contested](/methodology/#contested) trackers are the ones where some authorities accept narrowly-scoped 6(1)(f) legitimate-interest reasoning and others insist on 6(1)(a) consent.

## Original text

Reproduced verbatim from *Regulation (EU) 2016/679*, published by the Publications Office of the European Union on [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2016/679/oj). The official source is authoritative; this rendering is a navigation convenience.

> **1.** Processing shall be lawful only if and to the extent that at least one of the following applies:
>
> **(a)** the data subject has given consent to the processing of his or her personal data for one or more specific purposes;
>
> **(b)** processing is necessary for the performance of a contract to which the data subject is party or in order to take steps at the request of the data subject prior to entering into a contract;
>
> **(c)** processing is necessary for compliance with a legal obligation to which the controller is subject;
>
> **(d)** processing is necessary in order to protect the vital interests of the data subject or of another natural person;
>
> **(e)** processing is necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;
>
> **(f)** processing is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data, in particular where the data subject is a child.
>
> Point (f) of the first subparagraph shall not apply to processing carried out by public authorities in the performance of their tasks.
>
> **2.** Member States may maintain or introduce more specific provisions to adapt the application of the rules of this Regulation with regard to processing for compliance with points (c) and (e) of paragraph 1 by determining more precisely specific requirements for the processing and other measures to ensure lawful and fair processing including for other specific processing situations as provided for in Chapter IX.
>
> **3.** The basis for the processing referred to in point (c) and (e) of paragraph 1 shall be laid down by:
>
> **(a)** Union law; or
>
> **(b)** Member State law to which the controller is subject.
>
> The purpose of the processing shall be determined in that legal basis or, as regards the processing referred to in point (e) of paragraph 1, shall be necessary for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller. That legal basis may contain specific provisions to adapt the application of rules of this Regulation, inter alia: the general conditions governing the lawfulness of processing by the controller; the types of data which are subject to the processing; the data subjects concerned; the entities to, and the purposes for which, the personal data may be disclosed; the purpose limitation; storage periods; and processing operations and processing procedures, including measures to ensure lawful and fair processing such as those for other specific processing situations as provided for in Chapter IX. The Union or the Member State law shall meet an objective of public interest and be proportionate to the legitimate aim pursued.
>
> **4.** Where the processing for a purpose other than that for which the personal data have been collected is not based on the data subject's consent or on a Union or Member State law which constitutes a necessary and proportionate measure in a democratic society to safeguard the objectives referred to in Article 23(1), the controller shall, in order to ascertain whether processing for another purpose is compatible with the purpose for which the personal data are initially collected, take into account, inter alia:
>
> **(a)** any link between the purposes for which the personal data have been collected and the purposes of the intended further processing;
>
> **(b)** the context in which the personal data have been collected, in particular regarding the relationship between data subjects and the controller;
>
> **(c)** the nature of the personal data, in particular whether special categories of personal data are processed, pursuant to Article 9, or whether personal data related to criminal convictions and offences are processed, pursuant to Article 10;
>
> **(d)** the possible consequences of the intended further processing for data subjects;
>
> **(e)** the existence of appropriate safeguards, which may include encryption or pseudonymisation.

Prefer the canonical version? [Open this article on eur-lex.europa.eu →](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

---

## GDPR Article 7 — Conditions for consent

> What it means to "have consent" under the GDPR — burden of proof, plain language, the right to withdraw, and freely-given conditions.

Citation: *Regulation (EU) 2016/679* · Last reconciled 2026-04-25 · Canonical: https://eur-lex.europa.eu/eli/reg/2016/679/oj · Source: https://consenttheater.org/law/gdpr/art-7/

## In plain language

Article 6(1)(a) says you can process personal data if the user consents. Article 7 says **what counts as consent**. The two are inseparable — a "yes" that doesn't satisfy Article 7 isn't legally a "yes".

The four pillars of valid consent under Article 7:

1. **Demonstrable.** The controller must be able to prove the user consented. No log, no consent.
2. **Distinct, intelligible, plain language.** If consent is requested as part of a longer statement (terms of service, privacy notice), the consent ask must be presented in a way that is clearly distinguishable from the other matter and written in plain language.
3. **Withdrawable, and as easy to withdraw as to give.** The user must be informed of this before consenting, and the withdrawal flow can't be designed to be harder than the give flow.
4. **Freely given.** Conditioning a service on consent that isn't strictly necessary for that service is a strong signal the consent isn't free. So is a significant power imbalance (e.g., between an employer and an employee).

In practice, the EDPB and most national authorities have interpreted these conditions to mean that **cookie banners with a prominent "Accept" button and a hidden, multi-click "Reject" path are not free consent**, and the consent they collect is invalid.

**UK:** Article 7 of the [UK GDPR](/law/uk-gdpr-and-pecr/) is identical. The ICO has been particularly active on dark-pattern banners — its 2023–2024 statements explicitly target sites where Reject takes more clicks than Accept.

## How we use this on consenttheater.org

- Our [classification process](/methodology/#process) explicitly checks how a tracker maps to Article 7's "freely given" and "as easy to withdraw as to give" conditions.
- The browser extension's banner-quality observations (missing reject button, unequal button parity, dark patterns) are practical signals that Article 7 conditions are likely *not* met — even when a banner exists.

## Original text

Reproduced verbatim from *Regulation (EU) 2016/679*, published by the Publications Office of the European Union on [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2016/679/oj). The official source is authoritative; this rendering is a navigation convenience.

> **1.** Where processing is based on consent, the controller shall be able to demonstrate that the data subject has consented to processing of his or her personal data.
>
> **2.** If the data subject's consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language. Any part of such a declaration which constitutes an infringement of this Regulation shall not be binding.
>
> **3.** The data subject shall have the right to withdraw his or her consent at any time. The withdrawal of consent shall not affect the lawfulness of processing based on consent before its withdrawal. Prior to giving consent, the data subject shall be informed thereof. It shall be as easy to withdraw as to give consent.
>
> **4.** When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.

Prefer the canonical version? [Open this article on eur-lex.europa.eu →](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

---

## GDPR Article 17 — Right to erasure ("right to be forgotten")

> When a data subject can require erasure, what exceptions apply (free expression, public interest, legal claims, archiving for research), and how it interacts with public publication.

Citation: *Regulation (EU) 2016/679* · Last reconciled 2026-04-25 · Canonical: https://eur-lex.europa.eu/eli/reg/2016/679/oj · Source: https://consenttheater.org/law/gdpr/art-17/

## In plain language

You can ask a controller to delete personal data about you. The controller has to comply **without undue delay** if any of the listed grounds apply — for example, the data is no longer needed, you withdrew consent, you objected to processing, or the data was processed unlawfully.

But **erasure is not absolute**. Article 17(3) lists exceptions where the right does not apply, including:

- Freedom of expression and information.
- Compliance with a legal obligation.
- Public interest in the area of public health.
- **Archiving in the public interest, scientific or historical research, or statistical purposes** — provided the appropriate safeguards under [Article 89(1)](/law/gdpr/art-89/) are in place.
- Establishment, exercise or defence of legal claims.

The research / archiving exception is the one that allows the Internet Archive, academic GDPR-research datasets, and the planned ConsentTheater snapshots dataset to maintain historical records even when an erasure request would otherwise apply. It is conditional, not unlimited — see Article 89.

**UK:** Article 17 of the [UK GDPR](/law/uk-gdpr-and-pecr/) mirrors the EU text — same grounds, same exceptions including 17(3)(d) for archiving and research. The ICO publishes plain-language guidance on the right.

## How we use this on consenttheater.org

- The website's [privacy policy](/privacy/) describes how we handle the limited request metadata our infrastructure provider sees.
- For the planned snapshots dataset (see the [server repository](https://codeberg.org/ConsentTheater/server)), Article 17(3)(d) and Article 89(1) are the legal anchor for keeping historical observations in append-only git history while still honouring legitimate takedown requests for active scanning.

## Original text

Reproduced verbatim from *Regulation (EU) 2016/679*, published by the Publications Office of the European Union on [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2016/679/oj). The official source is authoritative; this rendering is a navigation convenience.

> **1.** The data subject shall have the right to obtain from the controller the erasure of personal data concerning him or her without undue delay and the controller shall have the obligation to erase personal data without undue delay where one of the following grounds applies:
>
> **(a)** the personal data are no longer necessary in relation to the purposes for which they were collected or otherwise processed;
>
> **(b)** the data subject withdraws consent on which the processing is based according to point (a) of Article 6(1), or point (a) of Article 9(2), and where there is no other legal ground for the processing;
>
> **(c)** the data subject objects to the processing pursuant to Article 21(1) and there are no overriding legitimate grounds for the processing, or the data subject objects to the processing pursuant to Article 21(2);
>
> **(d)** the personal data have been unlawfully processed;
>
> **(e)** the personal data have to be erased for compliance with a legal obligation in Union or Member State law to which the controller is subject;
>
> **(f)** the personal data have been collected in relation to the offer of information society services referred to in Article 8(1).
>
> **2.** Where the controller has made the personal data public and is obliged pursuant to paragraph 1 to erase the personal data, the controller, taking account of available technology and the cost of implementation, shall take reasonable steps, including technical measures, to inform controllers which are processing the personal data that the data subject has requested the erasure by such controllers of any links to, or copy or replication of, those personal data.
>
> **3.** Paragraphs 1 and 2 shall not apply to the extent that processing is necessary:
>
> **(a)** for exercising the right of freedom of expression and information;
>
> **(b)** for compliance with a legal obligation which requires processing by Union or Member State law to which the controller is subject or for the performance of a task carried out in the public interest or in the exercise of official authority vested in the controller;
>
> **(c)** for reasons of public interest in the area of public health in accordance with points (h) and (i) of Article 9(2) as well as Article 9(3);
>
> **(d)** for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes in accordance with Article 89(1) in so far as the right referred to in paragraph 1 is likely to render impossible or seriously impair the achievement of the objectives of that processing; or
>
> **(e)** for the establishment, exercise or defence of legal claims.

Prefer the canonical version? [Open this article on eur-lex.europa.eu →](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

---

## GDPR Article 89 — Safeguards and derogations relating to processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes

> The research-and-archiving carve-out that lets datasets like ours preserve historical observations under appropriate safeguards, even when other rights would otherwise apply.

Citation: *Regulation (EU) 2016/679* · Last reconciled 2026-04-25 · Canonical: https://eur-lex.europa.eu/eli/reg/2016/679/oj · Source: https://consenttheater.org/law/gdpr/art-89/

## In plain language

Article 89 is the doorway through which research projects, archives, and statistical institutions can keep doing what they do without colliding with every individual data-subject right in Chapter III of the GDPR. The deal is simple: **if you process personal data for archiving in the public interest, scientific or historical research, or statistical purposes — and you have appropriate safeguards in place — Member States may exempt you from a number of otherwise-binding obligations.**

What "appropriate safeguards" means in practice:

- Technical and organisational measures to ensure data minimisation.
- Pseudonymisation where the research goal can be reached that way.
- Aggregation or anonymisation when individual identification is no longer required.
- Restricted access; clear governance.

Article 89 is the legal anchor for the Internet Archive, library digitisation programmes, academic datasets, and projects like the planned ConsentTheater snapshots archive. It does **not** give a free pass — derogations are conditional on the safeguards being demonstrably in place — but it permits historical records to survive an Article 17 erasure request when erasure would "render impossible or seriously impair" the achievement of the research/archiving goal.

**UK:** Article 89 of the [UK GDPR](/law/uk-gdpr-and-pecr/) carries the same safeguards regime, and Schedule 2 of the Data Protection Act 2018 makes the corresponding domestic-law derogations.

## How we use this on consenttheater.org

- The append-only git history of the planned [snapshots dataset](https://codeberg.org/ConsentTheater/server) is justified under Article 89 in conjunction with [Article 17(3)(d)](/law/gdpr/art-17/) — historical scans remain in the chain because rewriting them would defeat the integrity of the research archive.
- Even with this anchor, our snapshots policy provides for cessation of *active* scanning on substantiated takedown requests, and for visible correction of any factually erroneous record. That is the kind of safeguard Article 89(1) requires.

## Original text

Reproduced verbatim from *Regulation (EU) 2016/679*, published by the Publications Office of the European Union on [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/reg/2016/679/oj). The official source is authoritative; this rendering is a navigation convenience.

> **1.** Processing for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes, shall be subject to appropriate safeguards, in accordance with this Regulation, for the rights and freedoms of the data subject. Those safeguards shall ensure that technical and organisational measures are in place in particular in order to ensure respect for the principle of data minimisation. Those measures may include pseudonymisation provided that those purposes can be fulfilled in that manner. Where those purposes can be fulfilled by further processing which does not permit or no longer permits the identification of data subjects, those purposes shall be fulfilled in that manner.
>
> **2.** Where personal data are processed for scientific or historical research purposes or statistical purposes, Union or Member State law may provide for derogations from the rights referred to in Articles 15, 16, 18 and 21 subject to the conditions and safeguards referred to in paragraph 1 of this Article in so far as such rights are likely to render impossible or seriously impair the achievement of the specific purposes, and such derogations are necessary for the fulfilment of those purposes.
>
> **3.** Where personal data are processed for archiving purposes in the public interest, Union or Member State law may provide for derogations from the rights referred to in Articles 15, 16, 18, 19, 20 and 21 subject to the conditions and safeguards referred to in paragraph 1 of this Article in so far as such rights are likely to render impossible or seriously impair the achievement of the specific purposes, and such derogations are necessary for the fulfilment of those purposes.
>
> **4.** Where processing referred to in paragraphs 2 and 3 serves at the same time another purpose, the derogations shall apply only to processing for the purposes referred to in those paragraphs.

Prefer the canonical version? [Open this article on eur-lex.europa.eu →](https://eur-lex.europa.eu/eli/reg/2016/679/oj)

---

## ePrivacy Directive Article 5 — Confidentiality of the communications

> The "cookie article" — the rule that storing or accessing information on a user's terminal device requires prior informed consent, with a narrow strictly-necessary exemption.

Citation: *Directive 2002/58/EC* · Last reconciled 2026-04-25 · Canonical: https://eur-lex.europa.eu/eli/dir/2002/58/oj · Source: https://consenttheater.org/law/eprivacy/art-5/

## In plain language

The ePrivacy Directive predates the GDPR by 14 years but is still the rule that governs **storing or accessing information on a user's terminal device** — including cookies, localStorage, IndexedDB, fingerprinting probes, and similar techniques. Article 5 is the part everyone in the cookie-banner industry actually argues about.

Article 5(3) — the famous "cookie article" — sets a default rule: **you may not store information in, or read information from, a user's terminal equipment unless the user has given prior informed consent**. There are two narrow exemptions:

1. The sole purpose is to **carry out the transmission of a communication** over an electronic communications network.
2. The storage or access is **strictly necessary** in order to provide an information society service explicitly requested by the user.

Both exemptions are read narrowly by EU regulators. "Strictly necessary" does not mean "convenient", "useful", or "the user expects this to work" — it means the service literally cannot function without that storage. Most analytics, marketing, A/B testing, advertising and personalisation cookies are explicitly out of scope.

The "consent" required by Article 5(3) is the GDPR's definition of consent — see [Article 7](/law/gdpr/art-7/). The two regulations are stitched together: ePrivacy says *you need consent*, GDPR says *this is what consent looks like*.

**UK:** The UK transposed ePrivacy via PECR (SI 2003/2426). **Regulation 6 of PECR** carries the same prior-consent requirement and the same "strictly necessary" exemption for cookies and similar technologies. See the [UK mapping page](/law/uk-gdpr-and-pecr/).

## How we use this on consenttheater.org

- The [minimal](/methodology/#minimal) consent burden tier in our catalogue covers exactly the kinds of trackers that fall under the Article 5(3) "strictly necessary" carve-out — CSRF tokens, language preferences, cart state.
- Every other tier ([contested](/methodology/#contested), [required](/methodology/#required), [strict consent](/methodology/#required-strict)) is what Article 5(3) calls "outside strictly necessary" — needs prior informed consent before any storage or access happens on the user's device.
- The browser extension and the planned snapshots collector both observe page traffic **before** any user interaction with the consent banner. This is the moment Article 5(3) actually applies — once consent is given (or deliberately rejected), the legal regime changes.

## Original text

Reproduced verbatim from *Directive 2002/58/EC*, published by the Publications Office of the European Union on [eur-lex.europa.eu](https://eur-lex.europa.eu/eli/dir/2002/58/oj). The official source is authoritative; this rendering is a navigation convenience.

> **1.** Member States shall ensure the confidentiality of communications and the related traffic data by means of a public communications network and publicly available electronic communications services, through national legislation. In particular, they shall prohibit listening, tapping, storage or other kinds of interception or surveillance of communications and the related traffic data by persons other than users, without the consent of the users concerned, except when legally authorised to do so in accordance with Article 15(1). This paragraph shall not prevent technical storage which is necessary for the conveyance of a communication without prejudice to the principle of confidentiality.
>
> **2.** Paragraph 1 shall not affect any legally authorised recording of communications and the related traffic data when carried out in the course of lawful business practice for the purpose of providing evidence of a commercial transaction or of any other business communication.
>
> **3.** Member States shall ensure that the storing of information, or the gaining of access to information already stored, in the terminal equipment of a subscriber or user is only allowed on condition that the subscriber or user concerned has given his or her consent, having been provided with clear and comprehensive information, in accordance with Directive 95/46/EC, inter alia, about the purposes of the processing. This shall not prevent any technical storage or access for the sole purpose of carrying out the transmission of a communication over an electronic communications network, or as strictly necessary in order for the provider of an information society service explicitly requested by the subscriber or user to provide the service.

Note: the reference to Directive 95/46/EC must be read as a reference to the GDPR by virtue of Article 94(2) of Regulation (EU) 2016/679. The "consent" required here is therefore the consent defined in [GDPR Article 7](/law/gdpr/art-7/).

Prefer the canonical version? [Open this article on eur-lex.europa.eu →](https://eur-lex.europa.eu/eli/dir/2002/58/oj)

---

# Project pages

Hand-curated pages (about, methodology, privacy, licensing, etc.) are not bundled in this file because they are visually rich .astro source and their lossy HTML→MD conversion lives at the URLs below — fetch individually if needed:

- [About](https://consenttheater.org/about.md)
- [Methodology](https://consenttheater.org/methodology.md)
- [Privacy policy](https://consenttheater.org/privacy.md)
- [License (full AGPL-3.0 text)](https://consenttheater.org/license.md)
- [Acknowledgements](https://consenttheater.org/acknowledgements.md)
- [Browser extension](https://consenttheater.org/extension.md)
- [UK GDPR & PECR mapping](https://consenttheater.org/law/uk-gdpr-and-pecr.md)