5 ms·

> In some ways, this is a loss—tracking cookies are undeniably terrible, and Google's proposed alternative is better for privacy, at least on paper. However, un

> In some ways, this is a loss—tracking cookies are undeniably terrible, and Google's proposed alternative is better for privacy, at least on paper. However, universal adoption of the Privacy Sandbox could also give Google more power than it already has, and the supposed privacy advantages may never have fully materialized as Google continues to seek higher revenue. Cookies are much maligned these days, but to defend them a little bit - the alternatives are almost universally worse for user privacy. Persistent session storage? Browser fingerprinting? Locking everything behind a user account with mandatory sign-in? Blegh. On the other hand, cookies are a pretty transparent interaction. It's a tiny file that sites in your browser. You can look at them. They expire on their own. You as a user can delete, modity, edit, hack them to your heart's content. They contain no PII on their own. They are old-fashioned and limited and that's a good thing. The real problem here is not the cookie - it's the third party data networks. I would much rather focus our ire on the function rather than the form.

tmpz22 2y ago
Blaming privacy violations on cookies has been an absolute masterclass in public relations and is probably the greatest innovation of FANNG.
- devrandoom 2y ago
  [flagged]
  - Henchman21 2y ago
    Man this reminds me a lot of bank fraud, er… I meant “identity theft”!
- matthewdgreen 2y ago
  As another user notes above, there are relatively few applications of 3rd party cookies that aren’t a direct privacy violation or that can’t be realized some other way. If the manufacturer installed a special slot on your car that was explicitly designed so that anyone could install a tracking device, the first thing you’d probably do is fill that slot up with epoxy. But when we discuss simply removing that slot as a manufacturer default, everyone on HN is suddenly up in arms: “why are you blaming the third party tracking slot!? The slot itself isn’t what’s tracking you.”
  - orangecat 2y ago
    Right. Disabling third party cookies is the first thing I do with any browser (the second being uBlock Origin), and it's caused problems on exactly one site that I can recall over the last several years.
    - timewizard 2y ago
      That's because Safari made that default years ago and we've all built workarounds for this anyways. Due to the proliferation of JavaScript and it's being default enabled on all sites or they _will_ break... and the ease of setting up APIs in the cloud.. your privacy settings really don't matter much anymore anyways. Likewise "autoplay blocking" isn't too hard to overcome. It's more out of politeness that it's ever honored.
    - Yeul 2y ago
      I have two browsers on my phone. One is locked down and the other one is vanilla for those rare cases when I absolutely need to experience the internet as intended.
zmmmmm 2y ago
first party cookies yes But third party cookies are a lot more insidious, because they get sent without any visibility to the user and have generally peripheral relevance to the application they are using. It's like if you go to the supermarket and they ask you if you want to sign up for a loyalty card and you say yes, vs you go to the supermarket and they secretly plant trackers on you so that when you go to other shops they can tell who you are. One is a lot worse than the other.
- frollogaston 2y ago
  Is there a legitimate use case for 3P cookies?
  - ferngodfather 2y ago
    Cross domain same identity authentication, but this has been worked around in most cases.
    - djfivyvusn 2y ago
      Only in places where you trust the domains.
  - paulryanrogers 2y ago
    Yes. My employer uses them to facilitate a widget that site owners can just drop into place. Some of these folks are using platforms they cannot easily change or customize, and/or they cannot manage sophisticated changes.
    - frollogaston 2y ago
      Ah, and I'm guessing this could instead be done with an iframe but it would be ugly.
      - winrid 2y ago
        It would still require 3P cookies.
Buttons840 2y ago
> You as a user can delete, modity, edit, hack them to your heart's content. This is not true in practice though. Cryptography means they cannot be altered (or even read) if their creator doesn't want them to be altered. Of all the CRUD operations, users can only realiably delete the cookie.
- NBJack 2y ago
  I gotta ask: how many cryptographically secure cookies have you encountered? In theory, yes. In practice? That's kind of expensive.
  - zeroCalories 2y ago
    If you wanna do any kind of restful service securely you need to sign your data.
    - jkrejcha 2y ago
      There's nothing about that that requires JWTs/signed cookies. You may need JWTs or their moral equivalents for 3rd party services but, especially for 1st party services, session identifiers are a fine enough scheme that are oftentimes implemented more securely and have the same amount of statelessness (at least from a REST perspective) as a JWT. Not that cookies are allowable within the constraints of REST anyway due to violation of the uniform interface/stateless constraints, but pragmatically cookies have the most user agent support, and when used as just an session identifier, are relatively close to following the constraints and are much better supported than using the Authorization header or whatever[1]. Statelessness (the lack of "sessions") refers generally to the fact that the client and the server don't need to share state, i.e. the client has all it needs to make a request rather than, like, an "authorization context" or something (which is what a "user session" colloquially is). Unfortunately, the difference in the way the terms were used kinda led to this confusion which made people think that they weren't doing REST unless they were using JWTs or signed cookies. It's the difference between storing the shopping cart in a cookie or what have you vs. creating a shopping cart resource. In the former scenario, the server has to track where in the (often implicit) state machine the current client is[2], whereas in the latter, the client has all it needs (a URI, authz token, etc) to make the request and all the state is stored server-side. [1]: If browsers had better support for setting the Authorization header somehow, this would almost certainly just be a "best practice" that we take for granted. Automated clients with API keys tend to be better in this regard. [2]: And there are significant disadvantages to doing it this way, if you've ever lost your cart or got those weird "session expired" errors after hitting the back button, you've ran into the pitfalls of doing it this way.
