Disable sameSite=lax by default on Nightly
Categories
(Core :: Networking: Cookies, task, P2)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox111 | --- | fixed |
People
(Reporter: tschuster, Assigned: tschuster)
References
Details
(Keywords: dev-doc-complete, Whiteboard: [necko-triaged])
Attachments
(1 file)
There are currently too many issues with lax-by-default to consider shipping the feature, so we might as well stop breaking sites for our Nightly population. We are also going to remove the experimental flag.
|
Assignee | |
Updated•1 year ago
|
|
||
Comment 1•1 year ago
|
||
Has Chrome unshipped https://chromestatus.com/feature/5088147346030592 or did Firefox not implement the exception?
Note: Chrome will make an exception for cookies set without a SameSite attribute less than 2 minutes ago. Such cookies will also be sent with non-idempotent (e.g. POST) top-level cross-site requests despite normal SameSite=Lax cookies requiring top-level cross-site requests to have a safe (e.g. GET) HTTP method. Support for this intervention ("Lax + POST") will be removed in the future.
https://www.chromium.org/updates/same-site/
Nov 21, 2019
Starting in Canary version 80.0.3975.0, the Lax+POST temporary mitigation can be disabled for testing purposes using the new flag --enable-features=SameSiteDefaultChecksMethodRigorously to allow testing of sites and services in the eventual end state of the feature where the mitigation has been removed.
|
|
Assignee | |
Comment 2•1 year ago
|
||
We also implement this mitigation (network.cookie.sameSite.laxPlusPOST.timeout). There are other issues, even with Chrome's implementation, that make lax-by-default problematic.
|
||
Updated•1 year ago
|
| Comment hidden (obsolete) |
|
|
Assignee | |
Comment 4•1 year ago
|
||
Pushed by tschuster@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/59bc02413996 Disable sameSite=lax by default on Nightly/Beta. r=ckerschb
|
||
Comment 6•1 year ago
|
||
| bugherder | ||
|
|
Assignee | |
Comment 7•1 year ago
|
||
We might have some documentation for this? Maybe as some kind of experimental feature.
|
||
Comment 8•1 year ago
|
||
FF111 MDN docs work for this can be seen in https://github.com/mdn/content/issues/25031
No one updated the browser compatibility data when this was exposed on nightly so there was nothing to undo.
Further there was no experimental features entry so no notification of the change there.
Upshot, all that was required was adding and experimental feature entry for this.
|
|
Assignee | |
Comment 9•1 year ago
|
||
The experimental feature (as seen on about:preferences#experimental) for same-site lax was actually removed here: https://hg.mozilla.org/mozilla-central/rev/59bc02413996#l5.12. So I am not sure if we still want to document it?
|
|
||
Comment 10•1 year ago
•
|
||
I always use the StaticPrefList.yaml to track the state of preferences - which is shown in this issue to have changed from earlybeta to false - https://hg.mozilla.org/mozilla-central/diff/59bc024139963340067d6566f7283de8f3e0c306/modules/libpref/init/StaticPrefList.yaml
When I look at FF111 nightly I can see it is still defined, though set to false.
Are you saying that under the hood this preference no longer does anything? So if someone sets the value, which they can, it will do nothing?
What's the long term plan here? If the preference does nothing and will be deleted, yes we should remove it from docs. But if it will be re-enabled we might just add a note saying that it does nothing for now and add a tracking bug link for someone who wants to see what the current state is.
Generally if a preference is not going to be used, removing it from StaticPrefList.yaml provides the clearest signal to MDN of intent.
|
|
Assignee | |
Comment 11•1 year ago
|
||
Are you saying that under the hood this preference no longer does anything? So if someone sets the value, which they can, it will do nothing?
No. I am just saying this pref is set to false by default even in Nightly and we have no plans for enabling the pref.
I guess I was under the wrong impression that the experimental prefs on MDN were mostly supposed to just match about:preferences#experimental.
|
|
||
Comment 12•1 year ago
|
||
Hi Tom,
I don't know what others do with the experimental features. In MDN we add them to experimental features and browser compatibility data when they first appear so that people can get a heads up on what they might try. We remove them from both places once the feature is released.
If the underlying feature really isn't testable at all (?) then you're right, I guess we should remove it from both places.
Description
•