back
221 comments
I naively assumed from the headline that the author would complain about users blocking cookies. I was very pleasantly surprised to see a post written by someone who appreciates that some users will want to do this and is actively working to support delivering them a useful content experience!
I assumed the same thing and was indeed happy when it turned out to be the better thing.
As someone working on a ticketing purchase flow, this is critical... can't exactly just turn people away! I was also surprised about localstorage throwing exceptions.
I often think that instead of completely blocking cookies, it would be better to accept them and then throw them away. Same with localStorage. Just store it temporarily.
I’ve been using Cookie AutoDelete for that purpose for the last few years. It works flawlessly for me and brings me comfort in knowing that I am only being tracked online by my browser fingerprint and IP.

https://addons.mozilla.org/en-US/firefox/addon/cookie-autode...

I do this with Firefox's Temporary Containers. Every manually opened tab is a new browsing session, with no cookies etc. Closed tabs' data get deleted after 15 mins. Fantastic addon, and the usage is as seamless as it gets.

https://addons.mozilla.org/en-US/firefox/addon/temporary-con...

Well, I've reacted to the article with an "of course, the Google's browser breaks everything if you try to block tracking".

There is absolutely no reason for letting the javascript know that you've blocked some functionality. It just adds new tracking.

Anyway, the sensible thing to do is to store the values for the lifetime of the page. Simply throwing them away can be an option, but it's a bad default. Non ad based browsers do get it.

This is the answer. Blocking the APIs is just asking for a broken internet, and I have very little sympathy.

Furthermore, blocking the API is a detectable characteristic and increases the surface area of your fingerprint. It has exactly the opposite of the intended effect on privacy.