nicce 2y ago
> They expire on their own. I have been looking them and yes, in 50 years…
immibis 2y ago
"Sawdust in bread is much maligned these days, but to defend it a little bit, the alternatives are almost universally worse for your health. Sand? Dog poop? Arsenic?"
- chii 2y ago
  well if you want cheap bread, something has got to give.

tmpz22 2y ago

Blaming privacy violations on cookies has been an absolute masterclass in public relations and is probably the greatest innovation of FANNG.

devrandoom 2y ago
[flagged]
- Henchman21 2y ago
  Man this reminds me a lot of bank fraud, er… I meant “identity theft”!
matthewdgreen 2y ago
As another user notes above, there are relatively few applications of 3rd party cookies that aren’t a direct privacy violation or that can’t be realized some other way. If the manufacturer installed a special slot on your car that was explicitly designed so that anyone could install a tracking device, the first thing you’d probably do is fill that slot up with epoxy. But when we discuss simply removing that slot as a manufacturer default, everyone on HN is suddenly up in arms: “why are you blaming the third party tracking slot!? The slot itself isn’t what’s tracking you.”
- orangecat 2y ago
  Right. Disabling third party cookies is the first thing I do with any browser (the second being uBlock Origin), and it's caused problems on exactly one site that I can recall over the last several years.
  - timewizard 2y ago
    That's because Safari made that default years ago and we've all built workarounds for this anyways. Due to the proliferation of JavaScript and it's being default enabled on all sites or they _will_ break... and the ease of setting up APIs in the cloud.. your privacy settings really don't matter much anymore anyways. Likewise "autoplay blocking" isn't too hard to overcome. It's more out of politeness that it's ever honored.
  - Yeul 2y ago
    I have two browsers on my phone. One is locked down and the other one is vanilla for those rare cases when I absolutely need to experience the internet as intended.

zmmmmm 2y ago

first party cookies yes But third party cookies are a lot more insidious, because they get sent without any visibility to the user and have generally peripheral relevance to the application they are using. It's like if you go to the supermarket and they ask you if you want to sign up for a loyalty card and you say yes, vs you go to the supermarket and they secretly plant trackers on you so that when you go to other shops they can tell who you are. One is a lot worse than the other.

frollogaston 2y ago
Is there a legitimate use case for 3P cookies?
- ferngodfather 2y ago
  Cross domain same identity authentication, but this has been worked around in most cases.
  - djfivyvusn 2y ago
    Only in places where you trust the domains.
- paulryanrogers 2y ago
  Yes. My employer uses them to facilitate a widget that site owners can just drop into place. Some of these folks are using platforms they cannot easily change or customize, and/or they cannot manage sophisticated changes.
  - frollogaston 2y ago
    Ah, and I'm guessing this could instead be done with an iframe but it would be ugly.
    - winrid 2y ago
      It would still require 3P cookies.

Buttons840 2y ago

> You as a user can delete, modity, edit, hack them to your heart's content. This is not true in practice though. Cryptography means they cannot be altered (or even read) if their creator doesn't want them to be altered. Of all the CRUD operations, users can only realiably delete the cookie.

NBJack 2y ago
I gotta ask: how many cryptographically secure cookies have you encountered? In theory, yes. In practice? That's kind of expensive.
- zeroCalories 2y ago
  If you wanna do any kind of restful service securely you need to sign your data.
  - jkrejcha 2y ago
    There's nothing about that that requires JWTs/signed cookies. You may need JWTs or their moral equivalents for 3rd party services but, especially for 1st party services, session identifiers are a fine enough scheme that are oftentimes implemented more securely and have the same amount of statelessness (at least from a REST perspective) as a JWT. Not that cookies are allowable within the constraints of REST anyway due to violation of the uniform interface/stateless constraints, but pragmatically cookies have the most user agent support, and when used as just an session identifier, are relatively close to following the constraints and are much better supported than using the Authorization header or whatever[1]. Statelessness (the lack of "sessions") refers generally to the fact that the client and the server don't need to share state, i.e. the client has all it needs to make a request rather than, like, an "authorization context" or something (which is what a "user session" colloquially is). Unfortunately, the difference in the way the terms were used kinda led to this confusion which made people think that they weren't doing REST unless they were using JWTs or signed cookies. It's the difference between storing the shopping cart in a cookie or what have you vs. creating a shopping cart resource. In the former scenario, the server has to track where in the (often implicit) state machine the current client is[2], whereas in the latter, the client has all it needs (a URI, authz token, etc) to make the request and all the state is stored server-side. [1]: If browsers had better support for setting the Authorization header somehow, this would almost certainly just be a "best practice" that we take for granted. Automated clients with API keys tend to be better in this regard. [2]: And there are significant disadvantages to doing it this way, if you've ever lost your cart or got those weird "session expired" errors after hitting the back button, you've ran into the pitfalls of doing it this way.

nicce 2y ago

> They expire on their own. I have been looking them and yes, in 50 years…

immibis 2y ago

"Sawdust in bread is much maligned these days, but to defend it a little bit, the alternatives are almost universally worse for your health. Sand? Dog poop? Arsenic?"

chii 2y ago
well if you want cheap bread, something has got to give.