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 <[email protected]> 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 <[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/CALdEk-yU%3DZDmhazA6ZE9i3XNEHxUeR21JC8yGtDRWsp7F-dx7w%40mail.gmail.com.
