Live data from Hacker News

Things not available when someone blocks all cookies

blog.tomayac.com

141–150 of 231 posts

Re: Things not available when someone blocks all cookies

#141
post #36

Earlier quoted context omitted.

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 tog…

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

Re: Things not available when someone blocks all cookies

#142

Earlier quoted context omitted.

Just the opposite. What this would normalize is app developers no longer be able to depend on location data being accurate, which would destroy the location data sales market by turning it into a market for lemons. 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…

Oh no, not the location data sales market.

Not sure what your point is or what your interpretation of my comment was. So just to clarify, I think the location data sales market is a bad thing and that is why I advocate a solution that would destroy that market and give us back location privacy. It has zero benefit to users and a lot of scary downside.

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

Re: Things not available when someone blocks all cookies

#143

Earlier quoted context omitted.

> The only browser feature we leverage are click events 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 goi…

I'm sorry if this hurts your beliefs, but in what way are aggregated and anonymized data exploitative? Every "offline" store does it. How do you expect businesses to make profits if they can't look at what drives their revenue without bothering every single customer with consent requests?

Data claimed to by anonymized usually can be easily deanonymized.

Re: Things not available when someone blocks all cookies

#144
post #140
post #17

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

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.

Re: Things not available when someone blocks all cookies

#145
post #17

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

Re: Things not available when someone blocks all cookies

#146

Earlier quoted context omitted.

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 tog…

They could call it "disable cookies and other persistent storage (more information)" with more information providing their reasoning why they are bundled in plain English. There is no reason the setting has to have a two word name with no description.

Dumbing down user interfaces has always been the trend on the internet.

Re: Things not available when someone blocks all cookies

#147
post #48

Earlier quoted context omitted.

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 tog…

How about — 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. And I'd be inclined to blame the state of the web in general.

I'd be tempted to nuance that:

  [ ] Cookies - stored locally and sent to web-sites automatically
  [ ] Local Storage - not automatically sent to web-sites
In all cases I veer towards sharing explicit details. If users choose to not understand it fully that is fine. I don't like 'dumbing-down' or simplifying taking away explicit details with no easy way to get it in the same place as the 'simple' exposition.

Re: Things not available when someone blocks all cookies

#148
post #144
post #140

Earlier quoted context omitted.

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.

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.

> 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

Re: Things not available when someone blocks all cookies

#149
post #144
post #140

Earlier quoted context omitted.

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.

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.

Re: Things not available when someone blocks all cookies

#150
post #52

Earlier quoted context omitted.

They could call it "disable cookies and other persistent storage (more information)" with more information providing their reasoning why they are bundled in plain English. There is no reason the setting has to have a two word name with no description.

Just like Windows Control Panel has "Printers and Devices" - because I guess people don't think of printers as devices?

From what I saw, that was indeed one of the more common complaints about Windows 8. Nobody could find printers and thought Windows 8 didn't support printers because Windows 8 merged everything to just "Devices" (and the short-lived Devices "charm" as an intended one-stop print shop/"universal Print button", RIP). It didn't help that Windows 8 tried to at the same time update the ancient Windows Printer driver model and remove some of the worst habits of Printer driver vendors (background apps that are always running, bespoke updaters, weird unregulated UI extensions to Win32 common dialogs via backdoor hacks, etc) so there was some Manufacturer-encouraged hysteria that Windows was moving too much cheese on Printers and coming to take people's beloved Printers away (which did result in Microsoft killing that nicer printer driver stack initiative of Windows 8 and its user-focused experience).
Post reply on HN