Closed Bug 1812297 Opened 1 year ago Closed 1 year ago

Disable sameSite=lax by default on Nightly


(Core :: Networking: Cookies, task, P2)




111 Branch
Tracking Status
firefox111 --- fixed


(Reporter: tschuster, Assigned: tschuster)



(Keywords: dev-doc-complete, Whiteboard: [necko-triaged])


(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: nobody → tschuster

Has Chrome unshipped 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.

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.

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.

Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged]
Pushed by
Disable sameSite=lax by default on Nightly/Beta. r=ckerschb
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch

We might have some documentation for this? Maybe as some kind of experimental feature.

Keywords: dev-doc-needed

FF111 MDN docs work for this can be seen in

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.

The experimental feature (as seen on about:preferences#experimental) for same-site lax was actually removed here: So I am not sure if we still want to document it?

Flags: needinfo?(hamishwillee)

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 -
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.

Flags: needinfo?(hamishwillee) → needinfo?(tschuster)

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.

Flags: needinfo?(tschuster)

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.

You need to log in before you can comment on or make changes to this bug.