
Resuming SameSite Cookie Changes in July - feross
https://blog.chromium.org/2020/05/resuming-samesite-cookie-changes-in-july.html
======
cremp
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...](https://github.com/google/google-api-javascript-
client/issues/561)

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

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

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

~~~
illnewsthat
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](https://www.chromestatus.com/feature/5088147346030592)
and
[https://www.chromestatus.com/feature/5633521622188032](https://www.chromestatus.com/feature/5633521622188032).

------
someguy12321
[https://web.dev/samesite-cookies-explained/](https://web.dev/samesite-
cookies-explained/)

[https://auth0.com/blog/browser-behavior-changes-what-
develop...](https://auth0.com/blog/browser-behavior-changes-what-developers-
need-to-know/)

------
lol768
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](https://bugs.chromium.org/p/chromium/issues/detail?id=961617)

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

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

~~~
recursive
What does one have to do with the other?

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

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

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

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

~~~
Karupan
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-...](https://pi-hole.net/2020/01/19/announcing-a-beta-test-of-pi-hole-5-0/)

[2] [https://www.bleepingcomputer.com/news/security/ublock-
origin...](https://www.bleepingcomputer.com/news/security/ublock-origin-now-
blocks-sneaky-first-party-trackers-in-firefox/)

