8 ms·

> All I am using is some innocent localStorage and IndexedDB to persist user settings like the values of the sliders or the chosen color scheme. When you turn

by jefftk 4y ago

> All I am using is some innocent localStorage and IndexedDB to persist user settings like the values of the sliders or the chosen color scheme. 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.

moffkalast 4y ago
Thing is though, it can be worked around as long as js is enabled. Client side fingerprinting plus server side data storage and you get the same functionality in a roundabout way.
- 0x0 4y ago
  So you get to share preferences with everyone else that matches your fingerprint :)
  - moffkalast 4y ago
    That's the punishment for blocking local storage. :P
    - smoldesu 4y ago
      s/punishment/reward
  - treeman79 4y ago
    /s Even better we could store login information this way. What could go wrong?
- jefftk 4y ago
  You don't even need JS: blocking cookies doesn't (but really should) disable the browser cache, which can reasonably reliably store information. 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.
- Spivak 4y ago
  I would actually love to see a demo of this used for comedic effect. "Unlogin, use your browser fingerprint as your password. We already, know who you are, why put up with the hassle of typing a password."
  - SilasX 4y ago
    I actually wrote up an April Fool’s parody based on that premise, modeled after Google’s NoCaptcha announcement. http://blog.tyrannyofthemouse.com/2021/04/leaked-google-initiative-no-more.html http://blog.tyrannyofthemouse.com/2021/04/leaked-google-init...
  - cpeterso 4y ago
    Some websites already do something similar: if you are logging in from an "unrecognized" (unfingerprinted) browser, they might force you to 2FA authenticate and then give you have the option to "trust this browser" for future logins. You might still need to log in with your password, but not 2FA. Of course, that fingerprint can break when your browser auto-updates to a new version.
Wowfunhappy 4y ago
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. • The modern web in general.
- orev 4y ago
  “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.
  - kevingadd 4y ago
    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.
  - MetaWhirledPeas 4y ago
    > “Cookies” is shorthand for “persistent storage” because nobody outside of web developers knows other methods exist Most people don't know what "cookies" means either. We shouldn't make the problem worse by giving them false information.
    - 4y ago
hnbad 4y ago
I'd argue that being able to write to and read from storage for the lifetime of the session (i.e. until you close the tab) is not "persistence" in the sense that any privacy-conscious user cares about. 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.
- jefftk 4y ago
  > It's not at all surprising that Google's browser would choose ... 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 https://bugzilla.mozilla.org/show_bug.cgi?id=341524
- mr_toad 4y ago
  > I'd argue that being able to write to and read from storage for the lifetime of the session The web API doesn’t cater to that. If you only need storage to persist for the session you can just use memory.
MereInterest 4y ago
Especially with single-page applications, I would love for there to be a way for a page to have either access to persistent store or network connections, but not both. A site could load all resources, then announce to the browser that it would like to have access to whatever it stored the previous time. The browser would grant access to the local information, and simultaneously take away access from ever initiating a network connection again. A newly loaded copy of the page would start in the same state, able to pull in new resources, but unable to read or write local information until it again gives up the right to exfiltrate. 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.
- deleted 4y ago
  [deleted]
legitster 4y ago
Came here to say this. If anything, a cookie that is not cross-domain is more innocent than localStorage.
- jefftk 4y ago
  What would make it "more innocent"?
  - gkbrk 4y ago
    Perhaps the comment was about HttpOnly which cannot be read by random ad / tracking scripts on the page. It is still storing data, but now the server needs to actively transmit it to other parties.
  - legitster 4y ago
    A cookie is a tiny plaintext file limited at 4kb. Your browser keeps an inventory of them, lets you read or delete them, and automatically clears them out regularly. 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.
    - potatoz2 4y ago
      Looks like local storage has a max size of 5MB and cookies 180 * 4KB = 0.7MB, so a similar order of magnitude. AFAIK, cookies can be set to expire in hundreds of years by sites and local storage can be cleared the same way as cookies.
      - legitster 4y ago
        I mean, you can make a cookie that is anything you want, but browsers accept what they accept. For Chrome that's a <4kb cookie with a max-expiration of 400 days. 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.
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.
hombre_fatal 4y ago
I don’t think so, else we should change the name. Cookies are sent to the server on every request so it has tracking implications that locally caching something like dark mode preferences does not. One issue is that there’s a hysteria over cookies which muddies the water.
- potatoz2 4y ago
  It’s trivial to emulate cookies with other Web APIs (storage + service worker, for one). You’re focusing on the label of the toggle and not user intent. If a website can send information about my visit 2 days ago to an upstream server, clearly my expectation of “Disable cookies” is broken.
  - hombre_fatal 4y ago
    Then it should be called disable client persistence or something more clear, imo. Cookies is already a ridiculous jargon word esp for the general public.
    - maxerickson 4y ago
      Firefox calls it "Cookies and site data". Seems clear and to the point.
