jiebi/CodeConvo huggingface dataset:
Code change:
malicious) request.  Thus, the reload request should be considered cross-site, like the request that initially navigated to the page. <ins> Because requests issued for, non-user initiated, reloads attach all SameSite cookies, developers should be careful and thoughtful about when to initiate a reload in order to avoid a CSRF attack.  For example, the page could only initiate a reload if a CSRF token is present on the initial request. </ins> 8.8.6. The "Lax" enforcement mode described in strict-lax allows a cookie to

Related discussion:
text: Adds some additional notes and warnings to developers on how to more carefully use SameSite cookies.
We are reporting on the behavior of cookies on cross-site windows opened through that goes against our assumptions (implied by the current specification) on when and how cookies should be isolated. Breaking these assumptions can lead to security issues, allowing the bypass of cookies as a defense mechanism against CSRF and XS-Leak attacks. The following table shows when cookies are attached to requests associated with s and pages opened through (where :x: stands for not attached/not accessible and :whitecheckmark: for attached/accessible): The behavior of cookies regarding page reloads for pages opened through from a cross-site position is evident from the : Currently, the specification mandates blocking cookies on user-initiated page reloads but not on reloads performed through JavaScript. We think that cookies should also be blocked in this scenario, as this interaction between JavaScript navigations and cookies allows attackers to bypass the restrictions imposed by (see 2.1). Additionally, we verified that cookies, even when not sent in the top-level request that loads a page, are still attached to requests that load subresources for that page. This behavior is not explicitly defined in the specification. However, its counterpart (setting a cookie) is defined as follows: Although these requests are not cross-site, they are performed implicitly by a page navigated from a cross-site context, effectively enabling an attacker to perform authenticated cross-site requests (see 2.1), or cookie tossing attacks. Following this argument, when considering that user-initiated page reloads are deemed cross-site and therefore do not attach cookies, it seems reasonable to assume both JavaScript navigations and subresource loads should also not attach cookies, as they are also transparent to the user. It is possible to abuse the previously described behavior to bypass CSRF protections An attacker can forge same-site requests starting from a cross-site position by abusing gadgets that result in secondary same-site requests. An example of one of these gadgets is a JavaScript-based redirect that performs a redirection using attacker-controlled data. Here is a possible attack flow: Victim visits URL, setting the cookie cookie for domain .
Code change:
malicious) request.  Thus, the reload request should be considered cross-site, like the request that initially navigated to the page. <ins> Because requests issued for, non-user initiated, reloads attach all SameSite cookies, developers should be careful and thoughtful about when to initiate a reload in order to avoid a CSRF attack.  For example, the page could only initiate a reload if a CSRF token is present on the initial request. </ins> 8.8.6. The "Lax" enforcement mode described in strict-lax allows a cookie to

Related discussion:
text: Victim then visits URL, which executes The request to URL is cross-site, so it does not attach cookies URL performs a navigation to the value of the URL parameter through This triggers a request to URL, which attaches cookies, allowing an attacker to make authenticated requests from a cross-site position A similar scenario was discussed in this . Besides JavaScript redirections, other requests, such as subresource loads, could also be exploited to subvert the security assumptions granted by cookies. cookies effectively defend against certain classes of XS-Leaks attacks. However, -based attacks are still possible since cookies are attached to top-level cross-site requests. Since cookies are not attached to top-level cross-site requests, they have been deemed an effective mitigation against -based XS-Leaks. As discussed in 2.1, gadgets that allow attackers to forge same-site requests from a cross-site position can be leveraged for XS-Leaks. An example would be a page that performs a stateful subresource load, which modifies the page DOM. If an attacker opens this page through , cookies will not be attached, but following subresource loads in the new page will attach these cookies, leading to state-dependent changes to the DOM, which could be measured by the attacker (through frame counting for example). Best regards
Thanks for your well researched issue! I’ll try and address some of the points you brought up. First and foremost, SameSite is meant as only one layer in a defense in depth strategy, its design and implementation tries to balance our security and privacy goals with the realities of the web as it exists today. This ultimately means that it must be used with smart site design that leverages the other security tools and features available. differs from the original site (let’s call it a.example) navigating itself by allowing a.example to continue to hold and manipulate a reference to the new window. But, every navigation a.example makes on that reference will have an initiator of a.example (On Chrome at least, I haven’t checked other browsers, but I believe it’s true for all). This means that, as far as SameSite is concerned, an a.example window navigating itself directly or opening a new window and navigating that instead are all the same type of top-level navigation. This appears to hold true for all the examples and notes in your post. This was a purposeful decision.
Code change:
malicious) request.  Thus, the reload request should be considered cross-site, like the request that initially navigated to the page. <ins> Because requests issued for, non-user initiated, reloads attach all SameSite cookies, developers should be careful and thoughtful about when to initiate a reload in order to avoid a CSRF attack.  For example, the page could only initiate a reload if a CSRF token is present on the initial request. </ins> 8.8.6. The "Lax" enforcement mode described in strict-lax allows a cookie to

