When you turn off cookies you're telling the browser not to let sites persist information. Otherwise, whatever goals you had in disabling cookies would just be worked around through these other technologies.
Of course, I also know why it’s not called that: a lot of people know what cookies are at this point, at least relative to the number who'd understand “persistent storage”. A toggle named “disable cookies” is better for usability.
On the other hand, trying to guess what the user actually wants based on a different preference is virtually guaranteed to cause confusion of its own. Should the setting also disable Canvas, since that’s commonly used for fingerprinting? And will Google make the same decision in Chrome v104 as they do in Chrome v110?
I can’t decide whether the primary issue is:
• The name of the setting.
• The undeserved cultural prominence we’ve given “cookies” specifically.
• The modern web in general.
It is simple to believe that they've taken that as a strong core principle of the company. The over-reliance on deep telemetry metrics, for instance, seems kind of a natural evolution of a company that cherishes as much feedback as it can get.
It seems reasonable to think that the immensely negative feedback on Windows 8 or the sad market response to Windows Phone sparked so many shifts in priority precisely in the way that any heavily feedback-focused (even slightly neurodivergent) person might over-react to negative feedback and try to do everything "not that" to make up for it, even if those were good ideas and the negative feedback was more concerned about execution of them rather than the ideas themselves.
I've been accused of "fanboying" Microsoft at times because I like pointing out the good parts of ideas that Microsoft has had over the years (like how the Charms bar was a good idea poorly executed) not to blow smoke up Microsoft but to remind them, as a feedback oriented company, of ways they've over-reacted to negative feedback, to wonder where they would be if they didn't just kill such good ideas at the first sign of disinterest/complaint but instead gave them room to grow/evolve. Sometimes it sounds like they need a lot more positive feedback to be a better company because all they seem to hear is the hate of some of the noisier crowds.
Telemetry is almost the opposite of user feedback as it completely disregards the human element of the user. You may be able to tell what is used often, where users drop out but you don't know why and you don't know what is important to you users. So what telemetry ends being used for more often than not is to back up the developer's own preferences by seemingly backing them up with data without actually doing so.
Both methods of corporate behavior have their advantages and disadvantages.
Similarly here, cookies have been around since Netscape in 1994. IndexedDB is as new as 2015, window.LocalStorage is from ~2010 IIRC. For backwards compatibility, it's totally reasonable to use "Cookies" or "Cookies and local storage", and expect that to extend to any new developments.
Whatever mechanism is used is irrelevant to the meaning/concept.
Most people don't know what "cookies" means either. We shouldn't make the problem worse by giving them false information.
The public never needs to know the technical distinction because it is both
1) Arbitrary: "cookie" could just as well have been a general term for client storage, and
2) Insignificant: Virtually nothing the public is concerned about hinges on specifically how client data is stored, except for lawyers trying to get around cookie laws or to deceive through the text and UI of cookie consent pop-ups.
> We shouldn't make the problem worse by giving them false information.
So what I'm saying is that it's not a problem. It's very easy and accurate enough to tell users that they have to allow cookies in order to use some webpages offline. They can make all of the informed political decisions and personal decisions they need to make. I'd be happy to even further complicate the situation by referring to localstorage as the type of cookie that you'd need to make a lot of pages work offline.
edit: I mean, you can save your cookie in localstorage. For me, that makes it a superset, and the name "local storage" makes it clear that it's storing things where you are. If the public weren't calling all client storage cookies, I'd recommend that they start calling all client storage localstorage.
IMO, your exception is what makes the distinction significant. Defining a cookie two different ways gives companies a powerful new tool for purposefully misleading and manipulating end users.
Yes, many users are already confused. But if we actually make it acceptable to define cookies more broadly (but only when it's convenient for those in power), we're going to make the situation much worse.
Calling all persistent storage "cookies" matches the popular understanding of what "cookie" means. I don't see the problem with accepting that and using the term accordingly.
It may not be technically correct, but this is a point where the technical distinction isn't important. If a user disables cookies, what the user is expecting is that persistent storage won't happen at all.
Renaming it to disabling "persistent storage" would be fine, too, except that it would be necessary to explain what "persistent storage" means.
The fact is that “cookies” now has a colloquial meaning that’s different from the technical definition, and both meanings are valid.
But at least some of this conversation revolves around what the public perception of cookies is, and as for that, I really don't know. I wouldn't presume that anyone else knows either unless they've conducted a poll.
I can't get with that definition. A server that attempts to set a cookie is very explicitly asking for state persistence on the client in the otherwise stateless HTTP protocol exchange. It literally has no other purpose.
Consider that a similar effect can be achieved by adding an id to every link in the body of a response. But its still just a link. In fact, before cookies this is how you associated requests with each other into a "session". And indeed, this is still a way to do user tracking across domains without cookies and in a way that is impossible to block in general.
What a thing is used for is not the thing itself.
That's the definition of "client-side state". Cookies have no purpose other than maintenance of client-side state.
https://www.rfc-editor.org/rfc/rfc6265
"This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol."
"Cache" is also “persistent storage” to me.
Block all cookies (not recommended)
- Sites can't use cookies to improve your browsing experience, for example, to keep you signed in or to remember items in your shopping cart
- Sites can't use your cookies to see your browsing activity across different sites, for example, to personalize ads
- Features on many sites may not work
That seems long enough that they could put in text about how this is storage in general and not just cookies.
Firefox just has "Cookies: All cookies (will cause websites to break)" so there's not really a place for that sort of text.
Allow websites to store data on your computer
[ ] short-term
[ ] long-term or permanently
Some websites need to store data for some features, or to work it all. Storing data can also enable them to track you.
[ ] Cookies - stored locally and sent to web-sites automatically
[ ] Local Storage - not automatically sent to web-sites
Local storage (or Cache API, IndexedDB) + Service Worker = Cookies (simply add a header to every request)
Local storage + DOM manipulation to add search params with the stored content = Cookies (apart from first navigation)
And on the flip side
Cookies set using JS + Ignore cookies server side = Local storage
It’s almost like the object/closure equivalence.
It would be a one-way street that way. The page can take any network information with it into the private cave, but nothing from the cave may ever come out, nor may it even know if the cave is empty before taking that irreversible step.
I think the real issue here is that Google chose to throw errors instead of turning those APIs into no-ops.
This behavior pre-dates Chrome. I get "Uncaught DOMException: The operation is insecure" in Firefox today, and if I'm reading the patch correctly [1] this dates to when it gained localStorage support in 2006. Quickly looking I can't find when this was added to WebKit, though.
[1] "return NS_ERROR_DOM_SECURITY_ERR;" https://bugzilla.mozilla.org/attachment.cgi?id=234539&action... from https://bugzilla.mozilla.org/show_bug.cgi?id=341524
Geez I hope that's not true. Cookies and localStorage serve a very different purpose. localStorage is exactly what it says: local storage. Cookies are sent to the server with every request and are quite wasteful in comparison.
I would expect my browser to be accurate of its labeling in the user settings.
At the end of the day it's about either surprising the user or developers, and the user wins out (as they should, imo). One could also argue that developers will eventually find out that the functionality they implemented is broken, while a user who thinks they're not being tracked may never realize they really are, just more sneakily and on a technicality.
localStorage is just one of many ways to track users. You could also store data in indexedDB, the new File API, installed service workers, or even the browser cache if you're clever enough.
If we start lumping all forms of tracking (storage) under "cookies", that's going to get real messy, real fast.
One issue is that there’s a hysteria over cookies which muddies the water.
Seems clear and to the point.
Client side fingerprinting plus server side data storage and you get the same functionality in a roundabout way.
Note that you can't use the cache to work around browsers blocking third-party cookies because all the major browsers fragment the cache by site.
Of course, that fingerprint can break when your browser auto-updates to a new version.
http://blog.tyrannyofthemouse.com/2021/04/leaked-google-init...
If anything, making these features break loudly enables sites to detect that they can't be used for persistence and allows them to find ways to circumvent that. Contrast this with cookies which are silently discarded if the server sends them anyway.
It's not at all surprising that Google's browser would chose a way to loudly break these features in a way that a) allows sites to detect that they're unavailable and b) discourages users from using this setting.
This reminds me of when third-party Android releases would add a way to fake sensor data (e.g. GPS) when denying permissions to apps so the apps wouldn't be able to lock out users unwilling to agree to those permissions. A feature that of course Google would never add to stock Android as it is important for their business model that apps can trust their tracking data to be genuine.
This is how all browsers have handled it, for as long as localStorage has existed. See, for example, this Firefox discussion from 2006: https://bugzilla.mozilla.org/show_bug.cgi?id=341524
The web API doesn’t cater to that. If you only need storage to persist for the session you can just use memory.
Local storage can contain just about any type of user data without letting users know, and theoretically forever.
If you have to store local data, and you cared about "innocence" (author's word), it seems to me a cookie set to the local domain leaves less room for shenanigans. Hence why Google probably disables it when you disable cookies as well.
I think localStorage being slightly better or worse than a local cookie is up for discussion. I just think you're weird if you think local cookies are bad but localStorage is good.