deleted 4y ago
[deleted]

by jefftk 4y ago

moffkalast 4y ago

Thing is though, it can be worked around as long as js is enabled. Client side fingerprinting plus server side data storage and you get the same functionality in a roundabout way.

0x0 4y ago
So you get to share preferences with everyone else that matches your fingerprint :)
- moffkalast 4y ago
  That's the punishment for blocking local storage. :P
  - smoldesu 4y ago
    s/punishment/reward
- treeman79 4y ago
  /s Even better we could store login information this way. What could go wrong?
jefftk 4y ago
You don't even need JS: blocking cookies doesn't (but really should) disable the browser cache, which can reasonably reliably store information. 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.
Spivak 4y ago
I would actually love to see a demo of this used for comedic effect. "Unlogin, use your browser fingerprint as your password. We already, know who you are, why put up with the hassle of typing a password."
- SilasX 4y ago
  I actually wrote up an April Fool’s parody based on that premise, modeled after Google’s NoCaptcha announcement. http://blog.tyrannyofthemouse.com/2021/04/leaked-google-initiative-no-more.html http://blog.tyrannyofthemouse.com/2021/04/leaked-google-init...
- cpeterso 4y ago
  Some websites already do something similar: if you are logging in from an "unrecognized" (unfingerprinted) browser, they might force you to 2FA authenticate and then give you have the option to "trust this browser" for future logins. You might still need to log in with your password, but not 2FA. Of course, that fingerprint can break when your browser auto-updates to a new version.

Wowfunhappy 4y ago

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. • The modern web in general.

orev 4y ago
“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.
- kevingadd 4y ago
  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.
- MetaWhirledPeas 4y ago
  > “Cookies” is shorthand for “persistent storage” because nobody outside of web developers knows other methods exist Most people don't know what "cookies" means either. We shouldn't make the problem worse by giving them false information.
  - 4y ago

hnbad 4y ago

I'd argue that being able to write to and read from storage for the lifetime of the session (i.e. until you close the tab) is not "persistence" in the sense that any privacy-conscious user cares about. 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.

jefftk 4y ago
> It's not at all surprising that Google's browser would choose ... 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 https://bugzilla.mozilla.org/show_bug.cgi?id=341524
mr_toad 4y ago
> I'd argue that being able to write to and read from storage for the lifetime of the session The web API doesn’t cater to that. If you only need storage to persist for the session you can just use memory.

MereInterest 4y ago

Especially with single-page applications, I would love for there to be a way for a page to have either access to persistent store or network connections, but not both. A site could load all resources, then announce to the browser that it would like to have access to whatever it stored the previous time. The browser would grant access to the local information, and simultaneously take away access from ever initiating a network connection again. A newly loaded copy of the page would start in the same state, able to pull in new resources, but unable to read or write local information until it again gives up the right to exfiltrate. 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.

deleted 4y ago
[deleted]

legitster 4y ago

Came here to say this. If anything, a cookie that is not cross-domain is more innocent than localStorage.

jefftk 4y ago
What would make it "more innocent"?
- gkbrk 4y ago
  Perhaps the comment was about HttpOnly which cannot be read by random ad / tracking scripts on the page. It is still storing data, but now the server needs to actively transmit it to other parties.
- legitster 4y ago
  A cookie is a tiny plaintext file limited at 4kb. Your browser keeps an inventory of them, lets you read or delete them, and automatically clears them out regularly. 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.
  - potatoz2 4y ago
    Looks like local storage has a max size of 5MB and cookies 180 * 4KB = 0.7MB, so a similar order of magnitude. AFAIK, cookies can be set to expire in hundreds of years by sites and local storage can be cleared the same way as cookies.
    - legitster 4y ago
      I mean, you can make a cookie that is anything you want, but browsers accept what they accept. For Chrome that's a <4kb cookie with a max-expiration of 400 days. 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.

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.

hombre_fatal 4y ago

I don’t think so, else we should change the name. Cookies are sent to the server on every request so it has tracking implications that locally caching something like dark mode preferences does not. One issue is that there’s a hysteria over cookies which muddies the water.

potatoz2 4y ago
It’s trivial to emulate cookies with other Web APIs (storage + service worker, for one). You’re focusing on the label of the toggle and not user intent. If a website can send information about my visit 2 days ago to an upstream server, clearly my expectation of “Disable cookies” is broken.
- hombre_fatal 4y ago
  Then it should be called disable client persistence or something more clear, imo. Cookies is already a ridiculous jargon word esp for the general public.
  - maxerickson 4y ago
    Firefox calls it "Cookies and site data". Seems clear and to the point.

deleted 4y ago

[deleted]