Resuming SameSite Cookie Changes in July | Hacker News Reader

Resuming SameSite Cookie Changes in July

blog.chromium.org

57 pointsfeross15 comments

It should be noted that SameSite was broken with Google Sign-in because Google themselves never set the None attribute before they reverted the rollout in April. [0]

This is a killer for all federated login systems.

[0] https://github.com/google/google-api-javascript-client/issue...

Can you recommend a good article that gives an overview of the issue? I'm not really familiar with how SSO is implemented and why SameSite breaks it.

Samesite won't break it if you set it none. Eg samesite=none Google failed to set it before the official rollout.

Reason is that sso effectively uses an iframe or popup to a 3rd party auth provider (Google, Microsoft, Auth0...) Provider saves a cookie with that state (from something like accounts.google.com) and usually reads it back from first party context.

If samesite is not set to none, supporting browsers are not allowed to write cookies on the auth domain from the firstparty context, and so the firstparty scripts don't think it ever happened, even though it did. First party scripts can't read it and so sso failed.

> and engage with websites and services to ensure they are prepared for the SameSite labeling policy

I'm not experienced in this area, what does "engage with" mean in this context? Does Google send emails to webmasters, do they seek out large sites and post comments on their blogs saying "SameSite! It's in July so be ready OK?"

Is it a message that appears in Google Console, is it a posting on Google Groups and they hope lots of people will see it?

I have been seeing warnings about this in the dev console for a while now.

A cookie associated with a cross-site resource at [url] was set without the `SameSite` attribute. A future release of Chrome will only deliver cookies with cross-site requests if they are set with `SameSite=None` and `Secure`. You can review cookies in developer tools under Application>Storage>Cookies and see more details at https://www.chromestatus.com/feature/5088147346030592 and https://www.chromestatus.com/feature/5633521622188032.

https://web.dev/samesite-cookies-explained/

https://auth0.com/blog/browser-behavior-changes-what-develop...

Can we have a fixed PDF viewer before you do this, please?

Range requests (which you'll see sent for linearized PDFs) are currently broken, and the cookies won't be sent at all if the SameSite flag is set or implicitly considered to be set: https://bugs.chromium.org/p/chromium/issues/detail?id=961617

Who is "we"? I mean, I'm not going to do it. And I suspect it's not going to get fixed before July, but I'd love to be wrong.

Chrome contributors/developers, ideally..

It seems a bit irresponsible to ship this change anyway in July with this bug unfixed. Affected authenticated PDFs are completely broken beyond rendering the first page or so.

What does one have to do with the other?

Anyway, here's a workaround for you. Right click the pdf hyperlink > Save As.

One... triggers the other. You don't get the pdf bug without the cookie change per that bug report.

I missed that. Explicit SameSite: None is still possible though, and no more broken than it is now.

That issue thread was extremely interesting. Thank you. One of those issues where there is a long chain of things leading up to the bug and it's not certain where to fix it best.

Third party cookies are a liability, and I wish they go away (although the thought of having Google set web standards scares me). However, I'm afraid what this will do is accelerate a different type of tracking involving first party websites fronting the delivery of tracking scripts .(e.g. using CNAMEs, A Records ... etc)

Thankfully, both pihole[1] and uBlock Origin on Firefox [2] now block CNAMEs.

[1] https://pi-hole.net/2020/01/19/announcing-a-beta-test-of-pi-...

[2] https://www.bleepingcomputer.com/news/security/ublock-origin...

Reply on news.ycombinator.com