We checked our 39 sites. Four clearly need a banner.

What we checked

Our 39 sites fall into two groups. 27 are price-comparison sites on one shared platform: a single Rust program behind Cloudflare that serves every site from the same templates. The other 12 are separate sites, among them a studio site, a personal blog, product sites and a few directories, most of them static Astro sites on Cloudflare Workers.

For each site we first wrote down what the code loads. Then we opened the pages in a browser and looked at what it actually got before we clicked anything: cookies set by the server or by scripts, localStorage and sessionStorage, and every request to another domain. On 23 October we did that for the pages where we expected trouble: a product page on the shared platform, a blog post with videos and a template preview. On 31 October we did it for the homepage of all 39 sites.

This was a spot check, not a full crawl. A page we didn’t open could still load something we missed, and one did: see the bug further down. Checking every template, again after every change, is the job we’re building Gatelamp’s scanner for.

No cookies before a choice

None of the 39 homepages set a cookie on the first visit, from the server or from a script. In the browser, every request to another domain went to one we run ourselves: our Umami on analytics.madebyspin.com, our sponsor slots or one of our own embeds. Two sites keep a small flag in sessionStorage, and the others stored nothing. That check didn’t catch images that only load as you scroll to them, which is where the bug further down was hiding.

Umami is the analytics tool on nearly all of them. We host it ourselves, it sets no cookies and we share its data with nobody. In the Netherlands, measuring with no or little impact on privacy needs no consent (Article 11.7a of the Telecommunicatiewet), and by our reading our setup fits that exception.

The shared platform stores two things, and only when a visitor asks for them: a login cookie when someone signs in, and their light or dark theme in localStorage when they pick one.

When a visitor clicks through to a shop, an affiliate network may set a cookie on its own domain, and our own redirect adds a click ID to the link. The EDPB counts tracking links like that under the ePrivacy rule and names affiliate marketing as its example. All of this belongs in our cookie text, which doesn’t mention it yet. Whether it also needs consent depends on the country.

In the Netherlands, the 2014 explanatory notes to the law say affiliate cookies fall under the exception for measuring how well a service works, as long as they’re used only to work out which link led to a sale. We found nothing from the Dutch regulator confirming that. In France, the Conseil d’État upheld the position of the regulator, the CNIL, in 2022: trackers used only to bill affiliate commission aren’t exempt, so they need consent. Germany probably goes the same way. Its regulators say a business need is no reason for an exception, though we found no ruling on affiliate links alone.

All 27 price-comparison sites have French pages and all but one have German pages, and they don’t ask for this yet. That’s the biggest open question in this audit.

Four sites need a banner, for one reason

madebyspin.com, fijnhier.nl, volkarakter.nl and selectedscreens.com use Google Analytics 4 next to Umami. GA4 sets cookies and sends visit data to Google, so it needs consent. These four sites ask first, with “Not now” and “Allow analytics” as buttons of equal weight, and Google Analytics stays off until someone accepts. Before a choice, none of the four contacted Google or set a cookie.

The weak spot is how it’s built: the same banner component, copied into four codebases. Four copies drift apart, and none of them keeps a record of who agreed to what. That’s the problem Gatelamp started from.

One site needed a banner, and now doesn’t

On 18 October, frankspin.com embedded YouTube videos in three posts with YouTube’s standard embed code. Every visit to those posts contacted Google before anyone pressed play.

Since 19 October each video is a thumbnail served from the site itself, with a play button and a line saying it loads from YouTube. The player loads from youtube-nocookie.com only after a click. On 23 October a post with a video made no requests to YouTube or Google before the click. The player still writes to the device once it loads, so we treat the click as the visitor’s consent rather than as an exception. That took the count of sites that need a banner from five to four.

Fixes that have nothing to do with a banner

On 23 October the template previews on themes.dev still loaded a font stylesheet from fonts.googleapis.com and a script library from cdnjs.cloudflare.com. Neither set a cookie, but every visitor’s IP address went to Google and Cloudflare before they chose anything. We saw that as a GDPR question rather than a reason for a banner. Since a redesign on 24 October the site shows screenshots instead of live previews, so those requests are gone.