That's basically incognito/private browsing mode.
"Delete cookies and site data when Firefox is closed"
Maybe. I run a word game (https://squareword.org) that uses localstorage to store stats. This allows me to give users statistics without requiring any sort of account or signup. Even so, I often hear from people that have their stats cleared, for example by iOS evicting localstorage after 7 days of not visiting a site.
I pick between the two. Of late that responsibility has been pretty well taken care of by the Forget Me Not extension on Firefox, although I think it's endangered (like a lot of things that have to do with Firefox and its extensions.)

You can set rules with three clicks, four clicks if you want that rule to be temporary and thrown away on browser restart. You may choose between never deleting, deleting on browser close, deleting on tab close, or just throwing them away. The initial setup for default policy has a few UI issues, but the author put a lot of work into it.

https://addons.mozilla.org/en-US/firefox/addon/forget_me_not...

Check out Forget Me Not - https://addons.mozilla.org/en-US/firefox/addon/forget_me_not...
I agree. Private browsing takes care of this for me. I close the tab, cookies are deleted, and I will randomly confirm this occurs occasionally just to be certain. There's no need to get all OCD or self-righteous about cookies when Javascript is the scourge. I can not respect any that block cookies but do not surf with Javascript disabled. Though html5 has nearly but not quite made Javascript irrelevant, the scourge seems to now be built in to html.
Agreed - Firefox have very legit, useable workflows for avoiding tracking while still having the web function for you. Chrome has IMO a purposefully unusable approach. It’s theatre, they give you the option, but that option breaks the web so badly that you’re not going to want to use it. Which makes sense, they’re an ad sales company, tracking is crucial to their business.
This is how I use Firefox, things only stored for the session, for the given container. Containers are better than first-party isolation, because many sites expect to share data with third-parties.

It is also better to fake API responses than to block access to them. In Firefox the privacy.resistFingerprinting option takes care of this. It was originally developed for the Tor Browser.

Unfortunately doesn't signal the rejection of tracking by things like fingerprinting.
What if browsers made it so when you turned off cookies, instead of not allowing anything to be written, they instead gave each page you visited its own fresh cookie jar that was cleared when you navigated away?
> 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.

I always use a wrapper around local/session storage[1] to avoid this problem. Then you have your app sync settings with storage, never read from it except during startup.

It becomes impossible to implement basic UI features like remembering open panes, etc when storage is disabled though. With the current policies around cookies - no cross-domain reads, Safari's ITP - there is no real need to turn them off for privacy reasons, for the average user at least.

[1] https://www.npmjs.com/package/localstory

"(On a tangent, MDN is completely broken with cookies blocked, too. I was about to report this problem (because I care and love MDN), when I discovered a PR is already under way that fixes the Issue. Thanks, @bershanskiy!)"

This would imply that "MDN" is under a state of rapid flux, potentially "breaking" and then being "fixed" (or not) over short periods of time. However it appears from the edit history that most of it is actually static and has not changed since 2019 or 2020.^1

Perhaps the "completely broken" catchphrase invoked by the author refers to an issue with "cosmetics" (window dressing) not content. I use a text-only browser and have not found MDN to be either partially or completely "broken". I send an HTTP request for a file and I receive the contents of the file. For me, it works. No cookies or Javascript required.

1. https://raw.githubusercontent.com/mdn/content/main/files/en-...

If I want to check browser compatibility, which can change from time to time, I can use Github or the MDN website.

For example,

https://raw.githubusercontent.com/mdn/browser-compat-data/ma...

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cl...

I created an extension that limits the maximum lifetime of cookies, I was surprised to see some have a lifetime of years. https://addons.mozilla.org/en-GB/firefox/addon/fresh-cookies...
Why does the browser pretend to have localstorage but then throw an exception when it's used?

Surely it would be better to simply pretend to not support localstorage and then all sites built with feature detection would work correctly without needing to special case this?

The Atlantic is really annoying in this respect. When you open an article in Firefox Focus, it fully renders for a moment, but then apparently some javascript loads at the end of the cycle which clears the page.
Yeah, adding try/catch around those has been a good practice for a while. I think there was a time when, if the site was running in a private window in Safari, localStorage would also throw exceptions.
I handle cookies on my proxy where I change them to per session cookies and interestingly the sites that have cookies that are "necessary for sites to work", are working flawlessly (/s)
> All I am using is some innocent localStorage and IndexedDB to persist user settings

Hrm, isn't this the exact definition of a cookie?

God bless this man for making this -- but you know what's CRAZY to me? That no one has done this before.

We all visit websites constantly and governments (particularly in EU) talk endlessly and vaguely about cookies and yet almost NO ONE really gets it. I work on this specific problem and it is SUCH a mess.

An interesting facet of this is the implicit trust by the author towards the downstream tooling and libraries. He is not alone.

We talk about how we need to make sure dependencies are secure, but I venture to state, it is often just brushed over. Yes, supply chain security (now to rinse my mouth out).

Weird to throw an exception when localStorage is not available. It is much more logical to have it undefined or null. Code working with localStorage is more likely to check whether it is available (“not falsey”) rather than trying to use it and fall back if it throws.
One thing that annoys me about firefox's total cookie protection is that I offer some 3rd party embeds. What I did on those is I set a cookie, and probed for its existance to check if the user has third party cookies disabled. Then if they do, it displays things for the case where it's not known whether or not the user is logged in to the service, rather than as if they're definitely not logged in.

This worked fine, but now that firefox just containerizes third party resources rather than actually blocking the cookies, so there's no longer a way to detect that the actual site cookies just aren't being delivered in a third party context, rather than not present without user agent sniffing.

instead of blocking cookies, it would be nice if there was something like "Certified Humane" for websites... and you could stick within an internet of websites created by people who are not dicks.
I think the problem here is "potentially blocked".

How do you know what's potentially blocked? Maybe it's listed clearly somewhere in the browser docs, or maybe it's not. Did they change it between versions? Did you even know about this issue in the first place?

I know people like to think of checked exceptions as a failed experiment from the dark past of object oriented programming, but this situation is a great example of statically-typed (or at least statically-checkable) side effects are a huge improvement in code safety.

This feels kinda unscalable though...

wouldn't it make more sense to change the browser to make cookies and localstorage non-persistent and isolated, but otherwise available programmatically and to XHRs.

i.e so that they can exist in isolation as long as the tab is open. This would be compatible with anything that doesn't require cross frame or cross tab persistence (which is usually all users care about).

Looking forward to the day some webmaster sets the background to pictures of cookies when you block them all.
Why is the website failing with unhandled errors, but working when they are try/catch'd? Either way the errors are being thrown, and the functionality isn't available. Is the browser not able to handle the situation itself more gracefully?
Someone knows if this happens only in Chrome or also in the rest of popular browsers?
Fun fact: the code example with the glow effect was created with [Carbon](https://carbon.now.sh/)
I wonder if instead of blocking cookies we could make a browser extension to share the tracking cookies (and only those) with random people on the web, to confuse trackers?
Not directly related to this article but doesn't aggressively blocking tracking in this way create a tracking monopoly for browsers, extensions and apps?
Why throw an exception instead of providing real working versions of these things that only persist data for as long as the page is open?
I recently read a thread about privacy here. One point was that the one best thing you can do is disable JavaScript. So I decided to try it. I installed Brave on my phone and disabled pretty much everything, including all cookies.

My thinking was, all I do is browse HN, hn.algolia, and lobsters. Those should work, right? Well lobsters works perfectly, including collapsing comments.

HN loses the ability to collapse comments. But algolia is the worst. Not only does it require JS, being an SPA, but it refuses to work until you enable cookies! My theory is that it reads the settings (popular, 24-hour) from a cookie, and plain dies if they're not there.

On another note, and to a pleasant surprise, a lot of the web works perfectly fine, and feels a lot snappier, including even google search. And many of the annoying cookie and paywall popups never appear, since they appear to be implemented in JS.

So yes, if you haven't tried it, I recommend you do. You can always whitelist sites you trust or really need to use.

I always accept all cookies because they have never had any negative impact on my surfing experience ever. Cookie banners and Privacy banners are much more of a problem than cookies ever were.
Is there a way to use csrf tokens without cookies?
How about, you know, handling error conditions?
I just want to take this opportunity to thank "adtech" and everyone working in it for making local storage way more complex than it otherwise needed to be because you couldn't/can't stop yourselves from abusing users.
Just don't use Chrome if it's user hostile. Use something else that's not.