Mozilla warns more Firefox website breakage to come because devs just aren't checking for SameSite snafus
- Reference: 1596697385
- News link: https://www.theregister.co.uk/2020/08/06/mozilla_samesite_breakage/
- Source link:
The transition, backed by other browser vendors, has to do with the SameSite attribute, which is used to declare how browsers should handle cookies.
Described in a [1]2016 specification , the SameSite attribute allows web apps to state that cookies should not be sent with cross-site requests – requests from a third-party origin (domain). With three possible values – SameSite=None; SameSite=Lax; and SameSite=Strict – it provides a defense against cross-origin information leakage and cross-site request forgery attacks.
At the start of the year, Google said it had begun a gradual rollout of a change to the default behavior of the SameSite attribute in Chrome 80 and sounded the alarm that some sites [2]might not function properly . The change is simply that if undeclared, Chrome will assume a SameSite value of Lax instead of None .
Since web developers haven't traditionally set this attribute, the change in the default setting was expected to cause problems. The Lax setting is only a bit more restrictive than None , but it's enough to prevent some websites from functioning properly.
Google warns devs as it tightens Chrome cookie security: Stuff will break if you're not clued up [3]READ MORE
The collateral damage proved serious enough that Google temporarily reversed its SameSite rollout in April due to the initial impact of the coronavirus pandemic. It seemed a bad idea at the time to hinder access to online healthcare resources.
Last month, Google said its SameSite cookie enforcement in Chrome had resumed and would once again be ramping up. Its SameSite changes are being activated for Chrome Stable channel users in versions 80 through 84, the latest release, though it's only available for an [4]unspecified subset of users at this point.
Microsoft and Apple both support SameSite in their browsers but neither has said much about adopting the same default handling of the attribute.
Mozilla meanwhile is moving ahead with its implementation. It activated the revised SameSite default behavior in Firefox Nightly 75 back in February. And in conjunction with the release of Firefox Beta 79 in June, the safer SameSite behavior has been activated for 50 per cent of beta users.
"We are changing the default value of the SameSite attribute for cookies from None to Lax ," said Mike Conca, group product manager for Firefox Web Technologies at Mozilla, in a [5]blog post . "This will greatly improve security for users. However, some web sites may depend (even unknowingly) on the old default, potentially resulting in breakage for those sites."
Reports of snafus related to SameSite behavior, in Chrome and Firefox, have been trickling in for months. The [6]latest issue for users of a pre-release version of Firefox (v81 on the Firefox Nightly release channel) is that GOV.UK Verify, a sign-in service for UK residents to access government services, can't process logins properly.
The Register asked the UK's Cabinet Office about this but given the time difference with our San Francisco office we don't expect an immediate response.
Other websites that have broken under the new SameSite regime include [7]UK mobile provider Three , [8]Analog Devices , and Sony's [9]PlayStation.com , to name a few. Both Chrome and Firefox maintain bug lists to track site breakage.
"There is currently no timeline to ship this feature to the release channel of Firefox," said Conca. "We want to see that the Beta population is not seeing an unacceptable amount of site breakage—indicating most sites have adapted to the new default behavior."
But since there's no clear definition of "breakage," he said, the Firefox team intends to keep an eye on various channels people use to report problems, such as Bugzilla, social media sites, and the like. ®
Get our [10]Tech Resources
[1] https://tools.ietf.org/html/draft-west-first-party-cookies-06
[2] https://www.theregister.com/2020/01/30/google_chrome_80_cookies/
[3] https://www.theregister.com/2019/10/24/google_chrome_tightens_cookie_security/
[4] https://www.chromium.org/updates/same-site
[5] https://hacks.mozilla.org/2020/08/changes-to-samesite-cookie-behavior/
[6] https://github.com/webcompat/web-bugs/issues/56216
[7] https://github.com/webcompat/web-bugs/issues/54509
[8] https://github.com/webcompat/web-bugs/issues/49310
[9] https://github.com/webcompat/web-bugs/issues/54198
[10] https://whitepapers.theregister.com/
Re: Standards?
If you look at the history of the development of web standards, this is the way it's always worked because otherwise you get no movement. This is why WHATWG was founded in the first place – largely because Microsoft was blocking any changes – and how most things like http/2 have been introduced.
Re: Standards?
I be happy if Strict was the only option.
no clear definition of "breakage,"
How about "in the beta I press login and it doesn't. In the release its fine"...
Re: no clear definition of "breakage,"
That is only true for login pages though. I think they mean a more general definition. Something like "I can perform a task using the release versional but it fails in the beta" would be a start, but it needs some level of protection from facebook devs raising a bug because the "task" they want to perform is to track you everywhere you go.
Re: Have an up vote from me
for mentioning F******k. The same reasoning can also apply to Google can't it eh?
And, I hope that MS gets taken to task for flagging that you have modded your hosts file. So what if I choose to block www.microsoft.com. It is my frigging compute isn't it?
What? It isn't? Ok. Bye-bye Windows. Most of us don't need you these days anyway.
How about...
...if it doesn't work, a big red banner comes up saying "This site is using out of date trchnolgy. Be careful using it"
Then the problem would be fixed pretty quickly.
Re: How about...
But most websites don't need this level of functionality. The time and effort involved to update a minor site for a local club or something is not going to happen.
If the functionality is needed then yes some sort of warning, but something that complains about EVERY website that is not up to latest standard (and that is a nebulous thing to describe) is going to get ignored and just annoy the user, so that they won't use the browser that flags it and will go to one that doesn't
Re: How about...
I
Re: How about...
The problem is easy to fix. Google is considering that now, the SameSite default value is Lax instead of none.
Just go and set it to None and the problem goes away.
Of course, if you've never paid attention to that, you might not know where to set it. Time to learn.
Re: How about...
Mozilla can't, because it doesn't know whether the site is working properly or not. It just interprets what the site tells it to display/do. If the site is broken, the user will notice the site is broken, but the browser has just followed the instructions and knows what it has done has completed successfully.
Why the problem?
On website for domain xyz.com only cookies relating to xyz.com should be accessible. Nothing else.
Any code within that page that accesses some other domain e.g. facexyz.com can only access cookies for facexyz.com for that instance, and cookies for xyz.com are not accessible. Simples. One cookie at a time.
Re: Why the problem?
I suspect this (entirely sensible) plan falls flat when confronted by a website that pulls resources, including code, from a dozen different domains because that's easier than actually taking responsibility for serving them up from your own server.
On the other hand, this might not be a bad thing. If the site was thrown together by an idiot, I probably don't want it to work as they intended and probably do want to be encouraged to find an alternative site.
"The Register asked the UK's Cabinet Office about this but given the time difference with our San Francisco office"
About a decade.
Its the old
sign at Heathrow
"Welcome to London, please put your watches back 70 yrs"
does my browser have this enabled or not?
I'm more concerned by the fact that browser vendors are intentionally modifying the behaviour of some browsers and the users won't necessarily know (even though it may be beta software it should be clear and obvious what the user is getting & not some random or unspecified allocation).
Chrome --> "it's only available for an unspecified subset of users"
FireFox --> "SameSite behavior has been activated for 50 per cent of beta users."
Standards?
Well, isn't this happeneing because Google are choosing to change the standard without bothering to go through the process of settling it in the standards body?
I'm all for general improvements in security. But this ad-hoc, we're doing it because we're a monopoly approach is just Google asserting itself as the defacto standards setter. The more they're allowed to do this the more control over the whole web they'll get.