3 ms·

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

by ris58h 4y ago

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.

pornel 4y ago
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.
- jefftk 4y ago
  > 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=diff https://bugzilla.mozilla.org/attachment.cgi?id=234539&action... from https://bugzilla.mozilla.org/show_bug.cgi?id=341524 https://bugzilla.mozilla.org/show_bug.cgi?id=341524
- SquareWheel 4y ago
  >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.
  - pedrovhb 4y ago
    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.
    - SquareWheel 4y ago
      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.
  - JohnFen 4y ago
    They have different primary purposes, but they can both be used to engage in tracking and other privacy-destroying behavior.
kccqzy 4y ago
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.

by ris58h 4y ago

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.

pornel 4y ago

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.

jefftk 4y ago
> 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=diff https://bugzilla.mozilla.org/attachment.cgi?id=234539&action... from https://bugzilla.mozilla.org/show_bug.cgi?id=341524 https://bugzilla.mozilla.org/show_bug.cgi?id=341524
SquareWheel 4y ago
>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.
- pedrovhb 4y ago
  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.
  - SquareWheel 4y ago
    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.
- JohnFen 4y ago
  They have different primary purposes, but they can both be used to engage in tracking and other privacy-destroying behavior.

kccqzy 4y ago

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.