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?
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".
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.
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.
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.
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.
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.
> 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.
WRT GPC, yes. We treat GPC as a "essential only" choice, and don't show you a banner. We treat DNT (Do Not Track) the same way, but its legal standing seems a lot less clear, especially due to the hijinks Microsoft did.
And GPC is not experimental: if you don't respect it, you're in violation of California's CCPA/CPRA law [1]. It's likely that other states will fall in line here as well.
I think we have different use cases: I'm trying to help people get compliant && do the right thing. From my perspective "anything that can trigger an uncomfortable conversation with an auditor" is not experimental. And I can tell you from the analytics that a significant portion of the web browsers out there are using it.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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/
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.
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.
>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.
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. *
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.)
With some nastiness, you could make every link on the page a form submission and submit the session ID with the form. Then render it into the HTML that’s returned in response.
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.
The only difference between your “DOM cookie” technique and a browser cookie is that it sounds like you’ve (re)invented a session cookie that only works with single-page apps. Either way it boils down to an opaque session ID token which is stored on the client and sent to the server with every request. You could do the same expiry/crosschecking/validation on the server either way; it makes no difference for security how the client stored it.
Frankly, this entire codebase is full of code smells that are hallmarks of Dunning-Kruger security (I should know, I was like that myself once!) and the fact that you haven’t learned anything in the 3 years since it was written is alarming.
> 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. *
By your logic, you're just to lazy to do this better than me and it's just easier to throw banners at everyone?
Yes, it’s a design choice, in that you have chosen to design something worse for the sake of feeling industrious.
There is no need to show a consent banner for authentication cookies (these are considered “Strictly necessary cookies... essential for you to browse the website and use its features, such as accessing secure areas of the site”). On the flip side the directive on tracking consent covers any method of tracking, it doesn’t let you go “nyah nyah, I didn’t use a ‘cookie,’ I made my own and called it something else!” so if you think you would need a banner for a cookie, you will need a banner no matter how you do 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?
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".
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.
The fix would be to use a per-domain cookie, and don't expire it in just a few days.
Aren't 3rd party cookies blocked by default in Chrome? Obviously not.
Must be positioning themselves for a Microsoft acquisition!
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.
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.
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.
> 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.
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.
> 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.
WRT GPC, yes. We treat GPC as a "essential only" choice, and don't show you a banner. We treat DNT (Do Not Track) the same way, but its legal standing seems a lot less clear, especially due to the hijinks Microsoft did.
And GPC is not experimental: if you don't respect it, you're in violation of California's CCPA/CPRA law [1]. It's likely that other states will fall in line here as well.
[1] https://oag.ca.gov/privacy/ccpa/gpc
It's experimental according to https://developer.mozilla.org/docs/Web/HTTP/Reference/Header... and according to your own link, its availability is very limited.
In any case, it's not widely respected in my testing, regardless of California law.
I think we have different use cases: I'm trying to help people get compliant && do the right thing. From my perspective "anything that can trigger an uncomfortable conversation with an auditor" is not experimental. And I can tell you from the analytics that a significant portion of the web browsers out there are using it.
You don’t need a banner for login cookies.
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.
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.
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.
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.
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.
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?
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.
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.
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.
Yes it’s evil.
I believe you can still do telemetry even, it just has to be anonymised.
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.
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.
Great clarification, thank you.
And basically all EU government websites?
I see at least two evil things trying to load on that page.
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.
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/
That website is not authoritative and should not be given more credence than your median tech blog.
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.
But... your site doesn't use cookies and doesn't process personal data. Why do you think you're in breach of GDPR?
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.
>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.
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...
They are just called "cookie banners".
The storage mechanism is not important.
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.)
[1] https://www.php.net/manual/en/session.idpassing.php
PHP doesn't have to use a cookie to maintain session.
Check my other comment for an explanation.
Session information is usually stored in a cookie. It is not better to use a session URI parameter.
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.
But how are you storing the session token in the browser?
In a hidden DOM on the page. Updated asynchronously.
There is Javascript running on the page that updates the DOM.
So as long as the user is on the page, the "session" stays alive.
A session by definition extends beyond one page.
With some nastiness, you could make every link on the page a form submission and submit the session ID with the form. Then render it into the HTML that’s returned in response.
A rose by any other name would smell as sweet.
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.
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.
The only difference between your “DOM cookie” technique and a browser cookie is that it sounds like you’ve (re)invented a session cookie that only works with single-page apps. Either way it boils down to an opaque session ID token which is stored on the client and sent to the server with every request. You could do the same expiry/crosschecking/validation on the server either way; it makes no difference for security how the client stored it.
Frankly, this entire codebase is full of code smells that are hallmarks of Dunning-Kruger security (I should know, I was like that myself once!) and the fact that you haven’t learned anything in the 3 years since it was written is alarming.
So my original comment was accurate then?
> 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. *
By your logic, you're just to lazy to do this better than me and it's just easier to throw banners at everyone?
Yes, it’s a design choice, in that you have chosen to design something worse for the sake of feeling industrious.
There is no need to show a consent banner for authentication cookies (these are considered “Strictly necessary cookies... essential for you to browse the website and use its features, such as accessing secure areas of the site”). On the flip side the directive on tracking consent covers any method of tracking, it doesn’t let you go “nyah nyah, I didn’t use a ‘cookie,’ I made my own and called it something else!” so if you think you would need a banner for a cookie, you will need a banner no matter how you do it.
I edited it about 10s after posting it.