Thanks Zainab! My concerns were indeed addressed: * On the interop front, the team showed willingness to collaborate with other browsers/engines on a more accurate, but not-necessarily-public list. * My concerns regarding the appeal process were addressed by the team's willingness to revise the process and potentially not require platform providers to be in the loop when appeals are made by 3rd parties RE resources that are hosted on their CDNs. I suspect that would make it significantly more feasible.
So from my perspective, this intent can be unblocked (and I believe it has the 3 required LGTMs). On Fri, Jul 25, 2025 at 6:57 PM Zainab Rizvi <riz...@google.com> wrote: > Some of the team met with Yoav to discuss his concerns, primarily those > around list interop and inquiries/appeals coming from 3rd party scripts > hosted on CDNs. > > For those interested in list interop, we plan to propose a breakout > session at TPAC on the topic, and look forward to collaborating with other > vendors and interested folks (feel free to reach out to us directly before > TPAC). > > We also discussed revising our appeals and inquiries process to allow > owners of third-party assets to confirm a list of affected resources hosted > on a CDN directly from Disconnect. This way CDN providers need not be > involved in the process as intermediaries. > > We further discussed how blocked resources are surfaced in DevTools Issues > and the Network Panel, so developers should also be able to discover > affected resources independently. > > On Wed, Jul 23, 2025 at 1:16 PM Alex Russell <slightly...@chromium.org> > wrote: > >> (sorry for previous typos) >> >> Per today's API OWNERS meeting, this intent is being held until Yoav's >> questions are resolved. I don't expect that this will be delayed long, and >> stakeholders will meet soon and update this thread with resolutions. >> >> Best, >> >> Alex >> >> On Wednesday, July 23, 2025 at 7:42:41 AM UTC+1 Yoav Weiss wrote: >> >>> Some questions >>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/NJvGkSvLk8I/m/4mJ-u25GAgAJ> >>> I >>> asked on the I2E are still left unanswered. >>> >>> Overall, I think this feature will cause interop issues *by definition*, >>> at least for the 57 domains on the list that are marked as "some URLs are >>> affected". >>> I'd appreciate it if y'all can hold back on shipping this until this is >>> further discussed at the API owners meeting. >>> >>> On Tue, Jul 22, 2025 at 5:51 PM Mike West <mk...@chromium.org> wrote: >>> >>>> Ok, it sounds like you're asking for something conceptually similar to >>>> https://learn.microsoft.com/en-us/microsoft-edge/web-platform/tracking-prevention? >>>> I think we can pull that together. >>>> >>>> Thanks for the suggestion! >>>> >>>> -mike >>>> >>>> >>>> On Tue, Jul 22, 2025 at 4:00 PM Alex Russell <slightly...@chromium.org> >>>> wrote: >>>> >>>>> Nothing first that I'm not asking from an Edge perspective (we have >>>>> the resources to follow along with most things y'all do), a sketch for how >>>>> a small browser might implement bloxking using the same list y'all do >>>>> would >>>>> be enough for me. >>>>> >>>>> Thanks! >>>>> >>>>> On Tue, Jul 22, 2025, 11:47 AM Mike West <mk...@google.com> wrote: >>>>> >>>>>> Hey Alex! Thanks for your feedback (and LGTM :) )! >>>>>> >>>>>> On documentation: we have a PR up against Fetch at >>>>>> https://github.com/whatwg/fetch/pull/1840 which aims to clarify the >>>>>> timing and web-facing impact of a blocking decision, and the list of >>>>>> affected domains is up at >>>>>> https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md. >>>>>> What additional documentation would you like to see that would improve >>>>>> consistency across vendors? >>>>>> >>>>>> That said, I think we have to broadly accept that different vendors >>>>>> are going to make different decisions about which resources they allow to >>>>>> load in a given context. This is already the case from a security >>>>>> perspective with choices between Safe Browsing and SmartScreen, and is >>>>>> already the case from a privacy perspective with decisions around >>>>>> subsetting blocklist vendors' lists which vary given each user agent's >>>>>> priorities and risk tolerance. I don't think it's likely that there's >>>>>> going >>>>>> to be alignment on a single list in the near-term. That doesn't seem >>>>>> fatal >>>>>> to me, as long as we agree on the web-facing impact. Does that more or >>>>>> less >>>>>> align with your view, or should we be aiming for a different >>>>>> compatibility >>>>>> bar in the long run? >>>>>> >>>>>> -mike >>>>>> >>>>>> >>>>>> On Tue, Jul 22, 2025 at 12:07 PM Alex Russell < >>>>>> slightly...@chromium.org> wrote: >>>>>> >>>>>>> I remain concerned that this behaviour isn't going to be shared by >>>>>>> other Chromium-based browsers. Web Platform behaviour differences >>>>>>> between >>>>>>> our implementations opens up risks of ongoing divergence, and so I'm >>>>>>> going >>>>>>> to LGTM3 on the condition that documentation is produced for other >>>>>>> embedders that wish to adopt the same behaviour in a straightforward >>>>>>> way. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> On Wednesday, July 16, 2025 at 6:39:57 PM UTC+1 Philip Jägenstedt >>>>>>> wrote: >>>>>>> >>>>>>>> LGTM2 >>>>>>>> >>>>>>>> On Wed, Jul 16, 2025 at 5:55 PM Chris Harrelson < >>>>>>>> chris...@chromium.org> wrote: >>>>>>>> >>>>>>>>> Ok, thanks for clarifying. >>>>>>>>> >>>>>>>>> LGTM1 >>>>>>>>> >>>>>>>>> On Wed, Jul 16, 2025 at 8:51 AM 'Zainab Rizvi' via blink-dev < >>>>>>>>> blink-dev@chromium.org> wrote: >>>>>>>>> >>>>>>>>>> Hi Chris! We will have a few UI indicators when a resource is >>>>>>>>>> blocked: >>>>>>>>>> >>>>>>>>>> 1. The "eye" icon will show up in the Omnibox that will >>>>>>>>>> allow users to disable the feature on a particular top-level site. >>>>>>>>>> 2. There is a toggle in settings for users to disable the feature >>>>>>>>>> entirely. >>>>>>>>>> 3. For developers, a dedicated issue will pop up in the "Issues" >>>>>>>>>> tab. >>>>>>>>>> 4. For developers, there is a dedicated network error >>>>>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:net/base/net_error_list.h;l=136?q=BLOCKED_BY_FINGER&sq=&ss=chromium> >>>>>>>>>> in >>>>>>>>>> the "Network" tab. >>>>>>>>>> >>>>>>>>>> On Wed, Jul 16, 2025 at 11:32 AM Chris Harrelson < >>>>>>>>>> chris...@chromium.org> wrote: >>>>>>>>>> >>>>>>>>>>> In case of something breaking: When a script is blocked, is the >>>>>>>>>>> user able to find that out in a site settings dialog? >>>>>>>>>>> >>>>>>>>>>> On Tue, Jul 15, 2025 at 7:59 AM 'Zainab Rizvi' via blink-dev < >>>>>>>>>>> blink-dev@chromium.org> wrote: >>>>>>>>>>> >>>>>>>>>>>> Yes, though Script Blocking in Incognito would have the same >>>>>>>>>>>> observable effect as extensions that block resources, such as ad >>>>>>>>>>>> blockers. >>>>>>>>>>>> The team is also adding monitoring to see if incognito >>>>>>>>>>>> detectability is on >>>>>>>>>>>> the rise due to these features. >>>>>>>>>>>> >>>>>>>>>>>> On Mon, Jul 14, 2025 at 7:23 PM Gregg Tavares < >>>>>>>>>>>> g...@chromium.org> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Does this enable more detection of incognito mode by sites? >>>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Jul 14, 2025 at 1:08 PM 'Zainab Rizvi' via blink-dev < >>>>>>>>>>>>> blink-dev@chromium.org> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, Alex! This will only be enabled for Chrome's Incognito >>>>>>>>>>>>>> mode. >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Mon, Jul 14, 2025 at 2:19 PM Alex Russell < >>>>>>>>>>>>>> slightly...@chromium.org> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Will this be enabled for all Chromium browsers by default? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Monday, July 14, 2025 at 8:54:57 AM UTC-7 >>>>>>>>>>>>>>> riz...@google.com wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Contact emails >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> riz...@google.com, mk...@chromium.org >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Explainer >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/explainers-by-googlers/script-blocking >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Specification >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/whatwg/fetch/pull/1840 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Summary >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Mitigating API Misuse for Browser Re-Identification, >>>>>>>>>>>>>>>> otherwise known as Script Blocking, is a feature that will >>>>>>>>>>>>>>>> block scripts >>>>>>>>>>>>>>>> engaging in known, prevalent techniques for browser >>>>>>>>>>>>>>>> re-identification in >>>>>>>>>>>>>>>> third-party contexts. These techniques typically involve the >>>>>>>>>>>>>>>> misuse of >>>>>>>>>>>>>>>> existing browser APIs to extract additional information about >>>>>>>>>>>>>>>> the user's >>>>>>>>>>>>>>>> browser or device characteristics. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> To strike this balance between protection and usability, >>>>>>>>>>>>>>>> this proposal focuses on blocking scripts in a third-party >>>>>>>>>>>>>>>> context in >>>>>>>>>>>>>>>> Incognito mode, enhancing Incognito's protections against >>>>>>>>>>>>>>>> cross-site >>>>>>>>>>>>>>>> tracking when users choose to browse in this mode. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> This proposal uses a list-based approach, where only >>>>>>>>>>>>>>>> domains marked as “Impacted by Script Blocking” on the Masked >>>>>>>>>>>>>>>> Domain List >>>>>>>>>>>>>>>> <https://github.com/GoogleChrome/ip-protection/blob/main/Masked-Domain-List.md> >>>>>>>>>>>>>>>> (MDL) in a third-party context will be impacted. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> When the feature is enabled, Chrome will check network >>>>>>>>>>>>>>>> requests against the blocklist. This feature will reuse >>>>>>>>>>>>>>>> Chromium's >>>>>>>>>>>>>>>> subresource_filter component, which is responsible for tagging >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> filtering subresource requests based on page-level activation >>>>>>>>>>>>>>>> signals and a >>>>>>>>>>>>>>>> ruleset used to match URLs for filtering. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 1% Experiment Summary >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Our 1% stable Incognito experiment did not show any >>>>>>>>>>>>>>>> statistically significant movement for Incognito-specific Core >>>>>>>>>>>>>>>> Web Vitals. >>>>>>>>>>>>>>>> Furthermore, we did not receive any breakage reports >>>>>>>>>>>>>>>> pertaining to this >>>>>>>>>>>>>>>> experiment. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As the feature is only enabled for third party resources in >>>>>>>>>>>>>>>> Incognito sessions, the sample size is smaller than we >>>>>>>>>>>>>>>> typically observe in >>>>>>>>>>>>>>>> a 1% experiment. We plan to carefully ramp the experiment to >>>>>>>>>>>>>>>> evaluate >>>>>>>>>>>>>>>> performance and stability impact before launching to Incognito >>>>>>>>>>>>>>>> 100%. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Blink component >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Blink>Network>FetchAPI >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG review >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://github.com/w3ctag/design-reviews/issues/1114 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> TAG review status >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Closed (resolution: decline) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Risks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> There shouldn’t be any interop concerns. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In terms of compatibility, this feature is anticipated to >>>>>>>>>>>>>>>> have an impact on websites that rely on scripts from domains >>>>>>>>>>>>>>>> identified as >>>>>>>>>>>>>>>> serving fingerprinting techniques. Sites that integrate >>>>>>>>>>>>>>>> third-party scripts >>>>>>>>>>>>>>>> from identified domains may experience functional breakage or >>>>>>>>>>>>>>>> render >>>>>>>>>>>>>>>> incorrectly when accessed in Incognito mode. We are attempting >>>>>>>>>>>>>>>> to mitigate >>>>>>>>>>>>>>>> this risk by applying temporary exceptions if we determine >>>>>>>>>>>>>>>> that the >>>>>>>>>>>>>>>> intervention on a particular domain may cause significant user >>>>>>>>>>>>>>>> experience >>>>>>>>>>>>>>>> impact. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Gecko: No signal >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> WebKit: Shipped/Shipping Safari has a similar feature as >>>>>>>>>>>>>>>> part of "Intelligent Tracking Prevention" (ITP) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Firefox: Shipped/Shipping Firefox has a similar feature as >>>>>>>>>>>>>>>> part of "Enhanced Tracking Protection" >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Web developers: <will fill out after explainer >>>>>>>>>>>>>>>> publication> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No, we are not proposing to ship this on WebView. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Debuggability >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We have added support in DevTools Issues to indicate which >>>>>>>>>>>>>>>> requests are being blocked by this feature. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We also have >>>>>>>>>>>>>>>> chrome://flags/#enable-fingerprinting-protection-blocklist-incognito >>>>>>>>>>>>>>>> which >>>>>>>>>>>>>>>> developers and users can use for testing suspected breakage >>>>>>>>>>>>>>>> even before we >>>>>>>>>>>>>>>> ship. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>>>>>>> (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> No. We plan to launch this on all Blink platforms except >>>>>>>>>>>>>>>> WebView. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>>>>>>> ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> We are exploring ways to test this feature via WPT. This >>>>>>>>>>>>>>>> isn’t possible today given the implementation-defined nature >>>>>>>>>>>>>>>> of blocked >>>>>>>>>>>>>>>> resources. Some explorations are discussed here >>>>>>>>>>>>>>>> <https://explainers-by-googlers.github.io/script-blocking/#testing> >>>>>>>>>>>>>>>> . >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Flag name on about://flags >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> chrome://flags/#enable-fingerprinting-protection-blocklist-incognito >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Finch feature name >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> EnableFingerprintingProtectionInIncognito >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Rollout plan >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> (RARE) Experiment users ramp up over time >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Requires code in //chrome? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> False >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Tracking bug >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://issues.chromium.org/issues/431761692 >>>>>>>>>>>>>>>> <https://issues.chromium.org/issues/370696608> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Launch bug >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://launch.corp.google.com/launch/4367306 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Estimated milestones >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Shipping on Desktop >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 140 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Shipping on Android >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 140 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Anticipated spec changes >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Open questions about a feature may be a source of future >>>>>>>>>>>>>>>> web compat or interop issues. Please list open issues (e.g. >>>>>>>>>>>>>>>> links to known >>>>>>>>>>>>>>>> github issues in the project for the feature specification) >>>>>>>>>>>>>>>> whose >>>>>>>>>>>>>>>> resolution may introduce web compat/interop risk (e.g., >>>>>>>>>>>>>>>> changing to naming >>>>>>>>>>>>>>>> or structure of the API in a non-backward-compatible way). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> None >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> https://chromestatus.com/feature/5188989497376768 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Intent to Experiment: >>>>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/NJvGkSvLk8I?e=48417069 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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 visit >>>>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjkJMw5aXR6T%3DQiiajtqAC0s9uqaWEZYgM6J4hUj5W7fA%40mail.gmail.com >>>>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjkJMw5aXR6T%3DQiiajtqAC0s9uqaWEZYgM6J4hUj5W7fA%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 visit >>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjGDTA_6ONhuHAxhg7yi-n9kC2y9JdL5nXtUzjb3FXd2Q%40mail.gmail.com >>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsjGDTA_6ONhuHAxhg7yi-n9kC2y9JdL5nXtUzjb3FXd2Q%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 visit >>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsieQ5z%3DKQEOQ_ELRSXHW1-agGASiD0aaVpkCku_BR%2BL%2Bg%40mail.gmail.com >>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFhOYsieQ5z%3DKQEOQ_ELRSXHW1-agGASiD0aaVpkCku_BR%2BL%2Bg%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 visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-WO%3DLD3JeHnD3Bz%2BfO2YACZfFaaCAv2VzERBNP23fmNw%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-WO%3DLD3JeHnD3Bz%2BfO2YACZfFaaCAv2VzERBNP23fmNw%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 visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeX3%3DUG8acCZ%2B%3DBimN9vT%2BXMtWdBOAp0ZaBL9VZF7isUw%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAKXHy%3DeX3%3DUG8acCZ%2B%3DBimN9vT%2BXMtWdBOAp0ZaBL9VZF7isUw%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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOmohSKyHgDaVebLLAHVvRXiU3mfa5g_RMOPh9CS9hvh-vUGMQ%40mail.gmail.com.
