Hacker News Reader

Comment by holtalanm | Hacker News Reader

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.

View on HN

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.

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

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.

advertisment still works, because the site can just execute a js and make a post request to the advertisment company.

You have to attach that "JWT token" (heh) with e.g JS which makes it vulnerable to XSS, doesn't it?

With xss you can also inject the code. So no cookie extraction needed imho.

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.

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

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.

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.

The extent to which my browser configuration breaks the websites on your list is my yardstick for success.

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.

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

I block third party cookies indiscriminately, and I never had issues logging into Facebook, Google, Twitter, or any Microsoft service except for Microsoft Teams. This includes logging into third-party services using the Google login.

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.

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.

That's a good question but I won't attempt to answer it for your case.

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!

I can't tell if you're joking or not but this clearly already exists via HTTP headers.

Yes, including the echo, this is literally cookies.

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.

IMO one step of tracking is to authenticate the tracked, so whatever the authentication method is, it'll be used as tracking method.

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.

Reply on news.ycombinator.com