I disagree.
For example, a simple todo-list web-app doesn't need any cookies but stores everything in localStorage.
Cookies are made for a server, localStorage for a client.
What happens when the web app decides to send the server the entire contents of the localStorage every time it loads? Now we are back to emulating cookies with localStorage.
For regular users "Cookies" is a catch-all term for any persistent identifiers and tracking. The exact API used to persist cookie-equivalent data shouldn't matter. Excluding some tracking methods based on a technicality is a gotcha that erodes users' trust.
I think the real issue here is that Google chose to throw errors instead of turning those APIs into no-ops.
> 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.
>For regular users "Cookies" is a catch-all term for any persistent identifiers and tracking.
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.
I agree it's a misnomer and it's confusing for developers to find that disabling cookies breaks local storage, but I think it's understandable. When a user disables cookies their intent is presumably for the website to not be able to track their device, and it's quite easy to work around this with local storage (just add a locally stored identifier to each request made).
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.
I can appreciate the argument, but it still bothers me. Don't you think there's an argument to be made for educating the user, rather than reinforcing their misunderstanding?
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.
