Closed Bug 1617609 (samesitelax) Opened 4 years ago Closed 5 months ago

[meta] Enable sameSite=lax by default


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




Tracking Status
firefox96 + verified
firefox124 --- wontfix


(Reporter: baku, Unassigned)


(Depends on 3 open bugs, Blocks 2 open bugs)


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


(1 file)

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

Depends on: 1617611
Keywords: site-compat


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

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

See Also: → sameSiteLax-breakage
Priority: -- → P2
Whiteboard: [necko-triaged]

(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

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

Depends on: 1620717

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 ?

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

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

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?

Depends on: 1622091

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.

Depends on: 1623313
Flags: needinfo?(ehsan)
Keywords: meta
Summary: Enable sameSite=lax by default → [meta] Enable sameSite=lax by default
Blocks: COVID-19
Depends on: 1634921
No longer depends on: 1634921
Depends on: 1642832

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.

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

Assignee: nobody → ngogge
Depends on: 1741863
Pushed by
Enable sameSite=lax by default. r=ckerschb,dveditz
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 96 Branch
Flags: qe-verify+
Regressions: 1742826

FYI, the Firefox 96 docs work for this can be tracked in
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.

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!

Flags: needinfo?(ngogge)

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.

Flags: needinfo?(ngogge)
Regressions: 1747403
No longer regressions: 1747403

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.

Flags: qe-verify+
Severity: normal → --
No longer depends on: 1617611, sameSiteLax-breakage
See Also: → 1617611
No longer depends on: 1642832, 1741863
Regressions: 1748577
Blocks: 1749679
No longer depends on: 1749634

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.
Regressions: 1750152
Regressions: 1751191
Depends on: 1751435
Depends on: 1751508

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

Resolution: FIXED → ---
Alias: samesite
Depends on: 1752475
Alias: samesite → samesitelax
No longer depends on: 1752475
Depends on: 1752475
Severity: -- → N/A
Depends on: 1763073
Blocks: cookie
Depends on: 1774857
Depends on: 1781981

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.

Assignee: n.goeggi → nobody
Flags: needinfo?(dd.mozilla)

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

Flags: needinfo?(dd.mozilla)
See Also: sameSiteLax-breakage
Depends on: 1797033
Depends on: 1800273
Depends on: 1812297

:freddy, can we P3 this?

Flags: needinfo?(fbraun)

I think we can WONTFIX this

Flags: needinfo?(fbraun)


Closed: 2 years ago5 months ago
Resolution: --- → WONTFIX
See Also: → 1873758
Target Milestone: 96 Branch → ---
You need to log in before you can comment on or make changes to this bug.