Code change:
The user agent includes stored cookies in the Cookie HTTP request header field. <del> When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field. </del> A user agent MAY omit the Cookie header field in its entirety.  For example, the user agent might wish to block sending cookies during "third-party" requests from setting cookies (see third-party- cookies). If the user agent does attach a Cookie header field to an HTTP <del> request, the user agent MUST compute the cookie-string following the algorithm defined in retrieval-algorithm, where the retrieval's URI is the request-uri, the retrieval's same-site status is computed for the HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". </del> <ins> request, the user agent MUST generate a single cookie-string and the user agent MUST compute the cookie-string following the algorithm defined in retrieval-algorithm, where the retrieval's URI is the request-uri, the retrieval's same-site status is computed for the HTTP request as defined in same-site-requests, and the retrieval's type is "HTTP". </ins> 5.7.2.

Related discussion:
text: While I worry this will further ossify that "temporary" mitigation it feels better than a blanket except for unspecified cookies. Given our metrics I don't think your proposal is unreasonable, but the more we can tighten the restriction the better. Any thoughts? Does Firefox have any data that could support or refute my idea? (Tangentially: I'd still like to see the 2 min exception removed, but I get a headache even thinking about it.)
tagging NAME NAME for visibility to the above comment. I think tying this to the 2 minute exception is fairly reasonable - 1% of page loads is sadly much too high to ship what the spec describes in any reasonable time frame. Perhaps some pages would still break, but it's worth a shot. And I agree we should change the spec to match (whatever becomes) reality here.
What about the idea of differentiating between explicit and -defaulted ? Not ideal, but then at least there won't be a security regression for those who opt into . Then for -defaulted we could do something along the lines you propose, in name of webcompat.
Right, we already differentiate between explicitly Lax () and unspecified () when it comes to the 2 min Lax+POST mitigation. Only the unspecified cookies qualify for that mitigation, explicitly Lax do not. (Perhaps it would have been better to name it Unspecified+POST, oh well) I'm suggesting to continue that pattern for the redirect chain exception, so I think we're in agreement.
NAME Yes, that's aligned with our thinking right now. Do you have numbers that can help us gain more clarity for these exact cases (a redirect where the final URL is same-site, but the overall chain is to be considered cross-site, also called "boomerang redirect") and split up into explicit-lax and default-lax? We're still in the process of collecting those within Firefox, but are obviously interested in your insights so far.
NAME I think URL has what you want. Those numbers are from roughly a week ago. tl;dr Between 80-90% of cookies are unspecified/default lax. Cookies that are being newly written are on the higher end of the range, cookies being read are lower.
Hi! John from Apple WebKit here.