Related discussion:
text: We wanted to allow the site to be able to operate specific “landing pages” in order to allow third-party entities (maybe a sign in flow or payment processor) to navigate the user back and then the landing page could refresh to allow access to cookies in order to complete the process. Since the reload must be explicitly initiated by the page it would require the site developer to “opt-in” to the behavior and hopefully design the landing page with that behavior in mind. Conversely, we disallowed user initiated reloads because that doesn’t show an intention on the site’s behalf that it wants or needs cookies following that cross-site navigation. Users have been taught over the years to try reloading if a page looks broken, something that could occur if cookies aren’t present. Continuing to block cookies helps prevent users from inadvertently weakening their own security. That’s expected and intended. Samesite operates on a per request basis (or on a per JS call basis) so all requests, sub-resource or otherwise, are subject to the same rules. See . The spec assumes that since the page loading the same-site resources is in control of what it loads, it shouldn’t load anything that makes harmful changes. You’re correct that if a site exposes an API like you’ve given in 2.1 then it’s possible to give an attacker control + access to SameSite cookies. But to me it appears that the gadget is the footgun and I’m not sure how/if SameSite should solve this. Allowing any cross-site entity to make requests as yourself is a dangerous tool! I mentioned above that pages are in control of what they load and as long as they only load safe resources that they’re expecting they should be fine, but if you have any examples to the contrary I’m very interested in hearing about them. Going back to how s are basically the same as any other top-level navigation, this is the intended behavior. Lax cookies shouldn’t be used for anything that can allow changes to anything important. Agreed, it’s definitely possible to leak state this way. I’m not familiar with the reasoning with why the single-origin policy allows references to read , but I’m sure the spec writers had a good reason. Hope that helped clear things up, let me know if you have any other questions or concerns.
Hi NAME thanks (as usual) for the kind and thorough response!
Code change:
malicious) request.  Thus, the reload request should be considered cross-site, like the request that initially navigated to the page. <ins> Because requests issued for, non-user initiated, reloads attach all SameSite cookies, developers should be careful and thoughtful about when to initiate a reload in order to avoid a CSRF attack.  For example, the page could only initiate a reload if a CSRF token is present on the initial request. </ins> 8.8.6. The "Lax" enforcement mode described in strict-lax allows a cookie to

Related discussion:
text: I did a bit of additional investigation and found some discussions that we missed before opening the issue: URL and URL As far as I understood, the current behavior concerning page reloads has been defined only recently (2021). Before that, different browser vendors had . Even nowadays, browsers do not seem to fully agree on the intended behavior, or at least Firefox is inconsistent with Chrome's behavior since it does not attach SameSite=strict cookies after a call to . Some confusion on this matter is justifiable. :) I now see the rationale behind the design that enables specific pages to opt-in to SameSite=strict cookies upon a self-initiated reload. I always thought SameSite=lax cookies ensured compatibility with SSOs and payment flows, as lax cookies are attached to top-level navigations. But this "strict + reload hack" (so to say) puts the webpage in control instead of attaching cookies to all cross-site top-level requests. The downside of this behavior, as discussed, is that JS-based open redirectors become a gadget for bypassing SameSite=strict cookies. I'm not sure if the benefits outweigh the risks, but probably, the spec would benefit from a more explicit discussion of this trade-off. Concerning subresource loading, I would argue that in general this is not a valid assumption. In principle, here we have an untrusted context (the cross-site page opened via ) that automatically loads authenticated resources. This is somehow the dual of SRI, CSP, mixed content, and other security mechanisms that prevent a trusted context from loading untrusted resources that an attacker could abuse. We have not measured the prevalence of security issues caused by this behavior in the wild (i.e., xs-leaks introduced by an authenticated subresource being loaded), but I would expect a non-negligible number of affected instances. The current behavior surprised me, and it is possible that developers who care about protecting from xs-leaks are also unaware of the potential risks. For instance, the states that: citing only other reasons (e.g., the 2 minutes exception rule) as major limitations of SameSite cookies. To conclude, we just wanted to discuss this issue after encountering a behavior that diverges from our mental model of SameSite cookies and that we could not entirely justify it after reading the spec.
Code change:
malicious) request.  Thus, the reload request should be considered cross-site, like the request that initially navigated to the page. <ins> Because requests issued for, non-user initiated, reloads attach all SameSite cookies, developers should be careful and thoughtful about when to initiate a reload in order to avoid a CSRF attack.  For example, the page could only initiate a reload if a CSRF token is present on the initial request. </ins> 8.8.6. The "Lax" enforcement mode described in strict-lax allows a cookie to