Four sites still have no privacy page: getwork.dev, themes.dev, theuiindex.com and dev.cards. No banner doesn’t mean no information. The Dutch Data Protection Authority says you still have to tell visitors about limited analytics, and the GDPR asks for a privacy notice whenever you handle personal data such as IP addresses.

A second check found a bug

On 31 October we added a random sample of pages from the price-comparison sites: 183 pages across the 27 sites. In the HTML of 6 of them, on 3 sites, a product image pointed at another company’s server. The images load as a visitor scrolls to them. The products on a homepage change over time and our first round looked at few other pages, so it missed this.

On gamecrew.nl and toolrango.com it’s a shop’s own photo on the homepage, from www.nedgame.nl and www.toolmax.nl. Our own image hosts normally serve these. A request like that shows the shop the visitor’s IP address, and toolmax.nl also sets a bot-protection cookie with the image.

On boardgamedrop.com, 4 of the 7 sampled pages point at an affiliate network’s click-tracking link, because one shop’s feed wraps its photos in that link. We changed the import on 22 October, but rows already stored only change at that feed’s next import, and these were still there. The link’s host didn’t resolve when we looked it up, so the request fails and the card stays empty.

We count this as a bug rather than a reason for a banner. The fix is to serve every photo from our own image hosts, and until that’s done this one stays open.

The script we didn’t add: Cloudflare Web Analytics

When we compared our list with what the pages loaded, one script turned up that wasn’t in any of our code: static.cloudflareinsights.com/beacon.min.js. It’s Cloudflare Web Analytics, which Cloudflare adds to pages as they pass through its network. On 19 October it was on for 22 of our domains, gatelamp.com among them.

Cloudflare’s documentation explains it: “Free customers have RUM enabled automatically, with EU traffic excluded, and can switch it off if they prefer.” RUM, real user monitoring, is the part of Web Analytics that runs in the browser. Our account shows the same thing: 36 of our domains got a Web Analytics site within three seconds of going live on Cloudflare.

With EU traffic excluded, Cloudflare doesn’t add the script for visitors from the EU. Its documentation decides that by the data center a visitor connects to, and the list also covers the UK, Switzerland and Norway. We work from the Netherlands, so the script never showed up on our own screens. Visitors from the rest of the world got it.

On 10 of the 22 domains it never ran anyway. The price-comparison platform only allows scripts from the site itself, so browsers refused Cloudflare’s script and logged an error. On the other 12 it ran: on 10 for visitors outside Europe, and on frankspin.com and themes.dev for every visitor. Those two are much older domains, and we may have switched that on ourselves years ago.

Going by Cloudflare’s documentation, the script itself is mild. It stores nothing in the browser and reads no cookies or storage. It collects performance data, such as load times and the page address, and sends it to Cloudflare, which says it discards the IP address at the data center.

It was still a script from another company that sent data about visits, on sites whose privacy pages didn’t mention it, doing a job our Umami already did. In the EDPB’s reading of the ePrivacy rule, a script that tells the browser to send information can fall under it even without cookies. Whether this one needs consent was a question we didn’t have to answer, because we didn’t need it. On 19 October we switched it off on all 22 domains, and on 31 October none of the 41 Web Analytics sites in our account was switched on.

To check your own domains, look at Web Analytics in the Cloudflare dashboard or ask the API. If you’re in Europe, loading your own site won’t show you the script.

What we took away

Most of what we found came down to choices made long before anyone thought about a banner.

• Most of our sites need no banner for what their pages load, because of tools we picked: analytics without cookies that we host ourselves, fonts on our own domain, videos that wait for a click.
• The code isn’t the whole page. A host or a CDN can add scripts on the way out, so check what the browser receives, and from more than one country.
• No banner still means work: a privacy page, an honest list of what each site uses, and checking again, because pages can change without anyone touching the code.
• Some questions need a lawyer. Nearly all our price-comparison sites also serve Germany, where the law has no separate exception for analytics (TDDDG §25), and the answer on affiliate links changes per country.