Bounce tracking mitigations are now rolling out to 100% stable starting today (in cases where 3P cookies are blocked).
On Mon, Sep 25, 2023 at 11:00 AM Ben Kelly <wanderv...@chromium.org> wrote: > FYI, we are rolling out bounce tracking mitigations to stable 10% today. > (Again, this only impacts users who are blocking 3P cookies.) This > intermediate rollout step was added in order to investigate some > regressions that showed up in the 1% stable data. > > On Thu, Sep 7, 2023 at 12:29 PM Ben Kelly <wanderv...@chromium.org> wrote: > >> Thank you. >> >> FYI, bounce tracking mitigations are rolling out to stable 1% as of today. >> >> On Tue, Sep 5, 2023 at 12:09 PM Chris Harrelson <chris...@chromium.org> >> wrote: >> >>> LGTM3 >>> >>> On Tue, Sep 5, 2023 at 6:56 AM Ben Kelly <wanderv...@chromium.org> >>> wrote: >>> >>>> Ping for last LGTM or more feedback. We were hoping to be able to >>>> collect some stable data before TPAC, if possible. >>>> >>>> On Wed, Aug 30, 2023 at 8:45 AM Yoav Weiss <yoavwe...@chromium.org> >>>> wrote: >>>> >>>>> LGTM2 >>>>> >>>>> On Tue, Aug 29, 2023 at 5:44 PM Ben Kelly <wanderv...@chromium.org> >>>>> wrote: >>>>> >>>>>> On Tue, Aug 29, 2023 at 1:40 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> I agree that WPT infrastructure shouldn't be a blocker when we're >>>>>>> following other browsers. >>>>>>> >>>>>> >>>>>> Thank you. >>>>>> >>>>>> Have y'all tested the mitigation with commonly used >>>>>>> authentication/payment flows, to make sure it doesn't break them? >>>>>>> >>>>>> >>>>>> We have been dogfooding and not run into any issues with auth/payment >>>>>> flows. We are also collecting UKM metrics on sites deleted. I've sent >>>>>> you >>>>>> a private email with that information. >>>>>> >>>>>> The UKM is predominantly advertising, tracking, etc. There are a >>>>>> smattering of auth/ecommerce/etc, but at lower volumes. The auth issue >>>>>> we >>>>>> believe may be related to automatic login scenarios in enterprises (issue >>>>>> 36 <https://github.com/privacycg/nav-tracking-mitigations/issues/36>), >>>>>> which can be largely addressed with enterprise policies. We also >>>>>> integrated webauthn security key taps as interactions in M117 to reduce >>>>>> authentication false positives. >>>>>> >>>>>> Overall, however, we believe that since we only take action when 3P >>>>>> cookies are blocked, breakage should be limited. The 3P cookie default >>>>>> has >>>>>> not changed yet, so most users will not be affected. In addition, >>>>>> chromeguard, enterprise policies and other mechanisms can be used to add >>>>>> cookie exceptions which bounce tracking mitigations will honor. >>>>>> >>>>>> Ultimately, many sites will need to adapt to a new normal when the 3P >>>>>> cookie setting default changes. That will need to include that bounce >>>>>> tracking is not an acceptable replacement. We would like to ship bounce >>>>>> tracking mitigations gated on 3P cookie permissions so that when sites >>>>>> perform 3P cookie deprecation testing they see the new bounce tracking >>>>>> behavior as well. >>>>>> >>>>> >>>>> Thanks for outlining your motivations! Going ahead with this change >>>>> before the 3P cookie deprecation but 3P cookie blocking makes perfect >>>>> sense! >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> On Mon, Aug 28, 2023 at 11:08 PM Mike Taylor <miketa...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> LGTM1 to ship, as long as we fast follow with doing the work to >>>>>>>> define >>>>>>>> and ship webdriver extensions in order to make this testable in WPT. >>>>>>>> >>>>>>>> (I don't think your team should be blocked on shipping because >>>>>>>> other >>>>>>>> browsers who already shipped the feature didn't do that work.) >>>>>>>> >>>>>>>> On 8/21/23 3:44 PM, Christian Biesinger wrote: >>>>>>>> > On Mon, Aug 21, 2023 at 3:25 PM Ben Kelly < >>>>>>>> wanderv...@chromium.org> wrote: >>>>>>>> >> >>>>>>>> >> >>>>>>>> >> On Mon, Aug 21, 2023 at 11:38 AM Mike Taylor < >>>>>>>> miketa...@chromium.org> wrote: >>>>>>>> >>> On 8/21/23 11:09 AM, Ben Kelly wrote: >>>>>>>> >>> >>>>>>>> >>> On Sun, Aug 20, 2023 at 11:27 PM Yoav Weiss < >>>>>>>> yoavwe...@chromium.org> wrote: >>>>>>>> >>>> Thanks for working on this important problem! >>>>>>>> >>>> >>>>>>>> >>>> On Thu, Aug 17, 2023 at 9:28 PM Ben Kelly < >>>>>>>> wanderv...@chromium.org> wrote: >>>>>>>> >>>>> Sorry, it seems I left off the signals section of the >>>>>>>> template: >>>>>>>> >>>>> >>>>>>>> >>>>> Firefox: No signal ( >>>>>>>> https://github.com/mozilla/standards-positions/issues/835) >>>>>>>> >>>> >>>>>>>> >>>> Firefox folks seem tentatively supportive, but have WPT >>>>>>>> questions. Can you address them? >>>>>>>> >>> >>>>>>>> >>> I'm checking without our WPT folks to try to understand what >>>>>>>> mozilla is suggesting. I'm not familiar with web-driver functions at >>>>>>>> all, >>>>>>>> so not quite sure yet how feasible this is. >>>>>>>> >>> >>>>>>>> >>> My read on bvandersloot's comment is that he's asking for a >>>>>>>> less generic version >>>>>>>> https://github.com/web-platform-tests/wpt/issues/17489 to make >>>>>>>> this testable (which you've already linked below). Exposing endpoints >>>>>>>> for >>>>>>>> advancing time seems to have more use cases than bounce >>>>>>>> tracking-specific >>>>>>>> webdriver endpoints, IMHO - but that's a discussion that should >>>>>>>> probably >>>>>>>> happen in the relevant WG. >>>>>>>> >>> >>>>>>>> >>> See https://github.com/web-platform-tests/rfcs for the process >>>>>>>> to propose extending the testdriver.js API to expose... but I think >>>>>>>> you'll >>>>>>>> want to get the relevant concepts added to the webdriver spec first >>>>>>>> (seems >>>>>>>> possible, if Mozilla if supportive). The other option would be to >>>>>>>> something >>>>>>>> similar to FedCM by adding webdriver extension commands (see spec PR >>>>>>>> here: >>>>>>>> https://github.com/fedidcg/FedCM/pull/465/files). >>>>>>>> >>> >>>>>>>> >>> I personally wouldn't recommend blocking on this work, but it >>>>>>>> seems useful for someone to pursue as good first bugs for folks >>>>>>>> interested >>>>>>>> in standards and WPT internals. Note that additions to WebDriver now >>>>>>>> require going through the Intent process (great news for folks >>>>>>>> interested >>>>>>>> in learning this process, presumably they exist!). >>>>>>>> >> >>>>>>>> >> Andrew Williams also helpfully pointed out a bunch of code >>>>>>>> source references to me for this. I filed crbug.com/1474656 to do >>>>>>>> this work. >>>>>>>> >> >>>>>>>> >> I think this is definitely something we will do, but it may take >>>>>>>> a milestone or two to get it done. In particular, I'm unsure if there >>>>>>>> will >>>>>>>> be pushback to modifying the web-driver functions for a bounce tracking >>>>>>>> mitigations-specific feature. >>>>>>>> > Lots of specs define webdriver extensions, that should not be a >>>>>>>> problem. E.g.: >>>>>>>> > https://fedidcg.github.io/FedCM/#automation >>>>>>>> > >>>>>>>> https://w3c.github.io/secure-payment-confirmation/#sctn-automation >>>>>>>> > >>>>>>>> https://w3c.github.io/webauthn/#sctn-automation-virtual-authenticators >>>>>>>> > >>>>>>>> > Note that you have to implement the commands twice, once for >>>>>>>> Chrome's >>>>>>>> > bots and once for upstream wpt.fyi and general UA automation uses. >>>>>>>> > Chrome's impl does not really use webdriver, it usually just >>>>>>>> calls a >>>>>>>> > function on internals (e.g. >>>>>>>> > >>>>>>>> https://chromium-review.googlesource.com/c/chromium/src/+/4740672/6/third_party/blink/web_tests/resources/testdriver-vendor.js >>>>>>>> ) >>>>>>>> > >>>>>>>> > The second impl is in Chromedriver, likely using CDP, e.g.: >>>>>>>> > https://chromium-review.googlesource.com/c/chromium/src/+/4281897 >>>>>>>> > plus >>>>>>>> > https://chromium-review.googlesource.com/c/chromium/src/+/4402971 >>>>>>>> > >>>>>>>> > Christian >>>>>>>> > >>>>>>>> >> I don't think we want to take on the general purpose clock >>>>>>>> modification change to web-driver, though. That seems like a much >>>>>>>> larger >>>>>>>> scope. >>>>>>>> >> >>>>>>>> >>> >>>>>>>> >>>> >>>>>>>> >>>>> Webkit: No signal ( >>>>>>>> https://github.com/WebKit/standards-positions/issues/214) >>>>>>>> >>>>> Web developers: No signals >>>>>>>> >>>>> >>>>>>>> >>>>> On Thu, Aug 17, 2023 at 10:22 AM Ben Kelly < >>>>>>>> wanderv...@chromium.org> wrote: >>>>>>>> >>>>>> Contact emails >>>>>>>> >>>>>> >>>>>>>> >>>>>> wanderv...@chromium.org, b...@chromium.org, >>>>>>>> rtarp...@chromium.org, j...@chromium.org >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Explainer >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> https://github.com/privacycg/nav-tracking-mitigations/blob/main/bounce-tracking-explainer.md >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Specification >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Summary >>>>>>>> >>>>>> >>>>>>>> >>>>>> This feature mitigates bounce tracking on the web. It works >>>>>>>> by deleting state from sites that access storage during a redirect >>>>>>>> that the >>>>>>>> user has never directly interacted with. See the specification for >>>>>>>> more >>>>>>>> details. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Blink component >>>>>>>> >>>>>> >>>>>>>> >>>>>> Privacy>NavTracking >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> TAG review >>>>>>>> >>>>>> >>>>>>>> >>>>>> https://github.com/w3ctag/design-reviews/issues/862 >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> TAG review status >>>>>>>> >>>>>> >>>>>>>> >>>>>> Issues addressed >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Risks >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Interoperability and Compatibility >>>>>>>> >>>>>> >>>>>>>> >>>>>> The main risk is that we will incorrectly delete state for a >>>>>>>> site that the user needs to continue functioning. Our approach >>>>>>>> attempts to >>>>>>>> address this with a number of signals: >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> If a user has interacted with the site within the last 45 >>>>>>>> days, we will not delete its state. >>>>>>>> >>>>>> >>>>>>>> >>>>>> We are adding successful webauthn key assertions as another >>>>>>>> "interaction" source in M117 to address SSO use cases that only require >>>>>>>> security taps to stay logged in. >>>>>>>> >>>>>> >>>>>>>> >>>>>> We only delete state if the potential tracking site is not >>>>>>>> permitted as a 3P cookie. This allows users and enterprises to grant >>>>>>>> permission to maintain state on these sites through existing >>>>>>>> mechanisms. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> We have documented some known use cases at-risk. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> In particular, since 3P cookies are default allowed today, >>>>>>>> this feature will only have an immediate impact on users that have >>>>>>>> opted >>>>>>>> into 3P cookie blocking or incognito where 3P cookies are blocked by >>>>>>>> default. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Ergonomics >>>>>>>> >>>>>> >>>>>>>> >>>>>> Minimal ergonomic risk. There are no direct APIs to call >>>>>>>> here. We are deleting state for sites behind the scenes. We do not >>>>>>>> delete >>>>>>>> state for sites that are currently open. We have devtools >>>>>>>> enhancements to >>>>>>>> help developers understand the process. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Activation >>>>>>>> >>>>>> >>>>>>>> >>>>>> No activation risk. There is nothing to polyfill. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Security >>>>>>>> >>>>>> >>>>>>>> >>>>>> This feature does incrementally worsen existing XS-Leaks in >>>>>>>> the browser by exposing an additional bit of information. Attackers >>>>>>>> can >>>>>>>> learn if a user has interacted with a site within the last 45 days if >>>>>>>> they >>>>>>>> are able to trigger a stateful bounce on the target site and execute a >>>>>>>> XS-Leak attack to detect the existence of cookies or state on the site. >>>>>>>> Since bounce tracking mitigations are only enforced when 3P cookies are >>>>>>>> blocked, however, the XS-Leak must use navigations and not subresource >>>>>>>> attacks. >>>>>>>> >>>> >>>>>>>> >>>> Does that mean that any exposed navigation bounce on a >>>>>>>> sensitive site becomes a history leak? Or do other conditions apply >>>>>>>> that >>>>>>>> would make this a rare occurrence? >>>>>>>> >>>> If it's the former, how do other browsers' mitigation >>>>>>>> techniques deal with this? >>>>>>>> >>> >>>>>>>> >>> I don't think it's equivalent to a full history leak on its >>>>>>>> own. In order to get the extra leaked bit of "was interacted with in >>>>>>>> the >>>>>>>> last 45 days", the site must already have a XS-leak allowing an >>>>>>>> attacker to >>>>>>>> detect the existence of cookies or state on the site. Typically >>>>>>>> cookies or >>>>>>>> state are already going to indicate some user activity (interaction). >>>>>>>> So >>>>>>>> the additional bit, while strictly a worsening of the situation, is >>>>>>>> relatively minor compared to what is available from the prerequisite >>>>>>>> attack. >>>>>>>> >>> >>>>>>>> >>> Again, we'd like to work on closing the underlying XS-leak that >>>>>>>> allows attackers to detect cookies/state in the future. Fixing forward >>>>>>>> here is preferable since trying to fix just the interaction bit in >>>>>>>> bounce >>>>>>>> tracking mitigations itself would likely force the introduction of some >>>>>>>> kind of allow/block list which has larger negative impacts (as >>>>>>>> discussed in >>>>>>>> the explainer alternatives). >>>>>>>> >>> >>>>>>>> >>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> We feel the best solution to this problem is to invest in >>>>>>>> fixing navigation-based XS-Leaks. The additional bit of interaction >>>>>>>> information leaked in the meantime is not ideal, but it has limited >>>>>>>> utility >>>>>>>> if an attacker can already tell if there is state on the target site. >>>>>>>> We >>>>>>>> are interested in collaborating with the security team to help address >>>>>>>> the >>>>>>>> underlying XS-Leak. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> WebView application risks >>>>>>>> >>>>>> >>>>>>>> >>>>>> We are purposely excluding WebView from this launch so we >>>>>>>> can evaluate impact to that platform separately. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Debuggability >>>>>>>> >>>>>> >>>>>>>> >>>>>> We issue devtool "issues" when a site may potentially be >>>>>>>> deleted as a bounce tracking. In addition, we have a devtools >>>>>>>> application >>>>>>>> panel to force the bounce tracking algorithm to run immediately. See >>>>>>>> the >>>>>>>> screenshots in this blog post. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Will this feature be supported on all six Blink platforms >>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>> >>>>>> >>>>>>>> >>>>>> All except WebView. We would like to evaluate the impact to >>>>>>>> WebView in a separate launch. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Is this feature fully tested by web-platform-tests? >>>>>>>> >>>>>> >>>>>>>> >>>>>> No, unfortunately. Since this feature runs off of a long >>>>>>>> duration timer we cannot construct a WPT test case. We need wpt#17489 >>>>>>>> to >>>>>>>> be fixed in order to correct this. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Flag name >>>>>>>> >>>>>> >>>>>>>> >>>>>> DIPS >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Requires code in //chrome? >>>>>>>> >>>>>> >>>>>>>> >>>>>> Yes. We must integrate with features like the chrome >>>>>>>> sign-in manager, TabHelper, etc. We are, however, actively working to >>>>>>>> move >>>>>>>> other code into the content// layer. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Tracking bug >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1360489 >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Measurement >>>>>>>> >>>>>> >>>>>>>> >>>>>> We are measuring UKM for sites that have state deleted by >>>>>>>> bounce tracking mitigations. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Availability expectation >>>>>>>> >>>>>> >>>>>>>> >>>>>> Our initial MVP implementation is launching to all platforms >>>>>>>> with the exception of WebView. In addition, bounce tracking >>>>>>>> mitigations >>>>>>>> are only enforced in situations where the tracking domain is not >>>>>>>> permitted >>>>>>>> as a 3P cookie. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Adoption expectation >>>>>>>> >>>>>> >>>>>>>> >>>>>> There is no specific API to adopt for this effort, but we >>>>>>>> only enforce the bounce tracking mitigations when 3P cookies are >>>>>>>> blocked. >>>>>>>> Therefore we expect it to have a greater impact as 3P cookie blocking >>>>>>>> becomes more common in the future. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Adoption plan >>>>>>>> >>>>>> >>>>>>>> >>>>>> N/A >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Non-OSS dependencies >>>>>>>> >>>>>> >>>>>>>> >>>>>> None >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Sample links >>>>>>>> >>>>>> >>>>>>>> >>>>>> https://bounce-tracking-demo.glitch.me/ >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Estimated milestones >>>>>>>> >>>>>> >>>>>>>> >>>>>> Gradual rollout during M116. Webauthn interaction support >>>>>>>> will take effect in M117. >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Anticipated spec changes >>>>>>>> >>>>>> >>>>>>>> >>>>>> We have written a monkey-patch spec here: >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> https://privacycg.github.io/nav-tracking-mitigations/#bounce-tracking-mitigations >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Link to entry on the Chrome Platform Status >>>>>>>> >>>>>> >>>>>>>> >>>>>> https://chromestatus.com/feature/5705149616488448 >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>>> Links to previous Intent discussions >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMi_7z0-yeTbBiE43V5SD1ri4jSVxrkR8Gs%3DD0NRoRKivA%40mail.gmail.com >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/vyXWn1W1daA/m/tL3f1_WbAwAJ >>>>>>>> >>>>>> >>>>>>>> >>>>>> >>>>>>>> >>>>> -- >>>>>>>> >>>>> 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/CAK7rkMi2xOMKfZsV5q9jgBuaFvRC3b67fsw%3DYF%2BLNDRgp%2BjdrA%40mail.gmail.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/CAK7rkMgTO8-OStci%3DDgu-xeNZJKgOnf17i15wkXintg2wod2Ag%40mail.gmail.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/CAK7rkMiXRs97mKph1BayrWAknP-1dfdCOTPHq%2B7xRBnSN%2BxU9g%40mail.gmail.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/CAK7rkMh5YYoSgos29560-ZasdpiPQTZSPzAPcTL83XGeHvNy5Q%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK7rkMh5YYoSgos29560-ZasdpiPQTZSPzAPcTL83XGeHvNy5Q%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/CAK7rkMhp-FWDKB0Sa%2BOUkfBWuHh5oXUzV6y8ugFW5vaisf3_MQ%40mail.gmail.com.
