jiebi/CodeConvo huggingface dataset:
Code change:
defined in SAMESITE.  A request is "same-site" if the following criteria are true: <del> The request is not the result of a cross-site redirect.  That is, the origin of every url in the request's url list is same-site with the request's current url's origin. </del> The request is not the result of a reload navigation triggered through a user interface element (as defined by the user agent; e.g., a request triggered by the user clicking a refresh button on

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:
defined in SAMESITE.  A request is "same-site" if the following criteria are true: <del> The request is not the result of a cross-site redirect.  That is, the origin of every url in the request's url list is same-site with the request's current url's origin. </del> The request is not the result of a reload navigation triggered through a user interface element (as defined by the user agent; e.g., a request triggered by the user clicking a refresh button on

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:
defined in SAMESITE.  A request is "same-site" if the following criteria are true: <del> The request is not the result of a cross-site redirect.  That is, the origin of every url in the request's url list is same-site with the request's current url's origin. </del> The request is not the result of a reload navigation triggered through a user interface element (as defined by the user agent; e.g., a request triggered by the user clicking a refresh button on

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:
defined in SAMESITE.  A request is "same-site" if the following criteria are true: <del> The request is not the result of a cross-site redirect.  That is, the origin of every url in the request's url list is same-site with the request's current url's origin. </del> The request is not the result of a reload navigation triggered through a user interface element (as defined by the user agent; e.g., a request triggered by the user clicking a refresh button on

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:
defined in SAMESITE.  A request is "same-site" if the following criteria are true: <del> The request is not the result of a cross-site redirect.  That is, the origin of every url in the request's url list is same-site with the request's current url's origin. </del> The request is not the result of a reload navigation triggered through a user interface element (as defined by the user agent; e.g., a request triggered by the user clicking a refresh button on

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:
defined in SAMESITE.  A request is "same-site" if the following criteria are true: <del> The request is not the result of a cross-site redirect.  That is, the origin of every url in the request's url list is same-site with the request's current url's origin. </del> The request is not the result of a reload navigation triggered through a user interface element (as defined by the user agent; e.g., a request triggered by the user clicking a refresh button on

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:
6.3.2.4.2. <ins> In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window.  In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run silent frame-based flows. If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a.  WebMessaging) instead of top-level redirections.  To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in WebMessaging). Section 4.18. of oauth-security-topics provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks. 6.3.2.4.3. </ins> Browser-based applications MUST prevent CSRF attacks against their redirect URI.  This can be accomplished by any of the below:

Related discussion:
text: The new section on the security of in-browser communication flows only applies to the browser-based OAuth client. It does not apply to the BFF or TM Backend. Therefore, I moved this section to the security considerations of the relevant pattern.
Code change:
The authorization server MUST include the HTTP "Cache-Control" response header field RFC7234 with a value of "no-store" in any response containing tokens, credentials, or other sensitive <del> information, as well as the "Pragma" response header field RFC7234 with a value of "no-cache". </del> <ins> information. </ins> For example:

