5 ms·

honestly the thing that bugs me the most about the article is cookies == tracking. Sure, cookies are used for tracking, but they are also used for authenticati

honestly the thing that bugs me the most about the article is cookies == tracking. Sure, cookies are used for tracking, but they are also used for authentication, which is something that nearly every webapp needs to do. I just think that, due to articles like this, cookies end up being viewed as nothing but bad, when they are an important tool for the web when used properly. More on-topic of the article: this doesn't look like it really changes anything, to me. Like, so instead of cookies being used to track your data, they use a _browser extension_?? that is potentially even _more_ invasive. Sure, if it does what they say it will do, it kind of obfuscates your personal data. Really, what people want is just....less ads. Less targetted ads. This doesn't achieve that.

Spivak 6y ago
For basically everyone cookies == tracking. That is pretty much their only user-visible purpose. I think the best way forward would be to heavily restrict the persistent data that websites (that aren't installed as apps) can store in the browser to basically just an authentication token that is only sent by the browser and not accessible to JS. It's kinda silly that we can't manage our website logins via the browser without clearing all the cookies for a site.
wyldfire 6y ago
> Sure, cookies are used for tracking, but they are also used for authentication, which is something that nearly every webapp needs to do. What if we could move authentication or more specifically the state held in the client for authentication to some other mechanism? Could we pitch cookies? Could we make this switch without making it somehow possible for advertisers to switch to the new mechanism?
- kenniskrag 6y ago
  Already exists. Custom HTTP Header with a JWT token for example. Also in the body of a post request can be the auth data. In the URL would also be possible but is a security risk due to e.g. browser history.
  - kenniskrag 6y ago
    advertisment still works, because the site can just execute a js and make a post request to the advertisment company.
    - deleted 6y ago
      [deleted]
  - tester34 6y ago
    You have to attach that "JWT token" (heh) with e.g JS which makes it vulnerable to XSS, doesn't it?
    - kenniskrag 6y ago
      With xss you can also inject the code. So no cookie extraction needed imho.
- heythere22 6y ago
  Most session providers use a session cookie and store all the required values on the server. Moving that to the client will require a lot of additional javascript. And will also make sure that browsing without javascript is definitely impossible. Not to think about the amount of additional security holes that would open.
- peeters 6y ago
  There's no reason to if you specifically block third-party cookies, which is what is being suggested (and what Axios muddies considerably by using "cookie" and "third-party cookie" interchangably). Unless you're going to throw out local storage and custom request headers, getting rid of cookies isn't really going to do anything except make the same thing less secure (since you won't be able to benefit from the HttpOnly flag).
  - freeone3000 6y ago
    Authentication, notably OAuth, from all of the large major providers comes from a domain other than the site content domain. Blocking third party cookies indiscriminately will render you unable to log into facebook, google, twitter, or any microsoft service, or anything that uses those tokens.
    - peeters 6y ago
      3rd-party cookies aren't actually intrinsic to OIDC auth flows. They might be used by some implementations under some flows, but they're not core to the spec. Typically the user agent will redirect to a Google/etc login page where it'll have access to first-party cookies. Then will redirect back to the site which requested authentication, passing state in the query params. It's only when you get into using stuff like Okta as a delegated authentication service do you run into trouble with 3rd party cookies. Edit: As an example, I just logged into Stackoverflow using Google as the authenticator, with umatrix blocking 3rd-party cookies. Worked without a hitch.
    - drtillberg 6y ago
      The extent to which my browser configuration breaks the websites on your list is my yardstick for success.
    - michaelt 6y ago
      No it doesn't. The user clicks 'log in with google', their browser gets forwarded to whatever.google.com, the (now first party) cookie gets checked, then the user gets forwarded back to your site with the access token as a parameter in the GET request. No third party cookies needed.
- cestith 6y ago
  It could be done, but first-party cookies aren't really the issue. Most browsers have the option to disable third-party cookies, but many ad-supported sites throw a fit if you browse them that way. I think the goal is to introduce some alternative, then switch blocking third-party cookies to a default. Finally cookies could be a first-party only solution.
  - mPReDiToR 6y ago
    Do sites like this deserve my eyeballs? If the site is essential I wipe the cookies before and after reading. Most of the time I skip the site in favour of another one.
    - cestith 6y ago
      That's a good question but I won't attempt to answer it for your case.
- freeone3000 6y ago
  what if we remove the JS, and just had the web browser echo a defined string back to the server? if this token uniquely identified the session, we could safely store the data server-side, with minimal leakage to other sites and no need for code execution at all!
  - rank0 6y ago
    I can't tell if you're joking or not but this clearly already exists via HTTP headers.
    - freeone3000 6y ago
      Yes, including the echo, this is literally cookies.
- tomjen3 6y ago
  Install client SSL certificates for the websites that needs would be a start, or cookies die within 60 seconds unless a password has been entered on the site.
