What a Cookie Banner That Only Says 'Ok' Actually Tells You

A cookie banner with one button is not a UI shortcut. It’s a tell — the same tell, usually, as a privacy policy nobody has opened since it was pasted in.

I found both on the same public site this week: a children’s-media property with real traffic. The banner reads “We use cookies to make sure you get the best experience. If you keep using this site, we assume you’re happy about it,” under two buttons — Ok and Privacy policy. No reject. No per-category choice.

And buried in section 9 of that linked privacy policy, a retention clause that ends: “for as long as necessary for the service requested […] and in any case not beyond 31/12/2019.”

That date is not a typo you can round away. It’s six years past. And it’s the same failure as the banner, just in a different field.

The policy names its own controller plainly enough — section 4 identifies the company behind the site and a contact address, which is itself one of the few things Article 13 requires and this document gets right.

What “Ok”-only actually breaks

Consent under GDPR has to be freely given, specific, informed, and unambiguous — Article 4(11), tightened further by the EDPB’s 2020 guidance, which explicitly rules out “keep browsing = consent.” A banner with a single affirmative button and no equally easy way to decline doesn’t clear that bar; it clears the bar for notice, not consent. Those are different legal categories, and a lot of sites still build the first and ship it as the second.

The site in question runs Google Analytics — declared in its own policy — which means non-essential, profiling-adjacent cookies are live from the moment the page paints, before any button is clicked. The banner doesn’t gate anything; it just informs you, after the fact, that it already happened.

The policy itself confirms there’s no built-in reject path — section 7, “Refusal to provide data,” puts the burden entirely on the visitor: “To do so, [the user] must disable [cookies] following the instructions provided by the browser in use.”

No opt-out lives on the site. The visitor has to already know how to turn off cookies at the browser level — exactly the friction the EDPB guidance rules out when acceptance is one click.

This is a solved problem on the implementation side. A compliant banner needs three things a one-button banner skips: an accept action, a reject action of equal visual weight, and a way to grant or withhold consent per cookie category (essential vs. analytics vs. marketing) before any non-essential script fires. None of that is exotic — it’s the default output of any maintained consent-management library. Skipping it isn’t a cost-saving shortcut; it’s usually a sign nobody revisited the integration after the first deploy.

The retention date is the same bug, older

Article 5(1)(e) — storage limitation — requires that personal data be kept “no longer than is necessary for the purposes for which [it is] processed,” and that the retention period actually be stated (Article 13). A retention clause that names a fixed calendar date, rather than a duration tied to the actual purpose, was always a strange way to comply with either. Once that date is in the past, it stops being strange and starts being one of two things: the site has been processing data — names, emails, phone numbers, browsing data, cookies — for six years past its own declared cutoff, or nobody has opened this document since whatever CMS template shipped it. The policy itself hints at the second: the same section title appears duplicated three times in a row, the kind of artifact you get from copying boilerplate without proofreading the result.

Neither reading is a technical nitpick. A privacy policy with a retention date that’s already expired fails the transparency requirement on its face — a user reading it today cannot actually know how long their data is kept, because the document is telling them a date that has already passed.

The policy also contradicts itself

There’s a third data point, and it’s the cleanest one: the policy’s own recipients section states “no data from the web service (navigation data and cookies as specified above) is communicated or disclosed” — with an exception only for judicial or police authorities.

A few sections later, in the cookie disclosure itself, the same document states the site runs Google Analytics and that navigation data, IP address included, “will be transmitted to, and stored on, Google’s servers in the United States.”

Those two sentences can’t both be true. This isn’t an interpretation of vague legal language — it’s the same document asserting “no data goes to third parties” and then naming the third party three pages later. It’s the kind of contradiction that shows up when a privacy policy is assembled from a template and never actually read against what the site does.

Who this is actually for

The site markets itself, and reads in practice, to children and the families watching alongside them — parents sharing a device, kids clicking through on their own. The policy’s own minors clause states: “Our website is aimed at a general audience and does not offer services directed at children.”

That’s a hard claim to square with the actual audience. It doesn’t change any of the three findings above, but it raises the stakes on all of them: a one-button consent flow and a data-transfer disclosure that contradicts itself are worse problems on a site parents are handing to their kids than on one aimed at adults who at least might read the fine print themselves.

Why this pairing is common, not rare

A one-button cookie banner and a stale retention clause tend to travel together for a boring reason: both are usually shipped once, at launch, by whoever set up the site, and then never revisited — because neither one breaks anything a developer would notice. The page still renders. Analytics still reports numbers. No exception gets thrown. The only signal that something’s wrong is a document nobody on the engineering side is reading, describing a consent flow nobody on the engineering side is testing.

That’s the actual lesson, past this one site: cookie consent and retention policy are not “legal’s problem” that happens to live in a text file next to the code. They’re configuration, with the same failure mode as any other configuration nobody owns — it’s correct on the day it’s written and silently wrong every day after.

The fix is not complicated

Add a reject button with the same visual weight as accept. Gate non-essential scripts behind the actual consent state, not behind page load. Replace the fixed retention date with a duration tied to purpose, and put a review date on the policy itself — a policy without an owner and a recheck cadence will always drift back to this state eventually, template or not.

None of that requires a legal team to design from scratch. It requires someone to treat the consent banner as a piece of the system that can be wrong, the same way an unauthenticated endpoint or an unindexed query can be wrong — and to check it with the same seriousness.