https://github.com/sbingler/schemeful-same-site:
"Modify SameSite’s implementation in the user agent to consider origins with different schemes as cross-site. Thus https://site.example and http://site.example would now be considered cross-site.
Part of this effort will be to update Incrementally Better Cookies to match the intended behavior."

The behavior of schemeful-samesite as found in Nightly seems to be different to what is described in https://github.com/sbingler/schemeful-same-site.

In particular, this part does not seem to hold:

This means that both secure and insecure origins will retain access to the same set of cookies. I.e., if a user visits http://site.example with http://site.example/image.jpg and the response sets a cookie then when that user visits https://site.example the request to https://site.example/image.jpg will still send that same cookie.

In Nightly, when a cookie is set from https://site.example.com/, when I visit http://site.example.com/ I get the following warning:

Cookie “foo” has been treated as cross-site against “http://test.example.com/” because the scheme does not match.

Hi Freddy, do you know what the plans are for samesite schemeful? Do we plan to ship it or can we close this bug?

We ended up removing cookies completely from our team's scope and roadmap.

When we worked on it, I thought it necessary and useful to make the SameSite attribute a schemeful comparison, as described in https://web.dev/articles/schemeful-samesite. However, given our decision not to go forward with samesite=lax by default (due to major compat issues), I am not sure how important that is right now.
Also, from [WPT]( https://wpt.fyi/results/cookies/schemeful-same-site?label=master&label=experimental&aligned&q=schemeful and) I can see that Safari and Firefox seem to align here.

Doing anything here requires close compat monitoring. If we make that switch though, we are the 2nd engine to adopt this behavior and thus changing the assumptions for what's "default" in the web platform.

(In reply to Frederik Braun [:freddy] (reo duty for Fx124) from comment #3)

When we worked on it, I thought it necessary and useful to make the SameSite attribute a schemeful comparison, as described in https://web.dev/articles/schemeful-samesite. However, given our decision not to go forward with samesite=lax by default (due to major compat issues), I am not sure how important that is right now.

Freddy, the network.cookie.sameSite.noneRequiresSecure pref has been enabled for @IS_EARLY_BETA_OR_EARLIER@ since 2022 (bug 1750972). Should we turn this pref off now (to reduce webcompat problems for pre-release users) or leave it on to continue pre-release testing?

https://searchfox.org/mozilla-central/rev/b73676a106c1655030bb876fd5e0a6825aee6044/modules/libpref/init/StaticPrefList.yaml#11475-11478

DOM: Security team has no further plans to work on cookies, but maybe Necko does. I personally think we should go ahead with "none requires secure" and "same-site is schemeful", but that's not my call to make.

Valentin, can you tell if there are plans for Necko team?

(In reply to Frederik Braun [:freddy] (reo duty for Fx124) from comment #5)

DOM: Security team has no further plans to work on cookies, but maybe Necko does. I personally think we should go ahead with "none requires secure" and "same-site is schemeful", but that's not my call to make.

Thank you for the suggestion.

Valentin, can you tell if there are plans for Necko team?

I'll put this on the roadmap. It seems like we need to address this anyway to improve our WPT tests for cookies.

DOM: Security team has no further plans to work on cookies, but maybe Necko does. I personally think we should go ahead with "none requires secure" and "same-site is schemeful", but that's not my call to make.

I agree with Freddy. Chrome has released both features years ago.

I'll put this on the roadmap. It seems like we need to address this anyway to improve our WPT tests for cookies.

I would proceed as the following:

1. let's enable the schemeful pref in nightly to monitor breakage.
2. let's enable non-require-secure pref by default.
3. let's reintroduce schemeful in the featuregate list

edgul, thought?

Yes, we want to at least be working toward this this year. I'd also recommend we review the blocking bugs to see if there are fixes we can make before flipping any prefs on in nightly.

I agree with Freddy. Chrome has released both features years ago.

That was our optimistic take when we tried to release this as part of the laxByDefauklt constellation before. The crash and burn was so bad we had to ship an unscheduled point release to turn it back off. Granted that the most breakage was caused by our own bugs in edge cases that had not come up in a year or two of nightly testing, but even after that we ran into a bunch of bugs on sites that served us different content than Chrome because they had made their "laxByDefault" adjustments to be "if (Chrome)"

I agree we should try to ship this again, but we need to do it very deliberately and watchfully