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 <[email protected]> wrote: > LGTM2 > > On Wed, Oct 12, 2022 at 9:02 AM Daniel Bratell <[email protected]> > 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 <[email protected]> wrote: >> >>> >>> >>> On Wed, Oct 5, 2022 at 1:25 AM Yoav Weiss <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Tue, Oct 4, 2022 at 4:13 AM Rick Byers <[email protected]> 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 <[email protected]> wrote: >>>>> >>>>>> Contact emails >>>>>> >>>>>> [email protected] >>>>>> >>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>>> 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 [email protected]. >>> 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 [email protected]. >> 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 [email protected]. >> 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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfWVUTmD7j9CND-PLFgpc-y7d8Tq61B9vzPZAp4E0_uFLA%40mail.gmail.com.
