
Changes to SameSite Cookie Behavior – A Call to Action for Web Developers - weinzierl
https://hacks.mozilla.org/2020/08/changes-to-samesite-cookie-behavior/
======
lol768
I tried to inform HMRC (and GDS: id4181490) about a bug with their Gov.UK
Verify authentication process for self assessment due to this behaviour
change.

They have no email address to report problems, the live chat agent wasn't
technical enough to understand the issue (and blamed me) and GDS put their
hands up and said it was nothing to do with them.

[https://github.com/webcompat/web-
bugs/issues/56216](https://github.com/webcompat/web-bugs/issues/56216)

I have no faith this'll get fixed on many sites before it breaks a much wider
proportion of users' workflows.

~~~
londons_explore
The solution to notifying companies via live chat agents is to format your
message like this:

> I have a technical message for the person or team responsible for building
> the XYZ website. Please ensure the following message gets delivered to them.
> Not acting on this message could cause the website to stop working entirely.

> [Technical details]

~~~
thih9
Have you seen a message like this work?

I'm asking because support agents sometimes receive messages from people who
offer consulting services, often related to website security. Some of them are
automated or not useful, but to a layperson they look similar to your template
above.

I could imagine a scenario where a support agent dismisses the above message
as spam.

~~~
giancarlostoro
I guess if you can find a manager of some sort within the org would be your
best bet.

------
jeremiahlee
Good change. It's sad that Firefox can only do these sort of changes under the
cover of Safari's or Chrome's larger marketshare. I imagine they would
instigate more of such changes sooner if they had a more dominant position.

~~~
slowwriter
I feel like anyone who has the slightest interest in the web, or even tech in
general, should use Firefox. I don't even think whether Chrome or Firefox is
the superior browser is relevant in this context.

Firefox has become the only real cross-platform and non-Google-controlled
alternative to Chrome/Chromium. It needs as much marketshare as possible in
order to stay relevant and prevent Google from completely dominating the web.

~~~
mendyberger
After seeing how google treat's users of other browsers as second class
(YouTube, search, to name a few), I decided to switch to Firefox before Google
gain's complete control over the open web

~~~
gfxgirl
Google might be #1 but they're there because people chose them and people can
just as easily choose something else. The only company that actually has
control of the web is Apple because the 1.5 billion iOS/iPadOS users have no
choice in browser engines and so Apple can basically prevent any standard from
progressing by refusing to ship it in Safari iOS. On Mac if they don't ship
people can choose Firefox or Chrome or whatever else. No other company has
that kind of power over the web, certainly not Google since at any time people
can switch away from Chrome.

~~~
slowwriter
I disagree. While I agree with you that it is highly problematic that
iOS/iPadOS users have no alternatives to WebKit in terms of what rendering
engine their browser uses, I disagree with the sentiment that Apple has a
level of control over the web that is remotely comparable to Google’s.

Why? For one, Chrome has much higher marketshare than Safari on mobile. While
Apple has a huge marketshare in terms of revenue, Android devices are much
more popular than iOS/iPadOS devices in terms of sheer numbers, and these
devices predominantly run Chrome.

As such, Chrome dominates both the mobile and desktop browser market, and the
only way for the consumer to work against that is, simply put, to run
Firefox/Gecko on his computer and his (Android) phone, or if you’re basically
anti-Google like me, WebKit on your iPhone.

------
blickentwapft
Please browser developers just make it easy to switch requirements for HTTPS
off during development.

There’s any number of circumstances in which my development machines don’t
have HTTPS.

~~~
VWWHFSfQ
This is so annoying. Our app requires HTTPS when not in debug mode. If you run
the app locally and accidentally forget to turn on debugging then it will try
to redirect to HTTPS. Firefox sees this and then from then on tries to force
HTTPS, even after you've restarted the app with debugging. And now you simply
can't access the non-HTTPS local site and I have no idea how to make Firefox
forget about the HTTPS redirect. Infuriating.

~~~
danielhlockard
Clear it from your HSTS cache, I bet you're setting that in the app when https
is hit.

~~~
VWWHFSfQ
It's not HSTS. I've tried multiple methods to clear localhost from Firefox
HSTS cache and it's not in there. But it still forces the HTTPS redirect.

~~~
iggldiggl
301 cache then?

------
whatusername
Here's a reminder about some of the fun complexity of this with Safari:
[https://www.chromium.org/updates/same-site/incompatible-
clie...](https://www.chromium.org/updates/same-site/incompatible-clients)

It's worth noting that as well as 3rd party tracking cookies - this has
impacts for things like SAML Browser Post Profile.

------
renewiltord
If I want to iframe a website that doesn't want to be iframed on my browser so
I can make some quick local tool, how do I even do it now? Previously I could
just nuke x-frame-options and the CSP headers and that's all accessible via
extension hooks but cookies aren't easy enough to do that way.

Like, go ahead and try iframing linkedin.com, with x-f-o and CSP nuked it'll
work on Firefox today but not Chrome. Even trying to intercept the cookie
doesn't work.

I wish there were a way to just easily turn this stuff off so I could
manipulate my user agent more easily.

~~~
jholman
Isn't it the case that you _can_ easily turn it off, in your own user agent?

For example, in this case (Firefox), to turn this new behaviour on ahead of
time, the article says you can go to about:config and set
network.cookie.sameSite.laxByDefault and
network.cookie.sameSite.noneRequiresSecure . I'm sort of hoping/assuming that
after this becomes the default, you'll still be able to override it using
those exact about.config properties.

~~~
renewiltord
Firefox does have that, thank you, but I think the Chrome equivalents don't do
the trick. I believed for no reason that would be the problem on Firefox too.

~~~
swensel
For Chrome:

chrome://flags/#same-site-by-default-cookies

chrome://flags/#cookies-without-same-site-must-be-secure

I found that at least the #same-site-by-default-cookies flag behaved as I
would expect when setting it to "Disabled". Use case was to load an iframe
that sets it's own cookies with no SameSite value and still have that value
default to "None".

We fixed this issue properly ("SameSite=None; Secure" in the cookie set in the
iframe), but using the #same-site-by-default-cookies flag was a workaround for
a little while.

What was a bit strange was the default behavior on Chrome was different for
users even on the same Chrome version. They seemed to be rolling it out in
phases. More info on that here: [https://www.chromium.org/updates/same-
site](https://www.chromium.org/updates/same-site)

~~~
renewiltord
We figured it out. They moved some of CSP/X-F-O to `extraHeaders` in a recent
release and it was being rolled out slowly across the world, so we were on an
early batch of rollouts. Works now.

------
verroq
Everyone’s already moved onto using service workers to implement third party
cookies. I know because we are using it in production.

-edit-

This is how we use it:

We have two domains.

Our main site `widget.com` and `widgetusercontent.com`.

`widget.com` contains an iframe from `widgetusercontent.com`.

We have a service that runs on `widgetusercontent.com/service` that is
controlled by us, but it needs to be authenticated with a temporary credential
(doesn't matter if it gets leaked) and cannot run on the same domain as
`widget.com` since it also contains user generated content.

We used to embed the URL `widgetusercontent.com/service?auth=$AUTH_COOKIE` on
`widget.com` and have the `widgetusercontent.com/service` set the cookie, but
this no longer works because this is third party cookie and has never worked
on Safari.

The solution is to load `widgetusercontent.com/service` as a blank page
containing only a service worker. We ask this page to load
`widgetusercontent.com/service/sw.js?auth=$AUTH_COOKIE`. The service we
control returns a service worker with the auth cookie embedded in it, and is
set to rewrite every request under `widgetusercontent.com/service/*` and
inject the $AUTH_COOKIE into the request header.

I came up with this myself but I assume others would have as well.

I don't know if this'll work for tracking and other nefarious stuff ad
networks use but this is a legitimate use case for us.

Yes it works in Safari. Cookies don’t work but this does.

~~~
vbezhenar
I don't understand why don't you just specify SameSite=None for your cookies?

~~~
treis
Incognito mode blocks third party cookies by default and apparently there is a
bug in Safari up to iOS 12 that treats None as strict:

>Versions of Safari and embedded browsers on MacOS 10.14 and all browsers on
iOS 12. These versions will erroneously treat cookies marked with
`SameSite=None` as if they were marked `SameSite=Strict`. This bug has been
fixed on newer versions of iOS and MacOS.

[https://www.chromium.org/updates/same-site/incompatible-
clie...](https://www.chromium.org/updates/same-site/incompatible-clients)

------
snomad
The article recommends setting network.cookie.sameSite.noneRequiresSecure to
true - this sounds like it would ignore the https only flag (on cookies that
set it)?

Is samesite=lax, cookie = https only not a valid config?

~~~
wccrawford
They recommend that if you want to try what will be the defaults when they
release this. The other setting is the other half of it.

If you enable only the setting you specified, you won't be able to set
samesite=none on http cookies, only "secure" cookies for https-only.

If you enable the other setting, cookies will default to Lax, regardless of
"secure" status for the cookie.

If you enable both, the only way to have a samesite=None (totally insecure)
cookie is over https and by manually specifying None.

------
Humphrey
I got caught out by this when upgrading all our sites to Django 2.1, as that
version sets SameSite: Lax by default.

So, I'm assuming that any Django 2.1+ site will already be compatible with
this.

------
jansan
Is this the same change that Chrome recently introduced? Or will we have to go
through a lot of changes and uncertainties again?

~~~
yoavm
Seems to be the same change.

"This is an industry-wide change for browsers and is not something Mozilla is
undertaking alone. Google has been rolling this change out to Chrome users
since February 2020, with SameSite=Lax being the default for a certain
(unpublished) percentage of all their channels (release, beta, canary)."

~~~
wildpeaks
This must be infuriating for webdevs if some of their users report an error
because they're in the percentage while the devs who have to fix things aren't
in it, unable to reproduce the error.

~~~
leegraham
The browser dev tools warn you about it (with links to how to fix it) and I
think if you’ve got the change they also tell you which cookies have been
blocked. I don’t mean that to sound holier-than-thou, even with the messages I
spent a couple of hours last week debugging the exact problem you mention on
an internal tool.

~~~
cpeterso
This is why web developers and testers should test pre-release browser
versions. Better to find out that a code change in Chrome Canary or Firefox
Nightly broke your website 4-8 weeks before the new browser ships than _after_
it ships. If the breakage is a browser bug, you still have a chance that
Google or Mozilla can fix the regression before it affects your users.

------
koolba
> For any flows involving POST requests, you should test with and without a
> long delay. This is because both Firefox and Chrome implement a two-minute
> threshold that permits newly created cookies without the SameSite attribute
> to be sent on top-level, cross-site POST requests (a common login flow).

Anybody have some background on this note?

~~~
mulcahey
Perhaps the type of login flow they’re getting to is that of an OIDC form_post
response method? An auto-posting form is returned from the identity provider,
which is then submitted to the relying party.

[https://openid.net/specs/oauth-v2-form-post-response-
mode-1_...](https://openid.net/specs/oauth-v2-form-post-response-
mode-1_0.html)

At least in .NET Core I observe a cookie for the OIDC nonce
(.AspNetCore.OpenIdConnect.Nonce - defends against replay attacks) and a
correlation cookie (.AspNetCore.OpenIdConnect.Correlation - tracks session
through the redirect handshake). Both of these are created during the login
redirect sequence and not intended to live beyond it.

The correlation cookie is set to SameSite=None here

[https://github.com/dotnet/aspnetcore/blob/master/src/Securit...](https://github.com/dotnet/aspnetcore/blob/master/src/Security/Authentication/Core/src/RemoteAuthenticationOptions.cs#L29)

The nonce cookie is set to SameSite=None here

[https://github.com/dotnet/aspnetcore/blob/master/src/Securit...](https://github.com/dotnet/aspnetcore/blob/master/src/Security/Authentication/OpenIdConnect/src/OpenIdConnectOptions.cs#L72)

I’m not familiar with many other auth flows outside of OIDC/OAuth2 but I
wouldn’t be surprised if other SSO-like flows have similar mechanisms

------
johnorourke
Magento2 discussion on this, including a contributed module to work around it
by overriding the built in cookie management:
[https://github.com/magento/magento2/issues/26377](https://github.com/magento/magento2/issues/26377)

------
scriptstar
My site [https://5pagesaday.com/](https://5pagesaday.com/) is showing Cookie
“_ga” has “sameSite” policy set to “lax” because it is missing a “sameSite”
attribute, and “sameSite=lax” is the default value for this attribute.

How to fix this? Anyone any clue?

~~~
wccrawford
That's Google Analytics. Remove it, or ask Google to fix their own stuff.

~~~
zelphirkalt
Removing it has the advantage to fix it not only for you, but also for your
visitors.

------
networkimprov
The latest FireFox also logs warnings in the console if a site cookie lacks
_SameSite_ , or has _SameSite=None_ without _Secure_.

------
AniseAbyss
"an unacceptable amount of site breakage"

I am already seeing that happen with FF unfortunately.

