Things not available when someone blocks all cookies
blog.tomayac.com
blog.tomayac.com
Given that many cookie banners still (IMHO illegally, to be verified by courts) give the choices "accept tracking or fuck off" I guess you could. But it behoves you that you would assume it's a stupid idea. :)
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.
https://addons.mozilla.org/en-US/firefox/addon/temporary-con...
This setup works well with one glaring exception... Cloudflare and their stupid boats. Using temporary containers for everything has really shone a light on just how much of the web Cloudflare is gobbling up. Cloudflare throws a captcha at me every time I visit any website they gatekeep for. I'm talking mostly about random sites that turn up in web searches. Its annoying enough that when I encounter a Cloudflare captcha, I just close the tab and try the next site.
Now I'm wondering if there's a way to eliminate results from web searches that use Cloudflare with something like the uBlackList add-on.
https://addons.mozilla.org/en-US/firefox/addon/cookie-autode...
The cookie banners can be super annoying sometimes, but they are easily removed with uBlock Origin. I also frequently have to solve captchas, but it's not so bad. For example, every time I visit amazon.com to order toilet paper or whatever, it thinks I'm a bot, but at least amazon's captchas are less annoying than some of the others.
https://addons.mozilla.org/en-GB/firefox/addon/i-dont-care-a...
P. S. If I'm using a separate Firefox container just for Amazon, they would isolate my Amazon cookie right? So then I could just whitelist it and avoid capchas?
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.
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.
An editor warning you that your work hasn’t been saved?
Or a game warning you that your progress will be lost.
There must be tons of legit use cases.
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...
The solution to "software authors routinely collecting more info than they should" is not "accept the behavior as irredeemable, and just normalize it".
The answer is "make ot way more visible to users when it is done, snd make it harder for software authors to do/maintain." Anything else is just a tacit acknowledgement and grant of legitimacy to the behavior in question.
* use as in use for the intended business purposes, not harder to write the code
What you propose, simply yelling at developers to stop requesting unneeded permissions, would have no useful effect. They won't change. And most customers won't care and will blindly click accept no matter what if they think they have to to access their game.
Never let the perfect be the enemy of the good. Assume that other actors in the world will respond the way they usually do, not the way you think they should. That is the way to get things done.
(For those who are unaware, a lot of free apps pay for themselves by secretly recording location history and then selling it. This is why companies and even government agencies can buy mass location data when they want and query it to find out who was where when. This has been going on for years and is well known and documented and in no way secret. Just for anyone who missed it somehow.)
Besides which, I don't care if you feed me garbo GPS GLONASS if I've war driven and reverse indexed local wireless nodes to GIS coords. There's more than one way to get at coordinates, and enough hands in the jar in terms of being honest with location data by default that it'd be an uphill battle to fight teach users just how many ways a mobile handset can potentially leak location data.
The problem is that the data is retained at all. Until that data is considered toxic/a liability, there will be no respite from it.
Such a weird choice to put the onus on the websites to ask whether to give the cookies, rather than the browser to ask whether to save them. I'm a big supporter of privacy legislation like the GDPR, but this is asinine, as it needs me to trust every website I visit to actually honor my choice.
Really, the original sin of cookies is that were designed to be transparent to user. That was a mistake that promptly needs to be rectified.
[0] https://addons.mozilla.org/en-US/firefox/addon/temporary-con...
edit: remove redundant "together"
When you tell Multi-Account Containers to always open a domain in a specific container, Temporary Containers knows about this, but for some reason it prompts you for additional confirmation. And sometimes this prompt breaks sites the first time through, adding an additional iteration when trying to configure a container to work with a site that uses multiple domains. Other than that they work together fine.
I would also recommend the Cookie Quick Manager extension, which lets you manage cookies on a per-container basis. If you have been using Multi-Account Containers by it self, then any links you open from a page will open in the same container (say reading news sites from HN), and you likely have a bunch of cross-site cookies stored there. This extension will let you clear out any undesired third-party cookies that have gathered in the container. The UI is a bit unclear at first (which of these three trashcan icons scattered across the page delete the subset of cookies I want), so read the tooltips before clicking an icon.
It probably can't be every site being separate since that breaks a number of things sites do (like opening 3p windows to complete transactions), but it could probably be done in some kind of logical group manner. Maybe by using different window colors to signify the partitions.
If you set it as default browser then all links you click will be openend there. Hit the back button when you're done and everything is deleted.
Another use case is if you quickly want to open some website to look something up: open the website, maybe click a few links, and when you're done everything is wiped.
You can keep a regular Firefox (or Chrome or whatever) for surfing to those websites where you want to keep some state.
For privacy purposes, Incognito mode achieves the same effect without any of the hassle. Maybe turning off cookies should not even be an option anymore?
I do use Multi-Account Containers and Temporary Containers too, but typically when I want multiple simultaneous sessions, rather than wanting my current session to be cleaned up.
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.
Client side fingerprinting plus server side data storage and you get the same functionality in a roundabout way.
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.
http://blog.tyrannyofthemouse.com/2021/04/leaked-google-init...
Of course, that fingerprint can break when your browser auto-updates to a new version.
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.
Whatever mechanism is used is irrelevant to the meaning/concept.
Most people don't know what "cookies" means either. We shouldn't make the problem worse by giving them false information.
The fact is that “cookies” now has a colloquial meaning that’s different from the technical definition, and both meanings are valid.
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.
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.
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.
"Cache" is also “persistent storage” to me.
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 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.
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.
What a thing is used for is not the thing itself.
That's the definition of "client-side state". Cookies have no purpose other than maintenance of client-side state.
https://www.rfc-editor.org/rfc/rfc6265
"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."
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.
Both methods of corporate behavior have their advantages and disadvantages.
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.
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.
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.
[ ] Cookies - stored locally and sent to web-sites automatically
[ ] Local Storage - not automatically sent to web-sites
Local storage (or Cache API, IndexedDB) + Service Worker = Cookies (simply add a header to every request)
Local storage + DOM manipulation to add search params with the stored content = Cookies (apart from first navigation)
And on the flip side
Cookies set using JS + Ignore cookies server side = Local storage
It’s almost like the object/closure equivalence.
Block all cookies (not recommended)
- Sites can't use cookies to improve your browsing experience, for example, to keep you signed in or to remember items in your shopping cart
- Sites can't use your cookies to see your browsing activity across different sites, for example, to personalize ads
- Features on many sites may not work
That seems long enough that they could put in text about how this is storage in general and not just cookies.
Firefox just has "Cookies: All cookies (will cause websites to break)" so there's not really a place for that sort of text.
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.
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
The web API doesn’t cater to that. If you only need storage to persist for the session you can just use memory.
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.
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.
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.
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... from https://bugzilla.mozilla.org/show_bug.cgi?id=341524
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.
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.
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.
One issue is that there’s a hysteria over cookies which muddies the water.
Seems clear and to the point.
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.
"In the URL" works for that, sort of, though not if you want it to still work for users that are just re-finding you through Google or typing in your address.
That is a session.
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...
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?
Hrm, isn't this the exact definition of a cookie?
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.
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).
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.
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.
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).
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 don't work in front-end but whenever I've used localstorage for personal projects it's as simple as getting/setting a javascript object with keys & values.
Do you mean the fact that cookies and LocalStorage (or other APIs able to persist data) are often considered the same thing when using the term "cookies"?
Meanwhile we see just how effective targeted advertisement can be for both money and political influence.
That seems unfortunate. And futile anyway, because the truth is that society as a whole actually wants advertising, in all its forms. We may find individual ads annoying but we still make our purchase decisions based on those ads and use those channels to hawk our own wares.
[1] The truth is that the big ad-driven internet companies have been, on the whole, actually fairly good stewards of this stuff. People don't trust them out of principle (or, just as often, tribalism), but at least so far the dystopia hasn't arrived.
https://www.pewresearch.org/fact-tank/2019/11/15/key-takeawa...
There's no point in additional discourse on the issue. We may as well be arguing about whether cigarettes cure lung disease.
https://en.wikipedia.org/wiki/Cidade_Limpa
Even for cities that do not outright ban it, outdoor advertisement is heavily regulated in many parts of the world. Compare you typical european and asian big city street. Clearly many people do not like ads even without the tracking.
Here's an ongoing example that should get someone put in jail:
Pharmaceutical companies target ads for addictive drugs at the people that are most likely to become addicted to those drugs.
(For the victim of this that I know personally, it wasn't painkillers. As far as I know, there have been no repercussions for the manufacturer of the drug in question or the ad networks.)
See also: The millions of comments on any thread on HN that discusses SEO, dark patterns, cookie consent, or apps that interfere with advertising revenue streams.
The argument is closer to "encouraging and profiting from illegal drug abuse is not 'responsible corporate stewardship'".
I actually don't really mind ads as long as the volume of them isn't too great. But I greatly mind the tracking that comes along with them.
> at least so far the dystopia hasn't arrived
I disagree. From my point of view, we reached the dystopia stage quite a while ago.
> People want ads
Says who? Sounds like rationalization from someone who works in the industry. I could be wrong.
Though I appreciate your frustration, your aggression is a little off target. :)
Do the users want their click events fed into an advertising engine? Did you ask them? If you made this opt-in, how many would say, yes, please track my clicks in order to advertise to me? Even if its anonymized/aggregated.
A huge amount of advertising is enabled by tracking users against their will, exploiting the fact that many users aren't aware of what's going on, don't know how to stop it, or aren't as invested in their preference as the adtech companies are in their revenue. "A man is always right in his own eyes". If you're smart it's easy to justify this stuff to yourself because you're getting paid, but that doesn't make it right.
You are right in that a huge amount of ads leverage user data at the expense of the user.
The point I’m trying to make is that not all involved in the advertising technology are exploitive. We do zero ad targeting based on user data. You make a search for specific products, we take the response and shuffle the order a bit based on vendor campaigns. That’s it. Nothing is associated or even collected from the user. It’s all system metrics.
The greatest harm that my team does is hurting optimized relevancy, which is inherit to advertising but also something we work hard to alleviate.
That misused proverbs quote is a nice touch. Shows a lot of self awareness.
I don't doubt that you're being truthful here. The problem is that the vast majority of adtech is extremely exploitive, and there is no way for a user to tell the "good guys" from the "bad guys". So all adtech must be treated as hostile.
Ads by definition try to influence the user to do things they would not have don on their own. They cannot ever be user respecting.