Hacker News Reader

Comment by ryu2k2 | Hacker News Reader

Honestly, I barely understand how Firefox's cookie protection works anymore. It used to have the simple option to block third party cookies that I had running all day and felt good with. That was until they started becoming necessary in certain scenarios (I can't even remember the details of what that was).

And then these days I have no idea if I can just accept a website's advertising cookies and expect Firefox to block them anyways, or if clicking on such a button would disable the browser's tracking protection.

View on HN

IIUC the main difference is that third-party cookies are not blocked, but scoped to the top-level domain.

So if you visit games.example which loads tracker.example it can set cookies. However these cookies are only used while you are on games.example. If you start browsing comics.example which also loads tracker.example it will start with no cookies, but can set cookies that only affect comics.example.

This way cross-site cookies can still be used for auth, experiments, spam protection or whatever else. But you can't do cross-site tracking as each top-level site had a separate cookie jar.

For a long while, google drive on the web would simply refuse to do anything unless you had 3rd party cookies enabled. I'm sure on purpose.

You were on drive.google.com but any files you wanted to download were on googleusercontent.com which needed auth cookies. So downloads didn't work, and neither did playing videos.

You could dodge around that with 'open in new window' but it was a pain in the ass. I think they've fixed it recently.

For me at least the whole thing could be solved with a change to the cookie management panel. Let me mark cookies(domains) I want to keep, stuff where I do want to stay logged in, and then set it to clear all unmarked cookies at the end of the session.

I use this extension to do just that: https://addons.mozilla.org/en-US/firefox/addon/cookie-autode...

The most common scenario I can think of is needing to login through a third-party gateway on a first-party site. This is now broken with mainstream browsers, and you need to find another way to do the same thing. I'm not sure what people are doing now, because you can't retain state.

I had my clients just enable it on the browser.

OAuth. You open the login page in a new window with a callback URL. The third party service adds a token to the callback URL, which authorizes you to retrieve the real auth token from that service.

I've never seen OAuth replace the scenario of a first-party site allowing user generated content that can embed a third-party site authentication flow. Are people using OAuth for that?

I've only ever seen it for explicitly supported authentication flows by the first-party site.

The flow is supported by the first party, but the login goes through a third party gateway which sends a token to the callback uri.

I think the previous poster was responding to this:

“I'm not sure what people are doing now, because you can't retain state.”

They do OAuth.

That's not what I'm talking about. I'm talking about scenarios where the authentication flow is not explicitly supported by the first party. It just exists through an iframe.

There is no replacement. It's just not possible anymore. OAuth doesn't address this.

Yes, that's right. You can't steal credentials from another site without their permission.

No... that's not how that mechanism was ever used. The authentication flow I'm describing was used by companies to embed login flows for functionality that was delivered by iframe as companion behavior next to the first-party site.

OAuth. If you take Google as example, You let them sign in with Google through OAuth and then query the user data through the APIs. On-behalf-of/authorization code grant flow.

You can’t do an iframe, but you can still get the data if it’s supported by their api and yours.

Which is the way it should be, imo.

Reply on news.ycombinator.com