jiebi/CodeConvo huggingface dataset:
Code change:
5.1.13. <ins> Use cross device authentication after a successful phishing resistant authentication.  The unauthenticated channel between the initiating and authenticating device allows attackers to obtain a QR code.  When the QR Code is presented after a successful phishing resistant authentication, this prevents the attack from being initiated. Scenario A user would like to verify an identity on a web application using an identity stored on a separate mobile device in a phishing resistant way.  Using verifiable credentials from a secure and trusted wallet and presenting this to a trusted verifier service would be an example of this.  The flow is initialized using a QR Code created inside a secure session on the target service after a phishing resistant authentication.  The verifier could validate the identity from the authenticated session where the QR Code is presented, and the identity sent in the verifiable credential. 5.1.14. </ins> The practical mitigations described in this section can prevent the attacks from being initiated, disrupt attacks once they start or reduce the impact or remediate an attack if it succeeds.  When

Related discussion:
text: fixes URL
Merging new mitigation proposal
I want to use my E-ID on a verifier website to prove my identity. If I authenticated on the correct website using a phishing resistant authentication and only after this, can I scan the QR Code to present my verifiable credentials presentation. This works good, as a lot of the website where I require a digital identity check, I already have an account and can use a phishing resistant authentication first. I could add a text for this, if you think this is a good idea. Greetings Damien
NAME I think of this as a type of "authenticated flow" where the user authenticated the channel before engaging in an additional cross device flow. I think it is a reasonable mitigation, would you like to take a stab at writing up a more detailed description of the attack?
NAME Thanks for the feedback. I created a PR for this: URL Greetings Damien
Code change:
Append the result of running Serializing a Key (ser-key) with member's member_name to output. <del> If member_value is Boolean true: </del> <ins> If member_value is Boolean true: </ins> <del> Append the result of running Serializing Parameters (ser- params) with parameters to output. </del> <ins> Append the result of running Serializing Parameters (ser- params) with parameters to output. </ins> <del> Otherwise: </del> <ins> Otherwise: </ins> <del> Append "=" to output. </del> <ins> Append "=" to output. </ins> <del> If member_value is an array, append the result of running Serializing an Inner List (ser-innerlist) with (member_value, parameters) to output. </del> <ins> If member_value is an array, append the result of running Serializing an Inner List (ser-innerlist) with (member_value, parameters) to output. </ins> <del> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </del> <ins> Otherwise, append the result of running Serializing an Item (ser-item) with (member_value, parameters) to output. </ins> <del> If more members remain in input_dictionary: </del> <ins> If more members remain in input_dictionary: </ins> <del> Append "," to output. </del> <ins> Append "," to output. </ins> <del> Append a single SP to output. </del> <ins> Append a single SP to output. </ins> Return output.

Related discussion:
text: NAME noticed that is messed up. I think the fix is to indent the top-level 2-5 -- but I want to have a good look at it, compare to implementation, and I'd like others to verify, as I'm wary of making changes at this late stage. Blame seems to be , which I vaguely remember as being... surprising. That will teach me to slow down when something weird happens with Git...
Ping NAME NAME NAME to look over my shoulder...
Looking at URL the problem is that what became top-level 3 and 4 should have been steps inside top-level 2. Further changes have happened so now that applies to top-level 5 as well. (Top-level 2 itself seems good as that initiates the loop.) (Other for each statements do appear to have correct indenting.)
Like that?
Looks good to me.
Code change:
FIN bit on the stream (HTTP3).  RST exceptions are represented with an stream error (HTTP3) of type H3_REQUEST_CANCELLED (HTTP3). <del> The semantics of the headers and setting are identical to those in HTTP/2 as defined RFC8441.  HTTP3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </del> <ins> The semantics of the pseudo-header fields and setting are identical to those in HTTP/2 as defined RFC8441.  HTTP3 requires that HTTP/3 settings be registered separately for HTTP/3.  The </ins> SETTINGS_ENABLE_CONNECT_PROTOCOL value is 0x08 (decimal 8), as in HTTP/2.

