LGTM1 On Wed, Apr 24, 2024 at 5:46 PM Christian Biesinger <cbiesin...@chromium.org> wrote:
> Hi Yoav, > > with regards to the spec: As Johann suggests, this can't really be > specified today and I am hoping we won't block on that as he suggests. (the > cookie spec linked from the fetch spec does not mention SameSite at all... > https://httpwg.org/specs/rfc6265.html#cookie) > Yeah, I'm convinced that this entire area is not currently specified, and that y'all are making strides towards that, and we shouldn't block this particular change on them. I just wanted to verify that what y'all are planning to ship aligns with my understanding of what we'd want to eventually specify here. > > with regards to the implementation: We do not send SameSite=Lax cookies > That makes sense. Thanks! > > Christian > > On Wed, Apr 24, 2024 at 11:04 AM Yoav Weiss (@Shopify) < > yoavwe...@chromium.org> wrote: > >> fetch-accounts <https://fedidcg.github.io/FedCM/#fetch-accounts> says >> that the origin for accounts requests is an opaque origin. What does that >> mean for `Same-Site: Lax` cookies? Will they be sent or not? >> >> On Tuesday, April 23, 2024 at 9:08:33 PM UTC+2 Johann Hofmann wrote: >> >>> I wanted to chime in on fetch + cookies integration: Yes, it's very >>> underspecified >>> <https://fetch.spec.whatwg.org/#http-network-or-cache-fetch:~:text=If%20includeCredentials%20is%20true%2C%20then%3A> >>> and leaves the computation of the actual SameSite status of cookies >>> included in the request to the cookies RFC >>> <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-rfc6265bis/#name-same-site-and-cross-site-re>. >>> This needs work on Fetch, 6265bis, HTML and Cookie Store specs (and now >>> also needs to consider 3PC blocking!) which we're actively doing right now >>> and hope to have some progress to share soon. I would not want to block >>> this feature on it (and we haven't blocked other features in the past). I >>> would expect the FedCM spec to adjust to the cookie layering work once that >>> lands, and can work with the team to make sure that happens. >>> >>> Hope this helps, >>> >>> Johann >>> >>> On Tue, Apr 23, 2024 at 8:05 PM Christian Biesinger < >>> cbiesin...@chromium.org> wrote: >>> >>>> Just wanted to ping this thread -- any lgtms? Or will it be discussed >>>> at tomorrow's meeting? >>>> >>>> Christian >>>> >>>> On Thu, Apr 18, 2024 at 11:31 AM Christian Biesinger < >>>> cbiesin...@chromium.org> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Apr 17, 2024 at 10:13 PM Domenic Denicola < >>>>> dome...@chromium.org> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Apr 18, 2024 at 6:19 AM Christian Biesinger < >>>>>> cbiesin...@chromium.org> wrote: >>>>>> >>>>>>> Contact emails >>>>>>> >>>>>>> cbiesin...@chromium.org >>>>>>> >>>>>>> >>>>>>> Explainer >>>>>>> >>>>>>> See summary >>>>>>> >>>>>>> >>>>>>> Specification >>>>>>> >>>>>>> https://fedidcg.github.io/FedCM/#fetch-identity-assertion >>>>>>> >>>>>> >>>>>> I wasn't able to find the part of the spec that talks about which >>>>>> cookies are sent. Probably I just don't understand Fetch + cookies >>>>>> integration well enough. Could you help point it out? Or maybe link to >>>>>> the >>>>>> PR that makes the change? >>>>>> >>>>> >>>>> It turns out our implementation did not match the spec in this >>>>> respect, so there was no PR (just an impl change). >>>>> >>>>> It is probably me who does not understand the fetch + cookies >>>>> integration, but my thinking is that because we give an origin to the >>>>> fetch >>>>> algorithm (the RP's origin), which is not same-site with the identity >>>>> provider (normally), fetch should not send SameSite=Strict cookies. >>>>> >>>>> Also cc'ing Dominic (Farolino) who has helped us in this area. >>>>> >>>>> [You may ask, what happens if the RP is indeed same-site with the IDP? >>>>> I think we would send SameSite=Strict cookies in that situation, but that >>>>> case is rare] >>>>> >>>>> Christian >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> Summary >>>>>>> >>>>>>> We recently changed >>>>>>> <https://chromestatus.com/feature/5094763339710464> FedCM to send >>>>>>> ID assertion requests with CORS. As a side-effect, that change also >>>>>>> meant >>>>>>> that we no longer send SameSite=Strict cookies to the ID assertion >>>>>>> endpoint >>>>>>> (we still send SameSite=None). Since it does not make sense to send a >>>>>>> different set of cookies to the accounts endpoint and the ID assertion >>>>>>> endpoint, this change makes them consistent – they both should get the >>>>>>> same >>>>>>> credentials as they identify the user in the same way. >>>>>>> >>>>>>> Not sending SameSite=Strict cookies is also consistent with >>>>>>> requestStorageAccess >>>>>>> behavior >>>>>>> <https://developers.google.com/privacy-sandbox/3pcd/related-website-sets-integration#cookie_requirements> >>>>>>> and cross-site requests in general. >>>>>>> Blink component >>>>>>> >>>>>>> Blink>Identity>FedCM >>>>>>> <https://issues.chromium.org/issues?q=status:open%20componentid:1456331&s=created_time:desc> >>>>>>> Search tags >>>>>>> >>>>>>> fedcm <https://chromestatus.com/features#tags:fedcm>, samesite >>>>>>> <https://chromestatus.com/features#tags:samesite>, cookies >>>>>>> <https://chromestatus.com/features#tags:cookies> >>>>>>> >>>>>>> >>>>>>> TAG review >>>>>>> >>>>>>> None >>>>>>> >>>>>>> >>>>>>> TAG review status >>>>>>> >>>>>>> Not applicable >>>>>>> >>>>>>> >>>>>>> Risks >>>>>>> >>>>>>> >>>>>>> >>>>>>> Interoperability and Compatibility >>>>>>> >>>>>>> There should be no interop risk because no other browser has shipped >>>>>>> FedCM yet and this change was requested by Webkit, with Gecko supporting >>>>>>> the request. >>>>>>> >>>>>>> With regards to compatibility, we have tested the known IDPs that >>>>>>> use FedCM and this is not an issue. In addition, for any IDP that >>>>>>> supports >>>>>>> "Sign in with X" on the web without FedCM, cookies must already be >>>>>>> SameSite=None because these requests are cross-origin by definition. >>>>>>> >>>>>>> Gecko: Positive. Change supported by Gecko >>>>>>> (https://github.com/fedidcg/FedCM/issues/320#issassessment >>>>>>> the team has done assessment the team has done uecomment-2012070115 >>>>>>> <https://github.com/fedidcg/FedCM/issues/320#issuecomment-2012070115>). >>>>>>> Not filing a standards position request for small additions at the >>>>>>> explicit >>>>>>> request from Firefox (they prefer PRs). >>>>>>> >>>>>>> WebKit: Positive. Change requested by WebKit (in a VC, no link >>>>>>> available). Recently, standards position requests for smaller FedCM >>>>>>> features have been closed, pointing to the (unresolved) main FedCM one >>>>>>> in >>>>>>> https://github.com/WebKit/standards-positions/issues/309 so not >>>>>>> filing one for this. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Web developers: No signals >>>>>>> >>>>>>> >>>>>>> Other signals: >>>>>>> >>>>>>> >>>>>>> WebView application risks >>>>>>> >>>>>>> Does this intent deprecate or change behavior of existing APIs, such >>>>>>> that it has potentially high risk for Android WebView-based >>>>>>> applications? >>>>>>> >>>>>>> None >>>>>>> >>>>>>> >>>>>>> >>>>>>> Debuggability >>>>>>> >>>>>>> None >>>>>>> >>>>>>> >>>>>>> >>>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>> >>>>>>> No >>>>>>> >>>>>>> Supported on all platforms except Webview, where FedCM is not >>>>>>> supported in general >>>>>>> >>>>>>> >>>>>>> >>>>>>> Is this feature fully tested by web-platform-tests >>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>> ? >>>>>>> >>>>>>> Yes: >>>>>>> https://wpt.fyi/results/credential-management/fedcm-same-site-none/fedcm-same-site-none.https.html?label=experimental&label=master&aligned >>>>>>> >>>>>>> >>>>>>> >>>>>>> Flag name on chrome://flags >>>>>>> >>>>>>> None >>>>>>> >>>>>>> >>>>>>> Finch feature name >>>>>>> >>>>>>> FedCmSameSiteNone >>>>>>> >>>>>>> >>>>>>> Requires code in //chrome? >>>>>>> >>>>>>> False (but FedCM in general does) >>>>>>> >>>>>>> >>>>>>> Tracking bug >>>>>>> >>>>>>> https://crbug.com/329145816 >>>>>>> >>>>>>> >>>>>>> Estimated milestones >>>>>>> >>>>>>> Shipping on desktop >>>>>>> >>>>>>> 125 if possible, otherwise 126 >>>>>>> >>>>>>> DevTrial on desktop >>>>>>> >>>>>>> 124 >>>>>>> >>>>>>> Shipping on Android >>>>>>> >>>>>>> 125 if possible, otherwise 126 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> Anticipated spec changes >>>>>>> >>>>>>> Open questions about a feature may be a source of future web compat >>>>>>> or interop issues. Please list open issues (e.g. links to known github >>>>>>> issues in the project for the feature specification) whose resolution >>>>>>> may >>>>>>> introduce web compat/interop risk (e.g., changing to naming or >>>>>>> structure of >>>>>>> the API in a non-backward-compatible way). >>>>>>> >>>>>>> None >>>>>>> >>>>>>> >>>>>>> Link to entry on the Chrome Platform Status >>>>>>> >>>>>>> https://chromestatus.com/feature/5092883024838656 >>>>>>> >>>>>>> >>>>>>> This intent message was generated by Chrome Platform Status >>>>>>> <https://chromestatus.com/>. >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "blink-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XGWV%3Dw4So1cgzyMonge2_3aSAHYUJuRnY98vHD%3DDDOZhg%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XGWV%3Dw4So1cgzyMonge2_3aSAHYUJuRnY98vHD%3DDDOZhg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "blink-dev" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to blink-dev+unsubscr...@chromium.org. >>>> >>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XFRwwWmpJHVP1Y%3Dh1vBP4WemS9b1DtEaR07uK%2Bfi9sEpg%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAPTJ0XFRwwWmpJHVP1Y%3Dh1vBP4WemS9b1DtEaR07uK%2Bfi9sEpg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSJ7OT1oD2BKAFBcpxr8A5%2BaArcr%3DF5q-oTHdBizC3cUNQ%40mail.gmail.com.
