Why we started complianceblog.dev

The gap between the requirement and the banner

The requirement side is well served. The Court of Justice of the European Union said on 1 October 2019, in the Planet49 case, that consent to storing cookies is not validly given through a pre-checked box the user has to deselect. The GDPR has applied since 25 May 2018. Regulators have published banner guidance in most languages of the Union. If you want to know what the rule is, you can find it in an afternoon.

The implementation side is served by people who sell implementations. Their content is not dishonest, but it is written to end at a product. Install the banner, pick a template, and you are covered. That sentence is doing a lot of work, and the work is invisible. A banner records a choice. Whether the rest of the site honours that choice is a separate question, and it is the question that decides whether a visitor who clicked “reject” was tracked anyway.

Between those two bodies of writing there is almost nothing: no one testing what a site does after the choice, and no one explaining how the site should have been built so that the test passes. That is the part in between, and we intend to publish it.

The finding that started the correspondence

In 2021 a consumer organisation asked me to test a Dutch webshop. The brief was ordinary: open the site in a clean browser profile, reject optional tracking, record what leaves. My report showed an analytics request leaving the browser after the visitor had rejected tracking. It carried the timestamps, the browser version and the exact steps, because that is how I was taught to write up a failed test when I worked in payments software in Frankfurt, and it is still how I write one.

I expected the usual reply. Companies tend to answer that kind of report with a statement from the press office, written to be quoted and not to be checked. This one sent a three-page technical explanation from the engineer who had traced the bug. His name was Milan. He had reproduced the fault within an hour of someone posting my report in his team chat: the tag manager loaded before the consent state had resolved, and it treated “unknown” as permission. He described the cause, described the fix, and asked me to run my test again.

I ran it again. The fix held.

A press statement asks you to believe it. A three-page explanation asks you to check it.

We kept writing after that. I would send a network capture from some other site, and Milan would describe the architecture he thought had produced it. He was usually right, and when he was not, he said so instead of defending the guess. I liked that he never let a guess pass as a finding. He says he liked the same thing about me, though I suspect he found it irritating for the first year.

By early 2026 we had noticed that those emails covered ground almost nobody published, and that the people who needed it most, the developers and marketers and compliance leads running the sites, were reading either the law firms or the vendors because there was nothing else.

What we will publish

Two things, side by side.

I test what systems do. A post from me starts with a claim a reader can check, describes the setup well enough that another person could repeat it, reports what happened before interpreting it, and ends with what the test does not establish. When a published test is real, it carries the date, the browser and its settings, the pages, the steps, and links to the primary sources. When a scenario is illustrative, it says so in the first paragraph that describes it, and it uses no first person.

Milan explains how to build systems so they survive that kind of test. His opening post, Law, translated into engineering, says what that means in his own words. The short version: a legal requirement becomes an architectural decision, the decision has trade-offs, and somewhere in the design there is a point where the team needs a lawyer rather than another workaround.

We read each other’s drafts before anything goes out. Milan is the harder editor. He tends to come back with the one failure mode I did not test for, which is the kind of editing I would pay for if he charged.

Four words that organise everything here

Every finding on this site is sorted into one of four categories, and the category is stated in the prose rather than left for the reader to guess.

Observed means I saw it directly: in a test, a document, a log, a page. “The browser sent a request to the analytics endpoint before the banner was answered.”

Reported means someone else said it: a company, a regulator, a researcher, a news outlet. “The authority reports that the banner was changed after the hearing.” We repeat the claim with the source linked, and we do not upgrade it to observed because we find it plausible.

Inferred means it is a reasonable reading of the evidence, and only that. “The timing suggests the tag manager loaded before the consent state resolved.” An inference can be wrong. We will say when one was.

Unresolved means the evidence cannot settle it. “Whether the same behaviour appears for signed-in users is unresolved.” Attaching an unresolved question to a finding tells the reader where the evidence ran out, which is more useful than pretending it did not.

The reason to insist on this is practical. A report that overstates its evidence is easy to dismiss, and the dismissal takes the accurate parts down with it. The 2021 report worked because it claimed exactly what the capture showed and nothing more, which is why an engineer could reproduce it in an hour instead of arguing with it for a week.

What you should not expect

No scandal headlines. If a capture shows a request leaving after rejection, the headline will say that a request left after rejection. It will not say that a company is breaking the law, because a capture alone does not establish that. To get from the request to a legal conclusion you would need to know what the request carried, which rules apply in that jurisdiction, what purpose the processing served, who the controller is, and whether an exception applies. Some of that is legal judgement, and I am not a lawyer. I spent a year of evenings on a data protection law certificate so that I could understand what my clients needed from my captures, and the main thing it taught me is where my competence ends. If one of our posts raises a legal question you need to act on, ask someone qualified in your jurisdiction.

No treatment of a privacy policy as a description of live behaviour. A policy is evidence of what a company says. The browser is evidence of what its software does. When the two disagree, the disagreement is the finding, and the policy does not win by being the official document.

No single test presented as proof that every visitor sees the same thing. Consent tools behave differently on a first visit, a return visit, a signed-in session, a different country, a different experiment cohort. One capture can reveal a problem. Repetition establishes whether it is stable, and when we have not repeated, we will say so.

And no pretending that a test we did not run was run. That rule sounds too obvious to write down. It is written down because the temptation to write “I opened the page” about a scenario one merely imagined is real, and the sentence reads the same either way.

The policy describes one behaviour. The browser produced another. That disagreement is the finding.

The question I cannot settle from outside

There is a limit to this whole method that I want to name rather than hide. From the outside, I can see what leaves a browser. I cannot see what the receiving server kept, for how long, or who it was joined with. A request carrying a client identifier to an analytics endpoint is observed. What happened to the identifier after that is unresolved, and no amount of repetition on my side will resolve it. The only people who can answer are the ones inside the system, and most of them are not writing to consumer organisations. Milan is one of the few who did. How much of compliance is visible from outside at all is a question I expect this site to keep circling without closing.

Send us what you captured

If you have seen something leave a browser that you did not expect, send it. What helps: the page address, the date and time, the browser and its version, whether the profile was clean, the steps you took, and the request you think should not have been there, as a saved HAR file or a screenshot of the network panel. The address is on the about page.

Two rules on our side. We will not publish a finding from a reader’s capture until we have reproduced it ourselves, and we will not name the site before that. And we credit you only if you ask us to.