10 ms·
Changes to SameSite Cookie Behavior – A Call to Action for Web Developers
- jansan 6y agoIs this the same change that Chrome recently introduced? Or will we have to go through a lot of changes and uncertainties again?
- yoavm 6y agoSeems 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 6y agoThis 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 6y agoThe 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.
- lol768 6y agoThere's an argument to send pertinent A/B study information in a request header of some sort, for this reason. It's now no longer enough to just look at the UA.
- cpeterso 6y agoThis 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.
- treis 6y agoCan confirm it is infuriating. Even worse when it's retail customer facing and it works for all developers. This broke our chat widget and is probably the explanation for our declining chat numbers. Nobody connected the dots until some developers got included in the rollout. Now all hell broke lose because the business realized we've been serving a broken chat feature to some users for months.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- lol768 6y agoI 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.
- IceCreamGondola 6y agoAs someone who used to work in Civil Service I can't say I'm surprised. The range of technical competance across the different government departments is staggering. Some are really making leaps and bounds while others are bloated, technical monoliths.
- garyclarke27 6y agoMaybe that explains why I’ve had numerous expensive problems with HMRC site, including missing VAT filing deadlines. By trial and error I found the only way to successfully use their site is to delete all HMRC and UK gov cookies before logging in.
- xenophonf 6y agoWeird issues like that are a big reason why I use in-private browsing all the time now.
- londons_explore 6y agoThe 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 6y ago
- verroq 6y agoEveryone’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.
- ThePhysicist 6y agoCare to elaborate how this works?
- verroq 6y agoI updated the parent post.
- nieve 6y agoIs this currently blocked by uBlock Origin/uMatrix?
- verroq 6y agoNothing blocks service workers except the Brave browser.
- renewiltord 6y agoIf 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.
- emn13 6y agoIn general: Use a custom proxy instead of using your browser as a proxy, in essence. I'm curious too - what's the use case for this? Why would you want to iframe linkedin?
- renewiltord 6y agoIt was a trivial half-hour project that I sunk-cost-fallacied into a couple of hours. I wanted to embed LinkedIn into our recruiting lead qualification tool so that you don't have to open a new tab (it's right on the page in a two-pane display). It was enough of an improvement that people could just start their day, qualify some 10 leads, and then bang on with the day. We had a chap build it and it worked really well actually till SameSite became required on Chrome. Opening in a new tab was frustrating enough that people would feel like maybe doing a couple and then push it to the rest of the day and it would fall by the wayside against their "real job", so to speak. Besides, they'd be doing it feeling like an obligation which I don't think puts one in the right frame of mind.
- emn13 6y agoYeah, so I think this is pretty much the a kind of scenario the feature is designed to break - an essentially stock browser navigating to some site, that can then wrap a trusted site, and potentially be a stepping stone for phishing or other nastiness. Obviously, if you have detailed control over the client - everything goes! But for fairly standard browsers, you don't want to allow this kind of nesting; at least not when the two sites aren't cooperating (and clearly linkedin isn't). It's possible there's some addon api to work around this, otherwise you'll need to use a proxy - which isn't too hard, really. Essentially: you need to have admin level control over the browser to allow this, or some other proxy; the browser won't allow a random website to see another site's cookies, even indirectly - which is by design. So in your case: since this is a feature, not a bug - a trivial workaround looks unlikely.
- Humphrey 6y agoI 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.
- johnorourke 6y agoMagento2 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
- jeremiahlee 6y agoGood 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.
- bawolff 6y agoI don't really recall them doing so back when they had real marketshare.
- javagram 6y agoFirefox never had the dominant position that Chrome has now. Chrome can get away with breaking the web because most people wouldn’t even think to switch to Firefox or IE at this point.
- starbugs 6y agoIt was important enough around 2010 to have a real impact (30+%). Why wouldn't people switch to FF anymore? I'd say because they prioritize their product development in the wrong way. It's really sad. Competition would be helpful for the market.
- emn13 6y agoI don't really think that's it; I think people just don't believe their personal choice of browser is going to make enough of a difference to privacy and competition to actually positively affect them; they just don't care in other words. And... I'm not sure their wrong. Sure, more competition would be good, but it's hard to see that being enough to address the monopolistic issues browsers currently face. And on iOS - you don't even really have a choice, given apples rules.
- starbugs 6y agoI have tried switching from Chrome to FF multiple times in the past 18 months. It just doesn't work. Neither for development nor for general use. It's sadly just not competitive anymore.
- AniseAbyss 6y ago"an unacceptable amount of site breakage" I am already seeing that happen with FF unfortunately.
- koolba 6y ago> 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 6y agoPerhaps 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_0.html https://openid.net/specs/oauth-v2-form-post-response-mode-1_... 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/Security/Authentication/Core/src/RemoteAuthenticationOptions.cs#L29 https://github.com/dotnet/aspnetcore/blob/master/src/Securit... The nonce cookie is set to SameSite=None here https://github.com/dotnet/aspnetcore/blob/master/src/Security/Authentication/OpenIdConnect/src/OpenIdConnectOptions.cs#L72 https://github.com/dotnet/aspnetcore/blob/master/src/Securit... 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
- scriptstar 6y agoMy 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 6y agoThat's Google Analytics. Remove it, or ask Google to fix their own stuff.
- zelphirkalt 6y agoRemoving it has the advantage to fix it not only for you, but also for your visitors.
- whatusername 6y agoHere's a reminder about some of the fun complexity of this with Safari: https://www.chromium.org/updates/same-site/incompatible-clients https://www.chromium.org/updates/same-site/incompatible-clie... It's worth noting that as well as 3rd party tracking cookies - this has impacts for things like SAML Browser Post Profile.
- blickentwapft 6y agoPlease 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 6y agoThis 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 6y agoClear it from your HSTS cache, I bet you're setting that in the app when https is hit.
- marksomnian 6y agoWith Chrome you can go to chrome://flags, find “unsafely treat insecure origins as secure”, and allowlist your dev server.
- joewrong 6y agoThis may help https://github.com/FiloSottile/mkcert https://github.com/FiloSottile/mkcert
- snomad 6y agoThe 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 6y agoThey 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.
- networkimprov 6y agoThe latest FireFox also logs warnings in the console if a site cookie lacks SameSite, or has SameSite=None without Secure.