Code change:
The retrieval's URI's path path-matches the cookie's path. If the cookie's secure-only-flag is true, then the retrieval's <del> URI's scheme must denote a "secure" protocol (as defined by the user agent). </del> <ins> URI must denote a "secure" connection (as defined by the user agent). </ins> <del> NOTE: The notion of a "secure" protocol is not defined by this document.  Typically, user agents consider a protocol secure if the protocol makes use of transport-layer security, such as SSL or TLS.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol. </del> <ins> NOTE: The notion of a "secure" connection is not defined by this document.  Typically, user agents consider a connection secure if the connection makes use of transport-layer security, such as SSL or TLS, or if host is trusted.  For example, most user agents consider "https" to be a scheme that denotes a secure protocol and "localhost" to be trusted host. </ins> If the cookie's http-only-flag is true, then exclude the cookie if the retrieval's type is "non-HTTP".

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.