Related discussion:
text: pseudo-header is hyphenated per [HTTP3], and expand out a "headers" straggler.
Thanks, this is great!
Code change:
attribute-name of "Secure", set the cookie's secure-only-flag to true.  Otherwise, set the cookie's secure-only-flag to false. <del> If the scheme component of the request-uri does not denote a "secure" protocol (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </del> <ins> If the request-uri does not denote a "secure" connection (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </ins> If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to

Related discussion:
text: This PR removes the requirement of checking the request's redirect chain during the computation of same-site-ness. This is being done because RFC6265bis is blocked by this work but we have yet to find a way to implement it in a web compatible way. In the interest of moving RFC6265bis forward the requirement is being removed.
The work to re-add the requirement back into RFC6265tris is being track by issue
Yeah, we did implement this - but we had to back it out (and re-spin stable, IIRC?) because it broke too many sites. :(
Correct, Chrome had to disable the change. Firefox had a similar experience.
We noticed a difference between Firefox & Chrome’s behavior for same-site cookies. Specifically, if a web page is requesting a resource whose final redirect target is same-site with the web page, . Firefox follows what was originally decided in URL and specified in recent i.e., Firefox looks at the whole redirect chain. For context: Firefox shipped SameSite=Lax by default this January and had to backpedal due to this (and some other webcompat issues). Firefox does not ship SameSite=Lax as the default setting for new cookies as of now. While we’re still working on our own metrics, we’ve noticed that Chrome is seeing about 1% of page loads potentially affected, which seems prohibitively high. At the same time, we would prefer not to weaken our implementation of explicit SameSite cookies, given that the redirect check was specifically added to prevent CSRF abuse scenarios. With these things in mind, we’ve been exploring the idea that we might treat cookies differently depending on whether the cookie was set to lax by default or is an explicit samesite cookie. NAME NAME it would be nice to hear some thoughts about this idea and also NAME how other browsers may have implemented . CC: NAME NAME NAME NAME NAME NAME
Yeah, I agree this is unfortunate. We did , but it broke a few sites and was backed out (or rather, put behind an off-by-default feature flag). NAME has been collecting better metrics so we can hopefully make progress on this. Can you give some more detail what you're thinking here? (also cc NAME


With these things in mind, we’ve been exploring the idea that we might treat cookies differently depending on whether the cookie was set to lax by default or is an explicit samesite cookie.
Code change:
attribute-name of "Secure", set the cookie's secure-only-flag to true.  Otherwise, set the cookie's secure-only-flag to false. <del> If the scheme component of the request-uri does not denote a "secure" protocol (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </del> <ins> If the request-uri does not denote a "secure" connection (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </ins> If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to

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.
Code change:
attribute-name of "Secure", set the cookie's secure-only-flag to true.  Otherwise, set the cookie's secure-only-flag to false. <del> If the scheme component of the request-uri does not denote a "secure" protocol (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </del> <ins> If the request-uri does not denote a "secure" connection (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </ins> If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to

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.
Code change:
attribute-name of "Secure", set the cookie's secure-only-flag to true.  Otherwise, set the cookie's secure-only-flag to false. <del> If the scheme component of the request-uri does not denote a "secure" protocol (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </del> <ins> If the request-uri does not denote a "secure" connection (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </ins> If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to

Related discussion:
text: If we standardize different behavior for default vs explicit SameSite=lax … We increase the complexity of SameSite cookies significantly. Is that desirable? Will developers be able to know the difference without this effectively being displayed as an additional cookie attribute in developer tools? Are we arriving at the desired end state or piling on more legacy and technical debt? It looks to me like this should instead be a fourth SameSite value, beside none, lax, and strict. Then we’ll have to decide if the new, fourth value is the default or the old explicit lax. I generally don’t like fixing legacy problems by increased spec complexity since it doesn’t help the web/Internet progress. I will bring this up with the CFNetwork folks at Apple to see what they have to say.
Hi John, You bring up some good points. I'm curious if the CFNetwork folks had anything to add.
I think what's under discussion is making the fourth value explicit in the specification. It apparently is already a thing in some implementations. I'm not sure we have a good reason to expose it in syntax though. But yeah, a clear name in the specification would help with tooling and such.
+1
"Default" is an explicit value for the in the algorithms and storage model defined in Section 5. It's not a part of the syntax. Unfortunately it looks like the algorithm only sets the if there's an explicit SameSite attribute in step 17 ("Default" is used for an otherwise unknown value). Presumably the should be initialized to "Default" somewhere, but that's an assumption and not explicit. The value of same-site-flag is technically undefined if there isn't a SameSite attribute and that's clearly not the intent.
Hi, Zhenchao Li from Apple working on CFNetwork. This change sounds quite complex to me. Although, if it means minimizing website breakage and tightening cookie restriction, I'm in favor of explicitly adding the behavior to the RFC. It does sound like we need to move from "SameSite=lax by default" to "SameSite=[fourth value] by default". Also, "default" still needs to be a separate state persisted in "Storage Model" so as not to be conflated any time.
Code change:
attribute-name of "Secure", set the cookie's secure-only-flag to true.  Otherwise, set the cookie's secure-only-flag to false. <del> If the scheme component of the request-uri does not denote a "secure" protocol (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </del> <ins> If the request-uri does not denote a "secure" connection (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </ins> If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to

Related discussion:
text: (I believe this is intended by latest draft, but as NAME pointed this might need some changes to the Storage Model section) NAME Could you help clarify more about "2 min Lax+POST mitigation"? I see it mentioned above but it would be great to discuss how the mitigation should behave exactly.
URL is the spec language around the behavior. As a quick refresher: the goal is to allow unsafe http methods (commonly POST) to attach cookies that do not specify a attribute but are being treat as "lax by default". This behavior is intended for newly created cookies and so has a lifetime limit of up to 2 minutes. Let me know if you have any more specific questions.
We (NAME NAME NAME and I) discussed this at TPAC and came to the following suggestion: We think that browsers have to apply a compatibility measure here, and it could be including cookies on cross-site redirects if they’re younger than, for example, 2 minutes. We’ll collect metrics to get a better understanding of what that number should be. We will update "Lax-Allowing-Unsafe" in the spec to document that behavior, which would make Chromium compliant to that and Firefox could (AFAIU) ship a compliant version as well. We’ll continue to recommend "Lax-Allowing-Unsafe" as the default behavior in the spec. We’ll note that this is a compatibility mechanism that browsers may support or not support at their own discretion. It's not a behavior sites should opt into.
I believe the "same-site redirect chain consideration" change should be removed from RFC6265bis, with the intention of adding it back to RFC6265Tris. RFC6265bis contains a number of improvements over RFC6265 that are being stalled due to UAs being unable to implement "same-site redirect chain consideration" in a web compatible way. My efforts examining metrics collected by Chrome haven't yet offered much insight into how this issue could be solved and I have no idea how much longer it could take. Because no UAs (to my knowledge) have shipped "same-site redirect chain consideration" I don't believe reverting the language will have any practical effect and shouldn't weaken any active protections. But publishing RFC6265bis as a new spec will have a number of benefits, including security/privacy benefits for the web's users.
This seems like a reasonable, pragmatic step to me.
Code change:
attribute-name of "Secure", set the cookie's secure-only-flag to true.  Otherwise, set the cookie's secure-only-flag to false. <del> If the scheme component of the request-uri does not denote a "secure" protocol (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </del> <ins> If the request-uri does not denote a "secure" connection (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </ins> If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to

Related discussion:
text: The current limbo state isn't helping anyone :) cc NAME
Yes, +1 to documenting reality and no longer blocking the IETF process for 6265bis on this particular item (which I do agree we should treat as a security bug to be eventually solved).
Not an editor, but LGTM (given that it reflects reality).LGTM, given the context.
Code change:
attribute-name of "Secure", set the cookie's secure-only-flag to true.  Otherwise, set the cookie's secure-only-flag to false. <del> If the scheme component of the request-uri does not denote a "secure" protocol (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </del> <ins> If the request-uri does not denote a "secure" connection (as defined by the user agent), and the cookie's secure-only-flag is true, then abort these steps and ignore the cookie entirely. </ins> If the cookie-attribute-list contains an attribute with an attribute-name of "HttpOnly", set the cookie's http-only-flag to

Related discussion:
text: Rephrases the requirements for the attribute to be slightly broader in order to support . Currently the requirements specifically ask for a secure protocol, with this change they'll ask for a secure connection (as defined by the user agent). This allows UAs to support cookie access on http://localhost
No WPT that I can see. According to , Firefox fully supports localhost, Chrome supports but not cookie prefixes, and Safari doesn't have support but does have an open bug.
Got it, thanks. If you're taking care of Chromium, and WebKit has an open bug, landing this seems reasonable. Thanks!
We are reporting inconsistent browser behavior regarding cookies and and prefixed cookies on . delegates the decision of what is a "secure protocol" to the user agent when describing how to handle cookies with the attribute. The affects both cookies with the attribute and cookies with name prefixes ( and ). rfc6265bis-12 states the following (): According to our tests: Firefox allows cookies to be set/sent on , as well as and prefixed cookies. Chrome also allows cookies to be set/sent with the attribute. However, and cookies are not allowed. Safari does not allow cookies to be set/sent, and consequently, and cookies are also discarded since they require that the cookie's be set to true via the cookie attribute. The table below summarises browser behavior when setting cookies on , localhost subdomains, and . We noticed these inconsistencies after interacting with developers of Web frameworks while discussing cookie integrity issues. Allowing cookies with the attribute and cookie name prefixes to be used on , would enable adopters of Web frameworks to test their applications locally, removing the burden of setting up HTTPS locally to use these security features. As shown in the table above, Firefox fully supports this behavior, while Chrome's support is still partial. Following , Firefox moved from a "secure protocol" check when handling cookies, to using the definition of specification, where is considered "Potentially Trustworthy". The states that: >An environment is a secure context if the following algorithm returns true: Chrome made the same decision following , and support for and prefixed cookies on has been deemed "in scope" (). Safari is aware of this inconsistency, but there is still no decision regarding changing their behavior (, , ).