- fendy3002 6y ago
  IMO one step of tracking is to authenticate the tracked, so whatever the authentication method is, it'll be used as tracking method.
skybrian 6y ago
Tracking and authentication aren't quite the same, but they aren't independent either. If you are logged in all the time (like many of us are for Hacker News), then your actions can be tracked pretty well. That's kind of the point of being logged in, to let the website know who you are.

Spivak 6y ago

For basically everyone cookies == tracking. That is pretty much their only user-visible purpose. I think the best way forward would be to heavily restrict the persistent data that websites (that aren't installed as apps) can store in the browser to basically just an authentication token that is only sent by the browser and not accessible to JS. It's kinda silly that we can't manage our website logins via the browser without clearing all the cookies for a site.

wyldfire 6y ago

> Sure, cookies are used for tracking, but they are also used for authentication, which is something that nearly every webapp needs to do. What if we could move authentication or more specifically the state held in the client for authentication to some other mechanism? Could we pitch cookies? Could we make this switch without making it somehow possible for advertisers to switch to the new mechanism?

kenniskrag 6y ago
Already exists. Custom HTTP Header with a JWT token for example. Also in the body of a post request can be the auth data. In the URL would also be possible but is a security risk due to e.g. browser history.
- kenniskrag 6y ago
  advertisment still works, because the site can just execute a js and make a post request to the advertisment company.
  - deleted 6y ago
    [deleted]
- tester34 6y ago
  You have to attach that "JWT token" (heh) with e.g JS which makes it vulnerable to XSS, doesn't it?
  - kenniskrag 6y ago
    With xss you can also inject the code. So no cookie extraction needed imho.
heythere22 6y ago
Most session providers use a session cookie and store all the required values on the server. Moving that to the client will require a lot of additional javascript. And will also make sure that browsing without javascript is definitely impossible. Not to think about the amount of additional security holes that would open.
peeters 6y ago
There's no reason to if you specifically block third-party cookies, which is what is being suggested (and what Axios muddies considerably by using "cookie" and "third-party cookie" interchangably). Unless you're going to throw out local storage and custom request headers, getting rid of cookies isn't really going to do anything except make the same thing less secure (since you won't be able to benefit from the HttpOnly flag).
- freeone3000 6y ago
  Authentication, notably OAuth, from all of the large major providers comes from a domain other than the site content domain. Blocking third party cookies indiscriminately will render you unable to log into facebook, google, twitter, or any microsoft service, or anything that uses those tokens.
  - peeters 6y ago
    3rd-party cookies aren't actually intrinsic to OIDC auth flows. They might be used by some implementations under some flows, but they're not core to the spec. Typically the user agent will redirect to a Google/etc login page where it'll have access to first-party cookies. Then will redirect back to the site which requested authentication, passing state in the query params. It's only when you get into using stuff like Okta as a delegated authentication service do you run into trouble with 3rd party cookies. Edit: As an example, I just logged into Stackoverflow using Google as the authenticator, with umatrix blocking 3rd-party cookies. Worked without a hitch.
  - drtillberg 6y ago
    The extent to which my browser configuration breaks the websites on your list is my yardstick for success.
  - michaelt 6y ago
    No it doesn't. The user clicks 'log in with google', their browser gets forwarded to whatever.google.com, the (now first party) cookie gets checked, then the user gets forwarded back to your site with the access token as a parameter in the GET request. No third party cookies needed.
cestith 6y ago
It could be done, but first-party cookies aren't really the issue. Most browsers have the option to disable third-party cookies, but many ad-supported sites throw a fit if you browse them that way. I think the goal is to introduce some alternative, then switch blocking third-party cookies to a default. Finally cookies could be a first-party only solution.
- mPReDiToR 6y ago
  Do sites like this deserve my eyeballs? If the site is essential I wipe the cookies before and after reading. Most of the time I skip the site in favour of another one.
  - cestith 6y ago
    That's a good question but I won't attempt to answer it for your case.
freeone3000 6y ago
what if we remove the JS, and just had the web browser echo a defined string back to the server? if this token uniquely identified the session, we could safely store the data server-side, with minimal leakage to other sites and no need for code execution at all!
- rank0 6y ago
  I can't tell if you're joking or not but this clearly already exists via HTTP headers.
  - freeone3000 6y ago
    Yes, including the echo, this is literally cookies.
tomjen3 6y ago
Install client SSL certificates for the websites that needs would be a start, or cookies die within 60 seconds unless a password has been entered on the site.
fendy3002 6y ago
IMO one step of tracking is to authenticate the tracked, so whatever the authentication method is, it'll be used as tracking method.

skybrian 6y ago

Tracking and authentication aren't quite the same, but they aren't independent either. If you are logged in all the time (like many of us are for Hacker News), then your actions can be tracked pretty well. That's kind of the point of being logged in, to let the website know who you are.