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.
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/
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.
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.)
Readit News
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".
Deleted Comment
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.
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.
It's a nightmare for anyone who uses private windows.
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.
Actually, if you're managing cookies, you've already lost.
Using a cookie to store user session for login is the use of an essential cookie and doesnt necessitate the popup on its own.
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.
* 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.
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?
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.
Deleted Comment
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.
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.
And basically all EU government websites?
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/
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.
* https://github.com/zelon88/HRCloud3/blob/master/core.php#L54...
The storage mechanism is not important.
[1] https://www.php.net/manual/en/session.idpassing.php
Check my other comment for an explanation.
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.
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.