Hi everyone, The Microsoft Edge team was recently queried by an IDP about Microsoft Edge's support status for FedCM. We are also shipping it and will continue to support it.
If you're an RP or IDP building support for Chrome, you should assume that your scenario will work equally well in Microsoft Edge. If you run into issues specific to Microsoft Edge, we will investigate and resolve them. Thanks, Erik p.s. Sorry for reviving an otherwise long-dormant thread; with so many other intents for additions to the API this one made the most sense to provide a general statement about our shipping status. On Thursday, October 13, 2022 at 11:18:05 AM UTC-7 Sam Goto wrote: > Thanks you all for the thoughtful and timely review, and we'll follow up > on the action items here separately! > > Sam > > On Wed, Oct 12, 2022 at 9:42 AM Yoav Weiss <yoav...@chromium.org> wrote: > >> LGTM3 >> >> The risk/benefit tradeoff here seems reasonable. Thanks for continuing to >> work with the community on finding the ideal shape of the solution here. >> Please recommend IDPs to take anti-self-hosting means to prevent making >> future changes to this harder than they should be. >> >> >> On Wed, Oct 12, 2022 at 6:16 PM Chris Harrelson <chri...@chromium.org> >> wrote: >> >>> LGTM2 >>> >>> On Wed, Oct 12, 2022 at 9:02 AM Daniel Bratell <brat...@gmail.com> >>> wrote: >>> >>>> LGTM1 >>>> >>>> (I appreciate that there are some unique risks here, but I'm confident >>>> the team will be able to navigate those) >>>> >>>> /Daniel >>>> On 2022-10-11 23:13, 'Ilya Grigorik' via blink-dev wrote: >>>> >>>> At Shopify, we've followed progress closely, and I'm really excited to >>>> see the i2s! >>>> >>>> Agree with the analysis tradeoffs and proposed rollout. This is a >>>> capability we're keenly interested in and would be willing to stay >>>> hands-on >>>> with as it evolves. >>>> >>>> On Wed, Oct 5, 2022 at 1:54 PM Sam Goto <go...@chromium.org> wrote: >>>> >>>>> >>>>> >>>>> On Wed, Oct 5, 2022 at 1:25 AM Yoav Weiss <yoav...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Tue, Oct 4, 2022 at 4:13 AM Rick Byers <rby...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> I've been involved somewhat with this work and so I'm recusing >>>>>>> myself from my API owner role for this intent. >>>>>>> >>>>>>> Nevertheless I wanted to chime in and say that I agree with the risk >>>>>>> tradeoff the team is proposing we make here. Yes there's still a lot to >>>>>>> figure out in the federated identity space, and it's likely that we'll >>>>>>> find >>>>>>> places where we need to make some breaking changes to better meet >>>>>>> customer >>>>>>> needs and get to interoperability. But I believe shipping what we have >>>>>>> now >>>>>>> as a V0 is the most effective way to figure out the path forward in a >>>>>>> timeframe that's compatible with Chrome's plans for 3P cookie >>>>>>> deprecation. >>>>>>> We've been evolving designs in public for >2 years and now we have at >>>>>>> least >>>>>>> one partner who is ready to scale up beyond OT limits, and we'd both >>>>>>> learn >>>>>>> a lot from doing so. It would be a mistake to think that we just have a >>>>>>> few >>>>>>> open issues to resolve before we could call the design "mature", and I >>>>>>> don't want to risk losing momentum with customers by suggesting we >>>>>>> should >>>>>>> just stick to "experiments" for another 6-12 months. Instead the >>>>>>> process of >>>>>>> becoming mature in the context of a dynamic identity provider ecosystem >>>>>>> and >>>>>>> evolving privacy landscape will be best served by a "launch and >>>>>>> iterate" >>>>>>> approach. Doing this responsibly requires a commitment on our part to >>>>>>> engage with the standards community in good faith to avoid past failure >>>>>>> modes where V0 (chromium-only) and V1 (standard) APIs have co-existed >>>>>>> in >>>>>>> chromium for an extended period of time while Google services in >>>>>>> particular >>>>>>> have retained a dependency on the V0 behavior. >>>>>>> >>>>>>> The partnership and ecosystem dynamics here remind me a lot of what >>>>>>> we encountered with PaymentRequest. We still don't have payment APIs >>>>>>> "figured out", but we've been able to learn and iterate >>>>>>> <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#> >>>>>>> >>>>>>> by working with a handful of partners through the web payments working >>>>>>> group to evolve fully launched APIs, including making significant >>>>>>> breaking >>>>>>> changes along the way (despite my own initial skepticism of the >>>>>>> practicality of that). >>>>>>> >>>>>>> Rick >>>>>>> >>>>>>> >>>>>>> On Mon, Oct 3, 2022 at 6:31 PM Sam Goto <go...@chromium.org> wrote: >>>>>>> >>>>>>>> Contact emails >>>>>>>> >>>>>>>> go...@chromium.org >>>>>>>> >>>>>>>> Explainer >>>>>>>> >>>>>>>> https://github.com/fedidcg/FedCM/blob/main/explainer.md >>>>>>>> >>>>>>>> Specification >>>>>>>> >>>>>>>> https://fedidcg.github.io/FedCM >>>>>>>> >>>>>>>> Summary >>>>>>>> >>>>>>>> The Federated Credential Management API (originally WebID >>>>>>>> <https://github.com/fedidcg/FedCM/issues/41#issuecomment-712304910>) >>>>>>>> allows users to use their federated identity to login to websites in a >>>>>>>> manner compatible with improvements to browser privacy. This intent >>>>>>>> covers >>>>>>>> a Web Platform API to prompt the user to choose accounts from one >>>>>>>> Identity >>>>>>>> Provider to sign-up or sign-in to a website. We expect to send future >>>>>>>> intents to make enhancements over these capabilities (e.g. multiple >>>>>>>> IdPs <https://github.com/fedidcg/FedCM/issues/319>) and keep >>>>>>>> raising the privacy properties of the API (e.g. the timing attack >>>>>>>> <https://github.com/fedidcg/FedCM/issues/230#issuecomment-1089040953> >>>>>>>> problem). >>>>>>>> >>>>>>>> >>>>>>>> Blink component >>>>>>>> >>>>>>>> Blink>Identity>FedCM >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EFedCM> >>>>>>>> >>>>>>>> TAG review >>>>>>>> >>>>>>>> Early Tag Review >>>>>>>> https://github.com/w3ctag/design-reviews/issues/622 >>>>>>>> >>>>>>>> Spec Tag Review https://github.com/w3ctag/design-reviews/issues/718 >>>>>>>> >>>>>>>> TAG review status >>>>>>>> >>>>>>>> Positive >>>>>>>> <https://github.com/w3ctag/design-reviews/issues/718#issuecomment-1187725216> >>>>>>>> >>>>>>>> Risks >>>>>>>> Interoperability and Compatibility >>>>>>>> >>>>>>>> Zero compatibility risk (new API) >>>>>>>> >>>>>>>> Gecko: Positive >>>>>>>> <https://github.com/mozilla/standards-positions/issues/618#issuecomment-1221964677> >>>>>>>> >>>>>>>> WebKit: Positive >>>>>>>> <https://lists.webkit.org/pipermail/webkit-dev/2022-March/032162.html> >>>>>>>> >>>>>>>> On interoperability and forward compatibility: FedCM is large and >>>>>>>> complex and, as browser vendors start to implement it (example >>>>>>>> <https://bugzilla.mozilla.org/show_bug.cgi?id=1782066>), we are >>>>>>>> seeing positive and constructive engagement. For example, we are >>>>>>>> actively >>>>>>>> working with Mozilla to find an interoperable way to address the >>>>>>>> timing attack problem >>>>>>>> <https://github.com/fedidcg/FedCM/issues/230#issuecomment-1089040953>, >>>>>>>> support multiple IdPs <https://github.com/fedidcg/FedCM/issues/319> >>>>>>>> and protect endpoints <https://github.com/fedidcg/FedCM/issues/320>. >>>>>>>> Because of that, there is a risk of incompatible changes going forward >>>>>>>> (list of currently known potential risks here >>>>>>>> <https://github.com/fedidcg/FedCM/labels/compatibility%20risk>), >>>>>>>> mostly affecting IdPs (see section below on activation). We think it >>>>>>>> is >>>>>>>> unavoidable that parts of our current design are suboptimal and are >>>>>>>> going >>>>>>>> to need to be revisited, but the biggest risk we are trying to avoid >>>>>>>> is to >>>>>>>> fail to bring IdPs along with us, increase their production footprint >>>>>>>> that >>>>>>>> we can learn from, and increase our confidence on technical >>>>>>>> feasibility and >>>>>>>> product-market fit. >>>>>>>> >>>>>>>> Based on our origin trials, we expect a small number of IdPs (say, >>>>>>>> less than ~30) to be incentivized to use the API in production until >>>>>>>> chrome phases-out third party cookies in 2024 >>>>>>>> <https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline>. >>>>>>>> >>>>>>>> These IdPs that we are partnering with need time, confidence, and >>>>>>>> stability >>>>>>>> to increase their deployment. For example, in origin trials, we ran >>>>>>>> into CSP >>>>>>>> issues >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1320724> >>>>>>>> and cross-origin iframe issues >>>>>>>> <https://bugs.chromium.org/p/chromium/issues/detail?id=1322320> >>>>>>>> that we could have never anticipated without IdPs experimentation, >>>>>>>> even if >>>>>>>> we had interoperable implementations in all major browsers. We think >>>>>>>> that >>>>>>>> the risk we take by not having a baseline that IdPs can work from if >>>>>>>> the >>>>>>>> API isn’t shipped outweighs the forward compatibility risks: not >>>>>>>> shipping >>>>>>>> would mean that we won’t learn about these bugs until it is too close >>>>>>>> to >>>>>>>> the deprecation of third party cookie (e.g. IdPs will continue to >>>>>>>> evolve >>>>>>>> their products using iframes and third party cookies without an >>>>>>>> alternative >>>>>>>> to build on). We also think that we can address some concerns on >>>>>>>> forward >>>>>>>> compatibility by setting the right expectations during developer >>>>>>>> documentation / outreach to IdPs as we make it battle-tested before we >>>>>>>> deprecate third party cookies in 2024 >>>>>>>> <https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline> >>>>>>>> . >>>>>>>> >>>>>>>> Web developers: We’ve been working with Identity Providers and >>>>>>>> Relying Parties over the last ~3 years, going over a good amount of >>>>>>>> design >>>>>>>> alternatives and prototypes (TPAC 2020 >>>>>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2020/The%20Web%20Platform%2C%20Privacy%20and%20Federation%20-%20TPAC.pdf>, >>>>>>>> >>>>>>>> 2021 >>>>>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2021/FedCM%20%40%20TPAC%202021%20(1).pdf> >>>>>>>> >>>>>>>> and 2022 >>>>>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM%20%40%20TPAC.pdf>, >>>>>>>> >>>>>>>> BlinkOn 14 >>>>>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2021/WebID%20-%20BlinkOn%2014.pdf>, >>>>>>>> >>>>>>>> 15 >>>>>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2021/BlinkOn%2015%20--%20FedCM.pdf>, >>>>>>>> >>>>>>>> 16 >>>>>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2022/FedCM%20BlinkOn%2016.pdf>, >>>>>>>> >>>>>>>> OIDF 2020 >>>>>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2020/Browsers%20and%20Federation%20-%20OpenID.pdf>, >>>>>>>> >>>>>>>> IIW 2020 >>>>>>>> <https://github.com/fedidcg/FedCM/blob/main/meetings/2020/The%20Web%20Platform%2C%20Privacy%20and%20Federation%20-%20IIW.pdf>), >>>>>>>> >>>>>>>> trying to strike the right balance between privacy/security properties >>>>>>>> and >>>>>>>> deployment structures (e.g. backwards compatibility). The current >>>>>>>> formulation is the result of identity providers, relying parties, >>>>>>>> browser >>>>>>>> vendors and industry experts that have co-designed with us through our >>>>>>>> devtrials and gathered production experience with their users through >>>>>>>> our >>>>>>>> origin trials (around ~33 small and big registered IdPs). For example, >>>>>>>> in >>>>>>>> the last two quarters, the Google Sign-in team has run experiments >>>>>>>> with ~20 >>>>>>>> Relying Parties leading to more than ~300K real users logging-in in >>>>>>>> production, achieving comparable sign-in/up conversion rates without >>>>>>>> depending on third party cookies. While this is a small sample size of >>>>>>>> the >>>>>>>> ecosystem and the deployment (notably missing representation of >>>>>>>> enterprises >>>>>>>> and EDU), we are encouraged by the approach and confident this is a >>>>>>>> solid >>>>>>>> and necessary first step. >>>>>>>> >>>>>>>> Other signals: This API is being developed within the FedID CG >>>>>>>> <https://github.com/fedidcg> composed of identity providers, >>>>>>>> relying parties, browser vendors and industry experts. The CG has >>>>>>>> produced >>>>>>>> an enumeration of known issues >>>>>>>> <https://github.com/fedidcg/use-case-library/wiki/Primitives-by-Use-Case> >>>>>>>> >>>>>>>> in the absence of third party cookies, a list of mitigation >>>>>>>> alternatives >>>>>>>> <https://github.com/fedidcg/use-case-library/wiki/Third-party-cookie-mitigations> >>>>>>>> >>>>>>>> and is actively working on how to decide >>>>>>>> <https://github.com/fedidcg/use-case-library/wiki/User-Flow-Decision-Trees> >>>>>>>> >>>>>>>> which Web Platform API to use for each circumstance. We don’t expect >>>>>>>> (or >>>>>>>> are designing for) FedCM to be used exclusively to solve all of the >>>>>>>> known >>>>>>>> issues, but rather in coordination with other browser proposals (e.g. >>>>>>>> CHIPS). We acknowledge that there is a series of anticipated breakages >>>>>>>> that >>>>>>>> are not handled (effectively) by any proposal (FedCM included) at the >>>>>>>> moment, and we are excited to continue working with the FedID CG, the >>>>>>>> Privacy CG <https://www.w3.org/groups/cg/privacycg> and the Privacy >>>>>>>> Sandbox <https://privacysandbox.com/> to extend FedCM in whichever >>>>>>>> way is constructive and/or work on new proposals. >>>>>>>> >>>>>>>> Activation >>>>>>>> >>>>>>>> Our design assumes that it is exponentially harder, in this order, >>>>>>>> to make changes to (a) user behavior than, (b) websites, (c) identity >>>>>>>> providers and then, lastly, (d) browsers. >>>>>>>> >>>>>>> >>>>>> I agree with this ordering. >>>>>> It'd be good to be transparent with adopting identity providers about >>>>>> the potential compat risk, so that they'd know what they are signing up >>>>>> for. >>>>>> >>>>>> On top of that, there's some risk of the *compat issues leaking* >>>>>> from identity providers to websites, if those websites self-host the IDP >>>>>> SDKs (for performance or other reasons). >>>>>> Would it be possible to ask identity providers to take measures >>>>>> against self-hosting? e.g. I think `document.currentScript.src` can help >>>>>> them enforce the script coming from an updatable source. >>>>>> >>>>> >>>>> >>>>> I really like the `document.currentScript.src` suggestion, and I think >>>>> that’s a great way to help us control future breakages! >>>>> >>>>> As you suggested, there is a lot that we can do by working with the >>>>> Developer Relations (devrel) and Business Development (BD) teams to set >>>>> up >>>>> the right expectations as this goes out. Here are a few examples that we >>>>> think could work: >>>>> >>>>> >>>>> - >>>>> >>>>> Set up a communication channel (e.g. a mailing list similar to the >>>>> one we have for Core Web Vitals here >>>>> <https://groups.google.com/a/chromium.org/g/speed-metrics-announce> >>>>> and here >>>>> <https://mobile.twitter.com/NicPenaM/status/1427712030455259142>) >>>>> that IdPs can subscribe to coordinate with us (in addition to direct >>>>> 1:1 >>>>> partnerships) >>>>> - >>>>> >>>>> Be transparent about the moving parts (e.g. the timing attack >>>>> problem >>>>> <https://github.com/fedidcg/FedCM/issues/230#issuecomment-1089040953>, >>>>> the multi-IdPs <https://github.com/fedidcg/FedCM/issues/319> API, >>>>> etc), and a rough timeline to resolve them (e.g. we could use the >>>>> Privacy >>>>> Sandbox Timeline >>>>> >>>>> <https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline> >>>>> >>>>> and have meaningful stability checkpoints at General Availability in >>>>> 2023 >>>>> >>>>> <https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline> >>>>> >>>>> and Phase-out in 2024 >>>>> >>>>> <https://privacysandbox.com/intl/en_us/open-web/#the-privacy-sandbox-timeline> >>>>> ). >>>>> - >>>>> >>>>> Make a recommendation to IdPs to control their SDKs (e.g. either >>>>> through document.currentScript.src or SLAs), at least until some >>>>> moving >>>>> parts settle, so that we can iterate quickly as an industry. It is >>>>> ultimately a business decision that IdPs make, so we can only go as >>>>> far as >>>>> making a recommendation. >>>>> >>>>> >>>>> Just a few more data points: >>>>> >>>>> >>>>> - >>>>> >>>>> We expect it is going to take us more than a quarter but less than >>>>> a year to resolve the known moving parts with confidence. Also, >>>>> importantly, they may or may not require backwards incompatible API >>>>> changes. >>>>> - >>>>> >>>>> To give you a sense of numbers, in origin trials, ~33 IdPs >>>>> registered over the last ~7 months. There are few IdPs (that have the >>>>> incentives to use the API at the moment, while 3P cookies are still >>>>> around) >>>>> and they are large and sophisticated developers >>>>> - >>>>> >>>>> In our experience so far, very few websites choose to self-host >>>>> (in origin trials, we found only 1), and the ones that do, are >>>>> extremely >>>>> large and sophisticated developers that can afford to self-host (i.e. >>>>> we >>>>> would know how to reach out to them individually) >>>>> - >>>>> >>>>> Outside of real-world production IdP deployment, it is possible, >>>>> though, that we are going to find developers playing with the API, >>>>> writing >>>>> blogs or demos, and that’s more likely to break (because we wouldn’t >>>>> be >>>>> able to reach out to them individually), but that’s a more acceptable >>>>> breakage. >>>>> >>>>> >>>>> >>>>>> >>>>>> >>>>>>>> So, the design pulls as much as possible the burden of change to >>>>>>>> browsers vendors and identity providers, and goes to a great extent to >>>>>>>> require little to no changes to websites and user's norms, while at >>>>>>>> the >>>>>>>> same time, raising the privacy properties of the system. >>>>>>>> >>>>>>>> While that’s not always possible, we believe we found an activation >>>>>>>> structure that could work at scale for a substantial part of the >>>>>>>> deployment >>>>>>>> (especially for consumers) through JS SDKs that are provided by >>>>>>>> Identity >>>>>>>> Providers and get dynamically embedded into relying parties. >>>>>>>> >>>>>>>> For example, through their JS SDKs, the Google Sign-in team was >>>>>>>> able to replace their dependence on third party cookies with FedCM >>>>>>>> without >>>>>>>> requiring changes to relying parties. >>>>>>>> >>>>>>>> We acknowledge that this activation model is insufficient for a lot >>>>>>>> of the deployment (especially for enterprises), so finding alternative >>>>>>>> activation structures is an active area of investigation. >>>>>>>> >>>>>>>> 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? >>>>>>>> >>>>>>>> This API does not deprecate or change behavior of existing APIs. >>>>>>>> >>>>>>>> >>>>>>>> Debuggability >>>>>>>> >>>>>>>> Basic devtools integration supported. We plan to extend this >>>>>>>> support as the product matures and we learn from developers what >>>>>>>> challenges >>>>>>>> they run into. >>>>>>>> >>>>>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>>>>> Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>> >>>>>>>> No >>>>>>>> >>>>>>>> The current implementation is available on all platforms (Windows, >>>>>>>> Mac, Linux, ChromeOS and Android) except WebView. >>>>>>>> >>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>> ? >>>>>>>> >>>>>>>> Yes, fedcm-* tests in this directory >>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/credential-management/> >>>>>>>> . >>>>>>>> >>>>>>>> Known issue: some of our WPT tests are failing >>>>>>>> <https://wpt.fyi/results/credential-management?label=experimental&label=master&aligned&view=subtest> >>>>>>>> >>>>>>>> on wpt.fyi. While the tests exist and pass in Chromium’s >>>>>>>> infrastructure, >>>>>>>> they rely on a Chrome-specific flag that would not work in other >>>>>>>> browsers. >>>>>>>> Making them work on upstream WPT requires PAC support; however, WPT’s >>>>>>>> PAC >>>>>>>> support does not currently support HTTPS tests, which FedCM requires >>>>>>>> because it is only exposed to secure contexts. We are working on >>>>>>>> adding >>>>>>>> that support, which is in progress here >>>>>>>> <https://github.com/web-platform-tests/wpt/pull/35276>. >>>>>>>> >>>>>>>> Origin Trial Instructions >>>>>>>> >>>>>>>> https://developer.chrome.com/blog/fedcm-origin-trial/ >>>>>>>> >>>>>>>> Flag name >>>>>>>> >>>>>>>> fedcm >>>>>>>> >>>>>>>> Requires code in //chrome? >>>>>>>> >>>>>>>> True >>>>>>>> >>>>>>>> Tracking bug >>>>>>>> >>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1353814 >>>>>>>> >>>>>>>> Launch bug >>>>>>>> >>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1321238 >>>>>>>> >>>>>>>> Measurement >>>>>>>> >>>>>>>> kFederatedCredentialManagement >>>>>>>> >>>>>>>> Estimated milestones >>>>>>>> >>>>>>>> OriginTrial desktop last >>>>>>>> >>>>>>>> 107 >>>>>>>> >>>>>>>> OriginTrial desktop first >>>>>>>> >>>>>>>> 103 >>>>>>>> >>>>>>>> OriginTrial Android last >>>>>>>> >>>>>>>> 107 >>>>>>>> >>>>>>>> OriginTrial Android first >>>>>>>> >>>>>>>> 101 >>>>>>>> >>>>>>>> DevTrial on Android >>>>>>>> >>>>>>>> 98 >>>>>>>> >>>>>>>> >>>>>>>> Anticipated spec changes >>>>>>>> >>>>>>>> We’re also currently resolving some questions >>>>>>>> <https://github.com/fedidcg/FedCM/issues/320> related to Fetch >>>>>>>> integration. >>>>>>>> >>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>> >>>>>>>> https://chromestatus.com/feature/6438627087220736 >>>>>>>> >>>>>>>> Links to previous Intent discussions >>>>>>>> >>>>>>>> - >>>>>>>> >>>>>>>> Intent to Prototype >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/2B4TJ7j2U4M/m/1X5T3OszCAAJ> >>>>>>>> >>>>>>>> - >>>>>>>> >>>>>>>> Ready for Trial >>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/jlV_1m7uUAg> >>>>>>>> - >>>>>>>> >>>>>>>> Intent to Experiment >>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/kws-gltC5us> >>>>>>>> - >>>>>>>> >>>>>>>> Intent to Extend Experiment >>>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/Juc7ix6UI24> >>>>>>>> >>>>>>>> >>>>>>>> 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+...@chromium.org. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-yf1BMQ4ZtMYH9cCQsecroEE3ZPOKgY8LU%3DNX3zAfbwYA%40mail.gmail.com >>>>>>>> >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-yf1BMQ4ZtMYH9cCQsecroEE3ZPOKgY8LU%3DNX3zAfbwYA%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+...@chromium.org. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY92OzzAAJkqpe11G9rW_7SNVo_qTYsu5OLd2mKZ%3DS3EOg%40mail.gmail.com >>>>>>> >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY92OzzAAJkqpe11G9rW_7SNVo_qTYsu5OLd2mKZ%3DS3EOg%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+...@chromium.org. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-wJNZAN_dBpfe60b9_iOseVPXypo%3DAvWwpD60W3coiXyg%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALdEk-wJNZAN_dBpfe60b9_iOseVPXypo%3DAvWwpD60W3coiXyg%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+...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABd3A800vm_-kX0inH4170iK1gs%3DT0w4da2P4kRe%2BYioTy5iTw%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABd3A800vm_-kX0inH4170iK1gs%3DT0w4da2P4kRe%2BYioTy5iTw%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+...@chromium.org. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4142e39-98ff-dc8d-43ee-56efc24ce3b1%40gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/e4142e39-98ff-dc8d-43ee-56efc24ce3b1%40gmail.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/2ad268f9-a425-4a95-a8a5-066fc177940dn%40chromium.org.
