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: Firefox is already enforcing that all redirects are same-site for cookies that have an explicit or strict attribute. We would like to keep that restriction of course. From my understanding the idea would be that only cookies that don't define their own SameSite attribute and are then "lax-by-default" we would ignore the redirects.
As a side note, Chrome does send with these redirected sub-resource requests, so internally the networking code does seem to know the correct same-site value of the request. Obviously we'd like to do the more secure behavior all the time, but we are committed to doing the specified secure behavior for explicit SameSite cookies. Firefox has enforced this for explicit SameSite cookies for maybe around a year and has not suffered a noticeable amount of web incompatibility. We are in the (slow!) process of gathering telemetry to measure the impact of this on laxByDefault vs explictly SameSite cookies. Our hope is that we can convince Chrome folks to honor the spec for explicit SameSite cookies so that users and sites will be secure as promised by the spec, and that Firefox will be less likely to run into Web Compatibility problems in the future because of this. And that if we must weaken the behavior of laxByDefault (as it appears we must based on site breakage) that we explicitly change the spec to say "lax-ish by default" cookies follow Chrome's current behavior of ignoring redirects and comparing only the originator and the final request URL.
Hello and sorry for my late response. Our (Chrome's) metrics continue to show around 1% of page loads containing 1 or more cookies that would be blocked by this enforcement. While I'm unable to share numbers (yet, I'll add them to URL once they're approved) I can say that the vast majority of values triggering this are unspecified (lax by default). I wonder then if many of these cookies are likely those being accessed after a POST request from some login or payment flow redirect chain. I don't have any data to back this hunch up but URL hints this may be the case. If it is then perhaps we can tie the redirect chain enforcement to the 2 min Lax+POST mitigation. I.e.: Allow unspecified cookies to be accessible after cross-site redirects for up to 2 minutes.