Related discussion:
text: These are suggested changes for a quite trivial issue. Please, take a look at my explanation in URL for more details.
URL URL " An example successful response: HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache" Pretty sure application/json shouldn't have a charset (see note at end of section URL) and I've long thought that "Pragma: no-cache" shouldn't be there (see URL ) Note that these apply to most of the example responses in the draft. Examples in RFC 6750 and RFC 6749 as well as some normative text in section of RFC 6749 use a "Pragma: no-cache" HTTP response header. However, both RFC 2616 and the shiny new RFC 7234 make special note along the lines of the following to say that it doesn't work as response header: 'Note: Because the meaning of "Pragma: no-cache" in responses is not specified, it does not provide a reliable replacement for "Cache-Control: no-cache" in them.' The header doesn't hurt anything, I don't think, so having it in these documents isn't really a problem. But it seems like it'd be better to not further perpetuate the "Pragma: no-cache" response header myth in actual published RFCs. So with that said, two questions: 1) Do folks agree that 6747/6750 are using the "Pragma: no-cache" response header inappropriately? 2) If so, does this qualify as errata?
Been working on this on and off for a while now (it's not exactly short at 80+ pages, various other priorities, etc.) but wanted to share my thoughts from an initial review of the OAuth 2.1 draft before the interim next week where it is on the agenda URL So for better or worse, here's that review: Abstract: "replaces and obsoletes the OAuth 2.0 Authorization Framework described in RFC 6749." I think "replaces" is probably unnecessary here and, to be pedantic, is arguably inaccurate because published RFCs don't ever go away or get replaced.
Code change:
The authorization server MUST include the HTTP "Cache-Control" response header field RFC7234 with a value of "no-store" in any response containing tokens, credentials, or other sensitive <del> information, as well as the "Pragma" response header field RFC7234 with a value of "no-cache". </del> <ins> information. </ins> For example:

Related discussion:
text: Probably should also consider using the official "obsoletes" attribute marker too for 6749 URL and probably also "updates"/"obsoletes" for others based on the scope of the rest of the document (not sure how this even works with a BCP or if you can or would want to update or obsolete a BCP) if this work proceeds. That scope could be better described in the abstract too as discussed somewhat in the thead URL and also the 1st paragraph of URL What is and isn't in scope is another larger question that I"m not even sure how to ask. What's included vs. what's referenced? Should this doc be incorporating bits of BCP 212 - OAuth 2.0 for Native Apps? Seems kinda antithetical to what a BCP is supposed to be but it's also a bit hard to tell how much was used. I mean, what happens if/when the BCP is updated? And that kinda begs the question of if it should also incorporate parts of or even replace the browser based apps draft? I guess that's a TBD circa page 68. There was talk about the device grant being in scope but I'm not seeing it (not saying it should or shouldn't be there but it was talked about). I dunno exactly but those are some scope questions that come to mind. Speaking of obsoleting, I do want to ensure that existing extensions and profiles of RFC 6749 that use legitimate extension points still present and unchanged in OAuth 2.1 aren't inadvertently impacted by this effort. I'm not sure how that should work in practice but want to be aware of it as/if this work progresses. URL "is designed for use with HTTP ([RFC2616])." I was momentarily proud of myself for knowing that RFC 2616 is obsolete but then remembered that the nits tool can automate the check for other obsolete or problematic references URL so take a look at those issues. Probably should also check the errata of any documents this one intends to update/obsolete or just borrowed a lot of text from to see if anything should be applied. URL "The interaction between the authorization server and resource server is beyond the scope of this specification."
Code change:
The authorization server MUST include the HTTP "Cache-Control" response header field RFC7234 with a value of "no-store" in any response containing tokens, credentials, or other sensitive <del> information, as well as the "Pragma" response header field RFC7234 with a value of "no-cache". </del> <ins> information. </ins> For example:

Related discussion:
text: Don't want to try and change the scope but perhaps a mention that things like RFC 7662 Token Introspection and self-contained tokens a la JWT exist here (or sec 1.4 or 7 or...) would be worthwhile. URL " Steps (3), (4), (5), and (6) are outside the scope of this specification, as described in Section 7." But Section 7 incorporates parts of RFC 6750 so being out of scope isn't really true. URL Not too sure about this section in this document but seems that it should at least reflect the fact that some things like RFC 8414 Authorization Server Metadata do now exist. URL All the cool drafts are doing BCP 14 [RFC2119] [RFC8174] these days. URL Mentioning the existence of RFC 7591 Dynamic Client Registration here seems appropriate. And I think it's be super useful to say that even when RFC 7591 isn't being used directly, it (and registered extensions to it URL) imply a common general data model for clients that's pretty widely used and useful even with so called static registration that "typically involve end-user interaction with an HTML registration form." URL "Authorization servers SHOULD NOT allow clients to influence their "clientid" or "sub" value or any other claim if that can cause confusion with a genuine resource owner." This text taken from draft-ietf-oauth-security-topic is out of context and somewhere between meaningless and confusing here in this document. Removing it or maybe something like this might be more appropriate: "Authorization servers SHOULD NOT allow clients to influence their "clientid" value in such a way that it might cause confusion with the identifier of a genuine resource owner during subsequent protocol interactions." URL "The client MAY omit the [clientsecret] parameter if the client secret is an empty string." Let's remove that sentence. As Michael Peck noted in his review, it doesn't even make sense in the context of this section describing authentication of confidential clients using a password/client secret. And that sentence has been the source of some other problems.