This site uses cookies to store the fact you clicked “Accept Cookies”
rodyne.com
rodyne.com
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.
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".
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.
Actually, if you're managing cookies, you've already lost.
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.
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.
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.
In any case, it's not widely respected in my testing, regardless of California law.
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.
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.
Thus, preemptive cookie banners are only needed for the "this is an evil website" case.
And basically all EU government websites?
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.
This is true for all laws, all scams, all ads.
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/
* https://github.com/zelon88/HRCloud3/blob/master/core.php#L54...
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.
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.
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.
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.
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?
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.
Check my other comment for an explanation.
The storage mechanism is not important.