This site uses cookies to store the fact you clicked “Accept Cookies”
59 comments
·April 10, 2025avemg
int_19h
It's because they are using a third-party (cookielaw.org) cookie to record the your choice. So if your browser is configured to not allow third-party cookies - e.g. Safari's "prevent third party tracking" and similar options in other browsers, or PiHole and AdGuard - this breaks them.
And yes, it's a known issue going back several years. The official response is "it affects less than 1% of our users, so fuck you".
LegionMammal978
How would they even be able to fix it, short of redirecting all their domains to stackexchange.com subdomains (and causing a colossal branding mess and making everyone mad)? Almost by definition, anything that would allow them to know you've accepted cookies on a different domain would be a form of tracking that all the anti-tracking stuff would clamp down on.
int_19h
The fix would be to use a per-domain cookie, and don't expire it in just a few days.
kristianp
Aren't 3rd party cookies blocked by default in Chrome? Obviously not.
cedws
Must be positioning themselves for a Microsoft acquisition!
null
learningmore
Yes! I’ve even considered finding some extension to just accept every cookie option for every site, so just I’m not hammered with consent dialogs on StackOverflow.
I use multiple browsers for testing, across multiple computers.
Perhaps this fact, along with their consent expiration policy causes the consent dialogs to always show.
ghusto
Please put in the bare minimum effort to understand. If you had, you'd know that you either _do not need a cookie banner_, or that you do because your site is collecting identifiable information on persons using cookies. If you do not care about the latter, then please start caring.
bradleyy
As someone who has helped build one of those cookie banners, I will admit that using cookies to store the state of what you consented to is somewhat ironic, or at least meta.
It's got some really interesting parts though: serving those banners, geolocated (show the right thing for the legal regime you're in) at actual "web scale lol". And while folks hate them, we respect the GPC signal, and then won't show you the banner, just opt you out of everything.
lapcat
> using cookies to store the state of what you consented to is somewhat ironic, or at least meta.
It's a nightmare for anyone who uses private windows.
bradleyy
The alternative would be something like "making you log in to save cookie preferences". There are legitimate reasons to do this, but most would oppose it. Would you provide some market feedback?
Would you rather log in to preserve your settings? Can you think of any other way to (semi-)anonymously identify you and preserve your settings across different sessions?
Note: this is actually a problem I'm thinking about, and really do want to find a workable solution.
lapcat
> Would you rather log in to preserve your settings? Can you think of any other way to (semi-)anonymously identify you and preserve your settings across different sessions?
The fundamental problem is that 99% of sites with cookie banners don't need cookie banners, because they don't need cookies at all. They say (lie) that it's to "improve your experience", but it's really just for tracking purposes.
If a site has a login, then of course they need some kind of storage, and they can present the cookie consent in the login form. Otherwise, though, it's an imposition with no benefit to the site visitor.
When you say "we respect the GPC signal", do you mean the Sec-GPC header? That would be a bit of improvement if all sites had to respect the header, but at this point it's still experimental and not widely used or respected.
bradleyy
It may not have been clear: I work for a SAAS company that sells a "cookie banner", or more properly, consent management; it's quite a bit more complex than just managing cookies.
Actually, if you're managing cookies, you've already lost.
cosmotic
One thing many dont understand about GDPR is that consent for cookies is only needed if its a nonessentual cookie, or in other words one used for ad tracking or analytics.
Using a cookie to store user session for login is the use of an essential cookie and doesnt necessitate the popup on its own.
JohnTHaller
Yeah, but that login cookie is tied to a session within our database. And since we can count those sessions and see when they were last accessed, now we have stats based on those sessions which are based on those cookies. And we can analyze those stats and glean some useful data - analyzed statistics, we'll call them analytics for short - so we have analytics based on the statistics from the sessions attached to the cookies. So, we better show a cookie banner just to be safe.
johnea
I don't agree at all with the "wild west" and "buyer beware" stuff in the article.
But I do completely agree that it's annoying, when I surf to a website with cookies disabled, and am forced to click "Yes I accept cookies", even though my browser isn't going to accept them. and that after I click OK, the site displays anyway.
I did read an article that came through the HN feed about how many person/hours of productivity were lost each year to this process in general. It wasn't a small amount.
o11c
Remember, according to the GDPR:
* any strictly necessary cookies do not require consent
* any preference/functionality cookies require consent, but the user has to go looking for them anyway
Thus, preemptive cookie banners are only needed for the "this is an evil website" case.
Kerrick
Evil, really?
Is a simple A/B test where you want to see whether using the phrase “sign up” or “register” on the landing page is more effective evil? Even if you have no desire to track individuals and you just want to know which phrase is more helpful in aggregate? Storing the data necessary to learn this requires consent, doesn’t it?
selfhoster11
IMO, yes. You are storing data you don't need to store, and adding a (small) fingerprint to the user's persistent profile with your site - so don't store it. Losing the ability to run A/B tests is not a big deal.
marcosdumay
It requires consent if it's personal information.
You can pretty much do an A/B framework that doesn't require consent. You will absolutely be prohibited from running any of the popular options we have today.
ghusto
Yes. Do it without personal information. If your intent is only to A/B test, you don't need to tie that to individuals, unless your intent is also to target those particular types of individuals.
null
loloquwowndueo
Yes it’s evil.
bn-l
I believe you can still do telemetry even, it just has to be anonymised.
jdlshore
You’re confusing the GDPR and the ePrivacy directive. (And maybe getting that wrong too. I’ve read the GDPR but not the ePrivacy directive. Oh, and IANAL.)
The GDPR doesn’t require consent for cookies. What it requires is a lawful basis for tracking people’s personal information. Most of those lawful bases don’t require consent either.
The only time the GDPR requires consent is when somebody wants to collect your personal information and they don’t have a good reason to do so. Then they have to ask, they have to make it easy for you to decline, and they have to make it easy for you to withdraw your consent later. They also can’t withhold anything from you if you decline. They can’t charge more for their services, block it from your access, etc.
That’s what the GDPR has to say about consent. Nothing to do with those cookie banners, which are the result of scummy companies doing scummy things.
lmkg
GP are wrong about which law applies, but they are applying that law correctly.
The ePrivacy Directive requires consent to read or write from the user's terminal device, except when strictly required for the functionality the user requested. Unlike GDPR, it does not allow a different Legal Basis. It must be consent, or strictly functionally necessary. Nothing else.
The passage of GDPR did impact the ePrivacy Directive in that it updated the definition of "consent." The ePD doesn't have one; it referenced the definition in the DPD, which was replaced by GDPR. This is why people blame the GDPR for cookie banners, although really it's incidental.
jdlshore
Great clarification, thank you.
aurareturn
Thus, preemptive cookie banners are only needed for the "this is an evil website" case.
And basically all EU government websites?
o11c
I see at least two evil things trying to load on that page.
boznz
This short post came about because I got an email yesterday which managed to traverse my spam filters saying my web site does not adhere to the GDPR regulations and (of course) offering to help fix it. Yes I know I shouldn't have opened it. (Lesson learnt, Spam filter added!) Anyway apologies in advance for said budget-driven, non-gdpr-compliant, web-site, and probably falling over at the slightest sign of stress.
karpour
Just because your site uses cookies does not mean you need a consent banner to be GDPR compliant
Unless you're tracking people or sharing visitor data with third party services, you're likely not doing anything that requires consent. See here: https://gdpr.eu/cookies/
lmkg
That website is not authoritative and should not be given more credence than your median tech blog.
usr1106
And not more credence than TFA. GDPR has legally very little to do with cookie banners as other comments have already pointed out. I am pretty sure nobody has been ever improsened because of not asking consent for storing cookies. Even for hefty fines you first need a hefty turnover, so that site seems unaffected. And obviously a couple of 100 millions are not hefty for Meta, Google & Co. They make bigger profits by taking the risks of not being in compliance.
rozab
But... your site doesn't use cookies and doesn't process personal data. Why do you think you're in breach of GDPR?
boznz
The post is supposed to be a bit tongue-in-cheek (and is tagged so), the fact being I am a New Zealand company who does have any known customers or affiliates in the EU but I also have no idea what WordPress or its plugins do in the background if you say enter your email for an RSS or comment feed.
I think lots of non-EU and non-technical bloggers would likely see the email I had (which was just opportunistic marketing spam from a European company and not nefarious) and think they were in breach of something like you say they are probably not.
1116574
>I think lots of non-EU and non-technical bloggers would likely see the email I had and think they were in breach of something like you say they are probably not.
This is true for all laws, all scams, all ads.
zelon88
Cookies are entirely a design choice, and a lazy one at that. It is entirely possible to identify, authenticate, maintain session, and store data about a user on the server completely without cookies. *
* https://github.com/zelon88/HRCloud3/blob/master/core.php#L54...
Garlef
They are just called "cookie banners".
The storage mechanism is not important.
wolfgang42
Could you explain how, rather than linking to the middle of a large chunk of code? Fundamentally you need to have some way to associate the data on the server to a particular client, and cookies (or something like them) is the way HTTP does that. In particular, your link appears to be using PHP’s $_SESSION, which... uses a cookie.[1] (Or a URL parameter, but that’s usually a much worse idea than cookies, especially for something that’s handling logins.)
zelon88
PHP doesn't have to use a cookie to maintain session.
Check my other comment for an explanation.
milesrout
Session information is usually stored in a cookie. It is not better to use a session URI parameter.
zelon88
In the proof of concept I linked, a self expiring session token is given to the client.
If it is returned before the expiry, a new token is generated and the process starts over.
If it is not returned before its expiry the session is considered to have been closed.
null
SirensOfTitan
But how are you storing the session token in the browser?
zelon88
I see you edited your original comment rather than replying to mine.
The URI parameter must be accompanied by the session token and encrypted login credentials as well via POST.
So unless you steal the username, hashed password, tokens, and URI parameter before the expiry of the token then you aren't hijacking a user session.
zelon88
Basically the web app builds a fingerprinting cookie with a super short lifespan in the page as a hidden DOM. On a set schedule, or with every request, the credentials that are baked into this "DOM cookie" are rotated. When the user stops sending requests the session is closed.
Let's say the cookie expiry is 10 seconds, or until the user clicks a button on the page.
Any MITM attack is going to have to intercept the HTML over clear text http in order to steal the DOM cookie. That attack would also work on a regular cookie. But with my design the attacker only has 10 seconds to deconstruct that cookie and use it to steal the session. With a regular cookie they have a lot more time.
The only other way to hijack the session would be local malware or browser extension, which would also work on a regular cookie.
milesrout
I edited it about 10s after posting it.
I am going to use this opportunity to ask: Why is that stackoverflow sites absolutely, positively cannot seem to remember my cookie preferences and seemingly ask me every single time I find myself there?