Policy Roast: Decline All Should Mean Decline All
If a site says decline all but still fires trackers, the banner is not consent. It is evidence.
If a site asks whether it can track you and you click Decline All, the deal is simple.
You asked. They said no. You stop.
When trackers still fire anyway, the consent banner stops being a privacy control and starts being liability theater.
The pattern: consent banners as evidence shields
A lot of consent UX is not built to enforce a user choice. It is built to create a screenshot a company can wave around later.
Look, Your Honor, there was a banner.
That is the problem.
The banner becomes an artifact that looks like compliance, while the underlying implementation still lets tag managers, analytics scripts, ad tech, or embedded third parties load before the refusal actually matters. The user sees a choice. The network trace sees a lie.
This is why these disputes keep surviving. The core issue is not exotic privacy theory. It is representational drift between what the interface promises and what the system does.
Why this keeps failing in production
The engineering failure modes are boring, which is exactly why they are dangerous.
1) The site blocks some tags, but not the container
Teams often block individual trackers while still loading the tag manager or consent framework in a way that allows downstream scripts to execute. Once the container loads, your deny rule is already compromised.
2) Consent is treated like a rollback, not a gate
If tracking scripts initialize on page load and you try to reverse them after the user clicks, you have already lost. The request has gone out. The cookie is set. The leakage happened.
3) Third-party code wins the race
Even when the first-party app behaves, an embedded video player, chat widget, analytics library, or ad-tech dependency can drop identifiers before your preference state is fully available.
4) Product teams optimize for measurement, not refusal
This is the ugly one. Sometimes the implementation is not broken. It is faithful to the wrong priority. The business wants attribution, retargeting, and funnel data badly enough that refusal becomes a soft suggestion instead of a hard deny rule.
That is not a glitch. That is governance.
What regulators are already saying
This is not a fringe theory from privacy absolutists.
The CNIL has been explicit that refusing cookies should be as easy as accepting them. The UK ICO has pushed for Reject All parity as well, and its guidance on cookies makes the baseline plain: non-essential tracking technologies need valid consent before they fire. TikTok was fined by the CNIL in part because users were not given an equally easy path to refuse cookies.
That matters because it shifts the fight from aesthetics to enforcement logic.
Once regulators say refusal must be real, a banner that says Decline All while trackers still run starts to look less like a compliance miss and more like deceptive system design.
The legal problem is not technical. It is representational.
If your interface communicates Decline All and your implementation still allows non-essential tracking, you are creating at least four kinds of exposure.
- Deceptive-practices theories You represented a control that did not exist in practice.
- Consent invalidation If refusal is not honored, the tracking event is much harder to defend as consensual.
- Discovery pain Once plaintiffs get logs, network traces, tag configurations, and consent-state records, this becomes a timeline story. Those are expensive stories to lose.
- Product-liability style arguments about design choices Not classic product liability, obviously, but the same logic appears. You made a predictable design choice, users relied on it, and the harm came from the mismatch between promise and behavior.
This paragraph is doing too much work if we call that a cookie bug. It is really a control-integrity failure.
What a defensible consent control looks like
If you want the control to survive both a regulator and a deposition, the standard is not mysterious.
- Default deny No non-essential tracking loads until affirmative consent exists.
- Gate execution at the container level Do not just block the downstream tag. Block the mechanism that can call it.
- Validate with network traces, not banner copy The test is what leaves the browser, not what the designer intended.
- Keep machine-verifiable evidence You need a record of consent state, timing, and what scripts executed under that state.
- Make refusal as easy as acceptance If Accept All is one click and refusal is a scavenger hunt, you are already inviting scrutiny.
What to do this week
- Run a real decline-all test in production. Open the site fresh, click Decline All, and inspect the network trace. Do not trust screenshots.
- Map every third-party script that can set identifiers before consent is available. If you cannot list them, you do not control them.
- Review your tag manager logic like it is an access-control system. Because it is.
- Ask one hard question internally. If decline-all reduces measurement quality, did the team silently choose analytics over consent enforcement?
That answer tells you whether the problem is engineering debt or policy theater.