Related discussion:
text: As for JS-initiated reloads, if the behavior is here to stay, I think the spec could mention these limitations more explicitly to prevent developers from building their applications based on wrong assumptions. Thanks again for the discussion! Marco
Hi NAME As you found in those discussions, reload behavior wasn’t well aligned previously and I’m not sure how purposeful each UA’s behavior was at the time. I know Firefox has a number of SameSite related behaviors behind default disabled configs, this could be as well. I don’t have easy access to Firefox at the moment but I believe the nightly builds have these flags enabled. What happens if you try testing on a nightly build? SameSite=Lax is useful for flows that use top-level navigation, but if a flow is happening in an iframe then SameSite=Lax cookies would be blocked. The reload technique enables these iframe based flows to function. The issue here is that a page may still load sub-resources that require SameSite=Strict auth cookies even if the initial request didn’t include those auth cookies? Plainly, any site that allows unauthenticated access to a page which loads authenticated sub-resources is incorrectly using SameSite. Sites should return a 401 error, or some other denial, if the initial request does not include the appropriate cookies. Sadly though, I agree with you that there are probably sites that do not. Just to confirm, the behavior you’re talking about are: URL navigations are not as restrictive as iframe navigations. Non-user controlled reloads allow cookies Sub-resource requests send SameSite cookies Redirect gadgets allow access to SameSite cookies Did I miss any? What do you mean by “these limitations”? Are you referring to the redirect gadget?
Any remaining comments/concerns before I close?
Hi NAME Sorry, I missed your earlier reply in October, and I'm just now seeing it. Thanks for the ping. I tried Firefox 123.0.1 (stable) and Firefox 125.0a1 (nightly), and they behave the same way. SameSite cookies are not attached to requests initiated via , but they are attached to requests caused by . Chrome sends the cookie in both cases. Indeed. While open redirectors and script gadgets are known to carry their problems, I am concerned about issues enabled by authenticated subresource requests, as they are less known to web developers. I don't think so.
Code change:
malicious) request.  Thus, the reload request should be considered cross-site, like the request that initially navigated to the page. <ins> Because requests issued for, non-user initiated, reloads attach all SameSite cookies, developers should be careful and thoughtful about when to initiate a reload in order to avoid a CSRF attack.  For example, the page could only initiate a reload if a CSRF token is present on the initial request. </ins> 8.8.6. The "Lax" enforcement mode described in strict-lax allows a cookie to

Related discussion:
text: All of the above, actually. I understand that it's challenging to change the behavior at this point. Still, I think it would be beneficial to explicitly document both redirection gadgets and authenticated subresource requests under Sec. 8.8 of the spec. This would help web developers to understand the risks better and adopt mitigations. Cheers, Marco
Still LGTM.
Code change:
3.3. <del> A client that makes a request to an "https" URI uses TLS12 with the </del> <ins> A client that makes a request to an "https" URI uses TLS13 with the </ins> TLS-ALPN. HTTP/2 over TLS uses the "h2" protocol identifier.  The "h2c"

Related discussion:
text: A lot has happened to TLS since we did RFC 7540. This tries to capture that succinctly. It rolls in changes from RFC 8740.It mentions early data and RFC 8470.It updates references, citing TLS 1.3 rather than 1.2 for a generic TLS reference.
A few small changes are included in , which could be integrated easily.
I won't create the pull request just yet, but here are some proposed changes: URL NAME do you think that you could review these? I've paraphrased some of RFC 8740 and I want to make sure I haven't missed anything.
(The GitHub link did something silly, but I'm assuming 837d46a5ff9e23a62cb719f69be7f1d10bf8da80 is the right commit and just looked at that.) s/the handshake// Though I wonder if this sentence can just be omitted. I needed to address it in RFC8740 because RFC7540 didn't have a TLS version dispatch. But now the TLS 1.2 features section is explicitly mentioned as being 1.2-only, so that exception already doesn't apply. Otherwise LGTM. (I think the default values in server settings is implicit from the fact that we haven't received anything from the server yet, but whatever.)
Thanks. I've updated my branch to remove the renegotiation piece. I've updated that link (which I should have checked).
Code change:
This memo sets this specification to be the establishing document for the HTTP Digest Algorithm Values [4] registry. <ins> IANA is asked to update the "Reference" for this registry to refer this document and to inizialize the registry with the tokens defined in algorithms. This registry uses the Specification Required policy (Section 4.6 of RFC8126). </ins> 13.2. This memo adds the "contentMD5" token in the HTTP Digest Algorithm

