About this blog
Legal commentary stops at the requirement. Vendor content ends at a product. This site is the part in between: what a system actually does, next to how it should have been built.
How it started
In 2021 a consumer organisation asked Konrad Haldorn to test a Dutch webshop. His report showed an analytics request leaving the browser after the visitor had rejected tracking, with the timestamps, the browser version and the exact steps. Companies usually answer that kind of report with a statement from the press office. This one sent three pages from the engineer who had traced the bug, Milan Rook, and a request to run the test again. The fix held.
They kept writing. Konrad would send a capture from some other site and Milan would describe the architecture he thought had produced it, usually correctly, and say so when he was wrong. By early 2026 the two of them had noticed that those emails covered ground almost nobody published. So they started writing them down here.
Konrad tests what systems do. Milan explains how to build them so they survive that kind of test. Each reads the other's drafts before anything goes out. The opening posts say more: Why we started complianceblog.dev and Law, translated into engineering.
Who writes here
- Konrad Haldorn, technical investigator in Berlin. The systems behind the rules.
- Milan Rook, software engineer in Rotterdam. Law, translated into engineering.
Neither of us is a lawyer. Where an article reaches a question that needs one, it says so instead of guessing.
Four words
Every finding on this site is sorted into one of four categories, and the category is stated in the text rather than left for the reader to guess. They appear as stamps in the articles.
- Observed
Seen 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
Stated by a company, a regulator, a researcher, a news outlet.
The authority reports that the banner was changed after the hearing.
- Inferred
A reasonable reading of the available evidence, and only that.
The timing suggests the tag manager loaded before the consent state resolved.
- Unresolved
A question the available evidence cannot settle.
Whether the same behaviour appears for signed-in users is unresolved.
What we will not do
If a request left after rejection, the headline says that a request left after rejection, and nothing larger. A privacy policy is evidence of what a company says, so we never read it as a description of what the software does. One capture from one browser on one day is reported as that, and repeated before it is called stable. A test is described as run only when it was run; a scenario we only imagined is labelled as illustrative in the first paragraph that describes it. And anything we say about a product comes from its own public pages, read on a date the article states.
How to reach us
Write to hello@complianceblog.dev. If you have seen something leave a browser that you did not expect, send 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. We publish a reader's finding only after we have reproduced it ourselves, we do not name the site before that, and we credit you only if you ask us to.
Corrections
If something here is wrong, write to the same address and name the article and the sentence. A factual error is corrected in the text and the article shows the date it was updated. An inference that turned out wrong stays on the page, marked as wrong, with the correction under it, so you can see what we got wrong and when. We answer every correction we receive, including the ones we end up disagreeing with. We have not had to use this policy yet. We expect to.