I totally understand your point and I think I agree, except—well, the setting says “disable cookies”. It should do what it says. If the goal is to disable all persistent information, the setting should be called “disable persistent storage”.
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.
They could call it "disable cookies and other persistent storage (more information)" with more information providing their reasoning why they are bundled in plain English. There is no reason the setting has to have a two word name with no description.
From what I saw, that was indeed one of the more common complaints about Windows 8. Nobody could find printers and thought Windows 8 didn't support printers because Windows 8 merged everything to just "Devices" (and the short-lived Devices "charm" as an intended one-stop print shop/"universal Print button", RIP). It didn't help that Windows 8 tried to at the same time update the ancient Windows Printer driver model and remove some of the worst habits of Printer driver vendors (background apps that are always running, bespoke updaters, weird unregulated UI extensions to Win32 common dialogs via backdoor hacks, etc) so there was some Manufacturer-encouraged hysteria that Windows was moving too much cheese on Printers and coming to take people's beloved Printers away (which did result in Microsoft killing that nicer printer driver stack initiative of Windows 8 and its user-focused experience).
Many of Microsoft's early successes seemed predicated on listening to user and developer feedback.
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.
> 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.
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.
Microsoft seems to have a crapload of competing teams with each fiefdom vying for attention and authority over decisions, whereas Apple, at least from an outsider perspective, more looks like an authoritarian, top-down corporate hellscape. Another very important distinction that explains this is that Apple doesn't give much about backwards compatibility, whereas it was a core part of Microsoft to keep backwards compatibility even at very high cost.
Both methods of corporate behavior have their advantages and disadvantages.
I'd guess it's more likely that there used to be a "Printers" control panel, when the main thing it controlled was the DB-25 parallel printer port on an ancient IBM-compatible PC, and later they added other devices to it. People accustomed to adjusting printer settings might scroll straight to "Printers" and be confused if it got renamed to "Devices." Even more nefariously, it's reasonable that there's some software out there that does a string comparison for "Printers" that ignores extra characters like " and Devices" which would be a reason not to rename it completely.
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.
“Cookies” is shorthand for “persistent storage” because nobody outside of web developers knows other methods exist. When people, laws, banners, etc. refer to cookies, they mean “any technology that stores information on the client side systems”.
Whatever mechanism is used is irrelevant to the meaning/concept.
Or we could just recognize that for the general population, "cookies" are any client storage by a website, and for technical people, cookies are a subset of options for client storage by a website.
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.
> 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.
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.
Right, if anything, we should campaign for the technical definition of "Cookies" to encompass everything as well and just call the old thing legacy HTTP cookies or whatever when you need to be specific.
As a non-web developer, I remember years ago when disabling cookies meant only cookies -- then learning that there were other forms of persistent storage. It made me angry and I felt betrayed.
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.
I disagree, but not in the technical sense. People have been talking about cookies since they were invented, so most people who’ve used a web browser know the word and have a vague sense that they’re used to store information on their computer, and are often used for tracking.
The fact is that “cookies” now has a colloquial meaning that’s different from the technical definition, and both meanings are valid.
Well, there is the distinction between cookies getting sent over the network vs localStorage being (obviously) local. but of course, a website can work around this by manually sending localStorage data in requests, so it makes sense that if people want privacy, you block both. Sucks though.
I think of cookies as a mechanism to send data across the network. That mechanism can be used to simulate persistence on the client, among other things.
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 think of cookies as a mechanism to send data across the network. That mechanism can be used to simulate persistence on the client, among other things.
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.
Cookies are a way for clients (and servers) to add data to HTTP requests. It's a header, plus the expectation that the client will add this data to subsequent requests sent within a certain timeframe.
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.
"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."
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.
And I'd be inclined to blame the state of the web in general.
[ ] Cookies - stored locally and sent to web-sites automatically
[ ] Local Storage - not automatically sent to web-sites
In all cases I veer towards sharing explicit details. If users choose to not understand it fully that is fine. I don't like 'dumbing-down' or simplifying taking away explicit details with no easy way to get it in the same place as the 'simple' exposition.
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.