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
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.
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.
> 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.
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)
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]
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.
17 comments
[ 2.6 ms ] story [ 44.9 ms ] threadRange 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
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.
Anyway, here's a workaround for you. Right click the pdf hyperlink > Save As.
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?
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.
[1] https://pi-hole.net/2020/01/19/announcing-a-beta-test-of-pi-...
[2] https://www.bleepingcomputer.com/news/security/ublock-origin...
This is a killer for all federated login systems.
[0] https://github.com/google/google-api-javascript-client/issue...
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.
https://auth0.com/blog/browser-behavior-changes-what-develop...