1617609 - (samesitelax) [meta] Enable sameSite=lax by default

Status: RESOLVED WONTFIX

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

Description

[Andrea Marchesini [:baku]]

Chrome is enabling samesite=lax by default. This bug is about enabling the same feature in firefox. See 1604212.

Comment 1

[ritika]

Hi,

Where can I track the release for this feature? And which versions of FF will this be launched for?

Comment 2

[j.j.]

Where can I track the release for this feature? And which versions of FF will this be launched for?

Watch this bug. See Tracking -> Milestone when Status changed to FIXED.

Mozilla may observe how Chrome's rollout goes
https://www.chromium.org/updates/same-site
https://www.chromestatus.com/feature/5088147346030592

Comment 3

[ritika]

(In reply to j.j. from comment #2)

Where can I track the release for this feature? And which versions of FF will this be launched for?

Watch this bug. See Tracking -> Milestone when Status changed to FIXED.

Mozilla may observe how Chrome's rollout goes
https://www.chromium.org/updates/same-site
https://www.chromestatus.com/feature/5088147346030592

Thanks for the information. Which values will Samesite attribute support ? Eg. None, Strict? Will the older versions also support Samesite?

Comment 4

[j.j.]

Please note that Bugzilla is a tracking database for implementers and not the best place to ask general questions, as it interferes with workflow.

Which values will Samesite attribute support ?

See https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#SameSite.
For SameSite=Lax by default the above linked Cromestatus entry should have helpful links.

Will the older versions also support Samesite?

Yes, as SameSite is supported since Firefox 60
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#Browser_compatibility

No, if you mean "Treat cookies as SameSite=Lax by default if no SameSite attribute is specified", what this bug is about.

Comment 5

[Mike Kaply [:mkaply]]

From chrome:

One policy will allow administrators to specify a list of domains on which cookies should be handled according to the legacy behavior (LegacySameSiteCookieBehaviorEnabledForDomainList), and a second policy will provide the option to set the global default to legacy SameSite behavior for all cookies (LegacySameSiteCookieBehaviorEnabled). More details about these policies will follow in future enterprise release notes before the Chrome 79 release.

Will we have the ability to do this on a per domain basis or will we just be able to flip the global default?

What is the name of the pref the controls this?

Comment 6

[Mike Kaply [:mkaply]]

See: https://bugzilla.mozilla.org/show_bug.cgi?id=1617609#c5

Comment 7

[Andrea Marchesini [:baku]]

In bug 1623313 I have implemented a similar behavior. Pref network.cookie.sameSite.laxByDefault.disabledHosts can be used to have legacy sameSite behavior for a list of hosts.

Comment 8

[Hamish Willee]

FYI, docs for this have been updated as described in here. In summary, the docs now reflect the standard for SameSite rather than what FireFox does (they do note that this has changed, and point down to the compatibility table for users to check).

What this means is that when this feature goes in the only doc change required should be a release note an update to BCD.

Comment 9

[Takanori MATSUURA]

"SameSite=lax by default" and "Reject insecure SameSite=None cookies" have been started since Chrome 85.

Comment 10

[Niklas]

Attachment: Bug 1617609: Enable sameSite=lax by default. r=ckerschb!,dveditz!

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/643bb56a34c4
Enable sameSite=lax by default. r=ckerschb,dveditz

Comment 13

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/643bb56a34c4

Comment 14

[Hamish Willee]

FYI, the Firefox 96 docs work for this can be tracked in https://github.com/mdn/content/issues/10857#issuecomment-982280050.
Mostly it is browser compatibility and also some additions to explain what "schemeful" means. The SameSite-Lax and setting for secure context were already documented.

Comment 15

[Daniel Bodea [:danibodea]]

I can definitely confirm that the "network.cookie.sameSite.laxByDefault" pref is enabled by default in Nightly v97.0a1 and Beta v96.0b7 and disabled by default in Release v95.0.2; THis was tested in Windows 10, Ubuntu 20.04.3 LTS and Mac OS 11.6.2.

Considering the fact that pascalc has added the qe-verify+ flag, I imagine he wanted the functionality tested not just the pref being enabled.
In order to properly verify this functionality, I will need some steps that I can take that would (at least) verify its basis.

Furthermore, this is a meta bug, so it could only be closed when all its dependencies are closed. Its remaining open dependencies are bug 1618610 (many breakages of this implementation) and bug 1617611 (fixing of broken tests after this implementation).

Niklas, can you help? Whan do you think should be verified here and HOW? Thanks!

Comment 16

[Niklas]

Hi Daniel,

QA testing was already done in form of a spot check. I think we just forgot to update this bug with the right label.
Ciprian Georgiu was the QA engineer i spoke to, i am sure they can fill you in on the details.

Comment 17

[Ciprian Georgiu, Desktop QA]

Hi! Yes, we spot-checked this feature in the last weeks on Beta 96. No new issues have been uncovered during testing, on Win 10 x64, Ubuntu 18.04 x64 and macOS 11. I think we can mark the meta bug as verified fixed on Beta 96, per this testing.

Comment 18

[Piradix]

A list where apply SameSite=lax et no restriction to https, will be a good solution for everyone.
TODO: A good chose to disable the cookie protection (SameSite=none pby default) is to set "SameSite=lax" when a user disable the shell "reinforced protection " (Protection renforcé) of Firefox.
Then you simplify the work of :

• developer on localhost
• devOP work.

For your information, the new politic of default "SameSite=none" and use "HTTPS", break tools chain of developer:

• they must set a cookie on they localchost server (not always possible in particular for prod serveur)
• they must configure a https service (not always possible, but a revers proxy (like stunnel) can help)
  In my case, I lost 2 days to find a workaround for 1 project for me. Now I must set my solutions on every project and on all developer environment : super !
  PS : In my case, your new politic don't crash our production server, but crash all our developer tools chain.

Comment 19

[Tom Schuster]

Bug 1751435 reverted this change again and SameSite is again restricted to (early) beta.

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last months and this bug has priority 'P2'.
:dragana, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 21

[Tom Schuster]

This is a meta bug, which probably shouldn't have an assignee. We are on top of this.

Comment 22

[edgul]

:freddy, can we P3 this?

Comment 23

[Frederik Braun [:freddy]]

I think we can WONTFIX this

Comment 24

[Valentin Gosu [:valentin] (he/him)]

Thanks!

Comment 25

[Hamish Willee]

For the MDN docs, what is the story here?

Specifically, the specification says that Lax should be the default - is this not the case? What does Firefox set by default? Do we know what iOS sets by default?

I hope to add a note to the browser compat data for this indicating the current settings. This is related to https://github.com/mdn/content/issues/36931

Comment 26

[edgul]

Firefox does not implement Lax by default. A few years ago an attempt was made, however there was too much web breakage to proceed at the time. As a result the current behaviour is when no SameSite attribute is set we use None by default. We currently have no plans to attempt again in 2025, and it's not totally clear what our long term plans are. We probably want to try again eventually, but it is definitely not a priority.