Related discussion:
text: add registration policy cc: NAME and NAME to URL Using RFC policy avoids the issues we had to face to refresh the current table. See
NAME now it's Specification Required :)
This specification obsoletes 3230 and updates the IANA registry to point to it, but doesn't specify what the registration policy actually is.
Related to NAME says
See
NAME do we need ? [x] 5. 'The IANA acts a registry' reads oddly; it maintains the registry. Also, saying 'the registry contains the tokens listed below' is misleading; these are initial registrations, which can be modified and added to after the RFC is published. Also, these might be better placed in IANA Considerations.[x] 5. There should not be RFC2219-MUSTs in IANA registry text. This can be addressed by having a requirement similar to "Deprecated digest algorithms MUST NOT be used."[ ] 5. The ability to have a digest algorithm that ignores content-codings is something of a surprise after reading section 2; it needs to be at least mentioned up there.
I'm sure I made this comment somewhere but I've lost it. I don't think we should mandate RFC required, that a very high bar for algorithms (and their users) that most likely developed the algoithm elsewhere already. Instead seem like a better option here
NAME imho registering new algos should be done via an RFC, this doesn't imply that those algorithms should be defined in an RFC. While it is fair to delegate the registration to an external specification, I think the approach of an RFC (eg URL ) is a lot more clean and improves the overall interoperability. It is important to note that any type of RFC is sufficient (currently Standards Track, BCP, Informational, Experimental, or Historic). In any case, I don't think this should be a game-stopper, so if there's general consensus on "Specification Required", that's ok.
I don't think running an RFC process can provide any meaningful value to the registration requirements. I mean, that's going to add like a year of overhead to something as simple as "use algorithm $foo with token , the output is encoded using base64".
The key to Specification Required is the Designated Experts. If they do they job you basically get what you need.
Code change:
This memo sets this specification to be the establishing document for the HTTP Digest Algorithm Values [4] registry. <ins> IANA is asked to update the "Reference" for this registry to refer this document and to inizialize the registry with the tokens defined in algorithms. This registry uses the Specification Required policy (Section 4.6 of RFC8126). </ins> 13.2. This memo adds the "contentMD5" token in the HTTP Digest Algorithm

Related discussion:
text: If there's any question from the DEs they can always kick it back out for further review.
NAME Seems that NAME is on the same page URL ;) So let it be Specification Required! Move on :)
Code change:
This document describes a set of data types and associated algorithms that are intended to make it easier and safer to define and handle <del> HTTP header and trailer fields, known as "Structured Fields", or "Structured Headers".  It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. </del> <ins> HTTP header and trailer fields, known as "Structured Fields", "Structured Headers", or "Structured Trailers".  It is intended for use by specifications of new HTTP fields that wish to use a common syntax that is more restrictive than traditional HTTP field values. </ins> Note to Readers

Related discussion:
text: Editorial: add one reference to Structured Trailers in a list of the types, and correct what appears to be a typo of Structured Field --> Structured Trailer.
Happened to spot these when perusing the structured headers spec; apologies if I've misread and the original text was correct.
Thanks!
Code change:
If a cache updates a stored response with the metadata provided in a HEAD response, the cache MUST use the header fields provided in the <del> HEAD response to replace all instances of the corresponding header fields in the stored response (subject to the exceptions in freshening.responses) and append new header fields to the stored response's header section unless otherwise restricted by the header field. </del> <ins> HEAD response to update the stored response (see update). </ins> 4.4.

Related discussion:
text: Now that we have three different places referring to the text on updating stored headers, it deserves its own section. In the process, I noticed that the current text forgot to mention that CC: private and no-cache can have arguments that affect header storage.
says: As per other discussions, this needs to be more nuanced; either a reference to 4.3.4, or new text.
The that no one is really doing this; is either converted to a GET on the backend, or it doesn't seem to touch the cache. I think the most sane thing to do is to refer to the rules for a 304 update, but make it clear that this is optional.
Could you clarify how HEAD is relevant for "Combining Partial Content"?
Arg, sorry, wrong issue.
Code change:
decimal point.  User configuration of these values ought to be limited in the same fashion. <del> 12.1.1.3. </del> <ins> 12.4.3. </ins> Most of these header fields, where indicated, define a wildcard value <del> ("*") to select unspecified values.  If no wildcard is present, all values not explicitly mentioned in the field are considered "not acceptable" to the client. </del> <ins> ("*") to select unspecified values.  If no wildcard is present, values that are not explicitly mentioned in the field are considered unacceptable, except for within where it means the variance is unlimited. 12.5. </ins> <del> 12.1.2. </del> <ins> 12.5.1. </ins> The "Accept" header field can be used by user agents to specify their preferences regarding response media types.  For example, Accept

Related discussion:
text: initial commit is just moving sections and updating headings; second commit will update some of "the following" comments to refer to the specific fields.
I believe it needs to be under "Proactive Negotiation" , or be a sibling of these...