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

Hi,

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
https://www.chromium.org/updates/same-site
https://www.chromestatus.com/feature/5088147346030592

(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?

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.

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?

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

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.

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.

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

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.

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!

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.

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.

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.

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

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.

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

:freddy, can we P3 this?

I think we can WONTFIX this

Thanks!