Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Things not available when someone blocks all cookies

blog.tomayac.com

Post reply on HN
Print view View original

151–160 of 231 posts

Re: Things not available when someone blocks all cookies

#151

Post by NovemberWhiskey »

javajosh wrote: post #141
orev wrote: post #36

Earlier quoted context omitted.

“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.

I think of cookies as a mechanism to send data across the network. That mechanism can be used to simulate persistence on the client, among other things. 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 think of cookies as a mechanism to send data across the network. That mechanism can be used to simulate persistence on the client, among other things.

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.

Re: Things not available when someone blocks all cookies

#152

Post by oliwary »

mcv wrote: post #41

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.

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.

Re: Things not available when someone blocks all cookies

#153

Post by hedora »

bagacrap wrote: post #113
hedora wrote: post #91

Earlier quoted context omitted.

The big ad companies definitely have not been good stewards. 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…

"won't somebody think of the drug addicts" is a novel (to me) argument for why all ads are bad

In this case, the drug addicts are people with medical conditions that have been intentionally pushed to abuse their medication by the pharmaceutical company and Google, etc.

The argument is closer to "encouraging and profiting from illegal drug abuse is not 'responsible corporate stewardship'".

Re: Things not available when someone blocks all cookies

#154

Post by javajosh »

NovemberWhiskey wrote: post #151
javajosh wrote: post #141

Earlier quoted context omitted.

I think of cookies as a mechanism to send data across the network. That mechanism can be used to simulate persistence on the client, among other things. 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 think of cookies as a mechanism to send data across the network. That mechanism can be used to simulate persistence on the client, among other things. 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.

Cookies are a way for clients (and servers) to add data to HTTP requests. It's a header, plus the expectation that the client will add this data to subsequent requests sent within a certain timeframe.

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.

Re: Things not available when someone blocks all cookies

#155

Post by SilasX »

Spivak wrote: post #80
moffkalast wrote: post #20

Earlier quoted context omitted.

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.

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."

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-init...

Re: Things not available when someone blocks all cookies

#156

Post by cpeterso »

Spivak wrote: post #80
moffkalast wrote: post #20

Earlier quoted context omitted.

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.

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."

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.

Re: Things not available when someone blocks all cookies

#157

Post by discardedrefuse »

npteljes wrote: post #49
mcv wrote: post #41

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 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...

I do this too! I pair Temporary Containers with the Containerise add-on which lets me create persistent containers for a few specific sites that I want stay logged in to.

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.

Re: Things not available when someone blocks all cookies

#158

Post by pedrovhb »

SquareWheel wrote: post #149
pornel wrote: post #144

Earlier quoted context omitted.

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.

>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.

Re: Things not available when someone blocks all cookies

#159

Post by diroussel »

guenthert wrote: post #136
pseudosavant wrote: post #126

Earlier quoted context omitted.

I have written a web app that does this so you can share links which have the same state. You can't have that long of URLs actually - especially for some browsers. Having to base64 encode most/all of it so you can safely use any kind of data makes it even worse. My use case was very basic and I quickly hit limits that made it so I couldn't "persist" all of the data I wanted.

Er, you'd store the data in your DB of course and only a comparatively small, encrypted index to it in the URL. You wouldn't trust the client to "persist" the data anyhow.

The question was about storing state in the URL. You are referring to storing a session I’d in the URL. Quite different.

Re: Things not available when someone blocks all cookies

#160

Post by WaitWaitWha »

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).

Post reply on HN