--- title: Cookie jarring date: 2026-02-24T11:59:05Z modified: 2026-03-06T08:50:54Z permalink: "https://dgw.ltd/2026/02/24/cookie-jarring/" type: post status: publish excerpt: "" wpid: 735 categories: - AI - Code featured_image: "https://dgw.ltd/wp-content/uploads/2026/02/cookie.png" featured_image_alt: Cookie and a important icon --- Cookie banners have been around for a long time and Cookies even longer. But why? First the obligatory bit about, no not those type of Cookies… _Cookies are small text files that a website saves onto your device, used to remember information about you or your visit – like that you’re logged in, what’s in your basket, or to track your behaviour across the web._ Now before any regulation existed, websites were dropping trackers onto your device silently and without your knowledge. This is bad. ## The law **EU Cookie Law — ePrivacy Directive (2002, amended 2009)** The EU’s rules stem from the ePrivacy Directive, which is implemented differently across each member state. The core principle is that non-essential cookies require prior informed consent before being set. **UK Cookie Law — PECR (Privacy and Electronic Communications Regulations)** The UK retained the ePrivacy Directive’s rules into domestic law as PECR, enforced by the ICO. Since Brexit, the UK has diverged slightly in tone and guidance – the ICO has signalled a more pragmatic, outcomes-focused approach rather than rigid technical compliance. However, the substantive requirements are currently very similar to the EU rules. ## What this actually means for real-world UX TL;DR cookie laws govern the **banner/consent experience** you encounter when visiting a website – not data protection broadly (that’s GDPR’s job), but specifically the act of dropping cookies or similar trackers onto a user’s device. **What it means in practice:** Websites cannot set non-essential cookies – analytics, advertising, personalisation, social media trackers – until the user actively says yes. “Non-essential” means anything that isn’t strictly necessary to make the website function (e.g. a shopping cart session cookie is essential; a Google Analytics tracker is not). This is why we have those annoying consent banners everywhere. Annoying, but important. Legally, those banners must make it as easy to **decline** as it is to **accept**. A banner with a big green “Accept All” button and a buried “Manage Preferences” link designed to frustrate rejection is non-compliant – this is known as a dark pattern, and regulators have fined companies for it. This should be done at the browser level imho, but I digress. Until the user gives consent, non-essential cookies **must not fire**. A compliant site should load clean, show the banner, and only start tracking after an explicit “yes.” If the user declines or simply closes the banner without consenting, the site should remember that preference without using a tracking cookie to do so (a strictly necessary preference cookie is allowed for this purpose). **The honest reality:** The vast majority of cookie banners on the internet are non-compliant in some way – either through dark patterns, pre-ticked boxes, or firing cookies before consent is given. Enforcement has been patchy, though EU regulators are getting tougher. **The “unknown cookies” issue** is particularly glaring. A Consent Management Platform (CMP) like OneTrust or Cookiebot can only block cookies it knows about. If a third-party script (say, an embedded widget, a CDN, or a loaded ad network) drops its own cookies that weren’t declared in the cookie audit, the CMP has no way to intercept them. Those audits are also typically done at setup and then go stale – websites change, scripts get updated, new trackers creep in. The consent banner says “here are your choices” but it’s essentially a snapshot of what the developer or colleague declared at one point in time and quite possibly now long gone. A company that can demonstrate a CMP was configured in good faith, cookies were audited periodically, and consent logs were kept is in a very different position to one that has a banner purely for show with everything firing regardless. The former is demonstrating accountability even if the technical implementation is imperfect. **The paper trail reality** is very much baked into how this is enforced in practice. Regulators largely assess: - Did you have a banner? - Did it offer a meaningful choice on its face? - Did you document consent? - Did you make reasonable efforts to categorise and block? **The deeper structural problem** is that the law was written around a user-interaction model (click yes/no) but the technical ecosystem it’s trying to govern – sprawling third-party scripts, tag managers, pixels, server-side tracking – is far more complex and opaque than any banner UI can meaningfully surface. The gap between legal intent and technical reality is probably wider in cookie compliance than in almost any other area of web regulation. ## Can we make our own one? I’ve implemented many cookie banners over the years, so had always been interested in trying to build one myself, but what would be involved? Given the need to demonstrate compliance, obviously going with a CMP makes a lot of sense. The process you have to go through – auditing, categorisation, user-facing text, and publishing – is the paper trail. But it comes at a cost. Much of this blog has turned into little experiments in building out proof-of-concept, AI assisted utilities which previously wouldn’t have been possible given the scale of the task. So I decided to give it a try. There are excellent design patterns for Cookie Banners, accessible and compliant, naturally for anyone following this blog it’s GOV.uk design system [Cookie Banner](https://design-system.service.gov.uk/components/cookie-banner/) component As mentioned above the reality is there are actually two parts to an effective Cookie Banner functionality. The scanner and the banner. Many of these are bundled into the CMP, but for our purposes I decided to separate them out. A node based scanner and a standalone WordPress plugin for the banner that consumes a JSON file provided via the scanner. The scanner primarily uses [Playwright](https://playwright.dev), a testing CLI. This allows us to use it to scan external websites for cookies, the tool then returns a JSON file: ```json { "name": "elfsight_viewed_recently", "domain": "core.service.elfsight.com", "path": "/", "expires": 1770045239.139848, "httpOnly": true, "secure": true, "sameSite": "None" } ``` Once we have this, we need to categorise it. Again importantly this needs to be done manually. This is the tricky part and where the commercial options have a big advantage, they maintain a database of cookies and suggest categories, analytics, advertising, personalisation and so on. We can try and build our own, but that’s a big process. I’ve put something in there as a proof of concept, but as with many of these builds there is a reason turnkey SaaS businesses still have the edge, they have been able to fulfil one aspect of a process that is just too much to take on and maintain for the rest of us. There are [open source options](https://github.com/jkwakman/Open-Cookie-Database) which I am evaluating. We also need to document consent so need to record the user’s consent (timestamp, preferences, anonymised IP hash, consent version) for full compliance, but also be GDPR compliant and not identifiable. Which means we need to add a table to our database, which I rarely like to do due to the technical debt, but compliance requires it. With all that done, we had a cookies-categorized.json which we can pop into the plugin. ```json { "name": "elfsight_viewed_recently", "domain": "core.service.elfsight.com", "provider": "Elfsight", "category": "functional", "purpose": "Remembers recently viewed items for Elfsight widgets", "necessary": false, "expiry": "1 year", "data_location": "EU", "transfer_mechanism": null } ``` Once we have this, the banner part was relatively easy. A settings page completed the requirement for users to be able to change their preferences. We can add this link to our footer so it’s easily accessible for users in the future. As per usual, my ‘oh I’ll just build a cookie banner and a JSON file’ fell somewhat short of the considerations – privacy, security and compliance – we need to consider very carefully and thoroughly. But that’s partly why running these experiments is so useful. By understanding the full journey we can see the gaps that can be optimised. For work that demands compliance, SaaS models have a real advantage. They’re expensive and often frustrating, but they give you something to point to – a documented process, an audit trail, a defensible answer when someone asks _how did you handle this?_ A vibe-coded solution rarely offers that. If the AI does everything, it might not be your problem – but it is your responsibility. Oh and why no cookie banner on this site? This is because I use a privacy-friendly analytics service called [plausible.io](https://plausible.io) so I didn’t even really need to build this in the first place.