On Thu, Jun 22, 2023 at 12:05 PM Rick Byers <rby...@chromium.org> wrote:
> Thanks for the added color! > > With WebKit and Gecko opposed on grounds that we're unlikely to ever > satisfy, it's clear this feature carries a lot of interop risk. Like other > controversial features we've shipped (eg. WebUSB), API owners are supposed > <https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/> > to evaluate that risk against the benefit of "moving the web forward". I > personally find it impossible to predict what the future of targeted > advertising will be on the web in ~5 years (eg. will it largely be replaced > by paywalls and/or move to users being required to be signed in to view all > ad-supported content?), but it's clearly important for the industry to > explore a variety of options to help increase the chances that we can align > on something good for both user's short term interests (eg. privacy) and > long-term interests (eg. availability of high-quality free content). So I'm > looking at this API mostly from a perspective of minimizing the costs to > the ecosystem across the likely possible outcomes. > > On the one hand, if perspectives like that of Gecko's > <https://github.com/mozilla/standards-positions/issues/622> prove to be > where the industry converges in time, then the ecosystem risk seems quite > low. We can probably unship this API without breaking any websites, and > worst case if we couldn't then we could simply lie and generate random > topics or something. So future compat risk seems very small and so we > shouldn't be too afraid of being wrong about the value of this API. > > On the other hand, if Topics ends up being successful and other engines > decide to support it (perhaps because some content providers choose to > offer free access to users with the API and paywall otherwise), then we > have to consider the future interop risk. It looks to me like the team has > done a good job with API design, specs and tests such that future > interoperability is likely not too hard. Thank you Domenic for your spec > maturity summary, very helpful! > > The only concern I can see is in the large number of open spec issues. > Given there's at least one open issue > <https://github.com/patcg-individual-drafts/topics/issues/71> that we'd > likely be deciding implicitly by shipping (API name/location), Josh could > you and the team do a bug triage pass and assign a label to it and any > others in a similar boat of being a substantial breaking change should we > decide differently in the future? Ideally such issues could be resolved > now, but if we need to carry them past ship then we should at least be > aware of the future known compat risk we're creating for ourselves. Even > something like the API name doesn't seem like a huge compat problem to me - > I suspect we could simply ship it under a 2nd name for a few months and > then remove the first, right Josh? Still, I think we should make this > determination explicitly prior to shipping. > Yep, done. That was the only challenging compat issue that I came across, and I've labeled it as such. Yes, we could do such a rename but yes we'd wind up having to support both names in the wild for some period of time. Josh > > Thanks, > Rick > > > On Thu, Jun 22, 2023 at 10:26 AM 'Michael Kleber' via blink-dev < > blink-dev@chromium.org> wrote: > >> A little more color here: >> >> When we first began work on (the respective predecessors of) Topics and >> Protected Audience, our best guess was that Topics would be more easily >> adopted, based on its vastly simpler API surface, but that Protected >> Audience would allow the advertising industry much more power in exchange >> for the hard work of living within its privacy boundaries. And as Josh >> said, the two APIs are also best suited to different levels of detail in >> targeting. >> >> Over the course of the Origin Trial, I would say much of this expectation >> has been borne out. Topics is becoming available to many ads buyers, for >> example, as described by Google Ad Manager at >> https://support.google.com/admanager/answer/12270543?hl=en, while >> Protected Audience so far only includes a narrower slice of early >> adopters. On the other hand, the lists of self-declared testers for the >> two APIs, here >> <https://github.com/patcg-individual-drafts/topics/blob/main/topics-tester-list.md> >> and here >> <https://github.com/WICG/turtledove/blob/main/fledge-tester-list.md> >> respectively, are the same length — so perhaps the Protected Audience >> barrier to entry is not as high as we feared. The OT feedback has >> indicated that both APIs are of interest to the same parties, neither one >> clearly dominating the other, at least for now. >> >> I think the real answer to the question will only be known over time, as >> the ad tech industry tries out the two different APIs and see what best >> suits each use case. We can certainly add some cross-references to the two >> explainers, but I don't think it will rise to the level of guidance to >> developers on how to choose one vs. the other. >> >> --Michael >> >> >> On Thu, Jun 22, 2023 at 10:15 AM Yoav Weiss <yoavwe...@chromium.org> >> wrote: >> >>> >>> >>> On Thu, Jun 22, 2023 at 4:05 PM Josh Karlin <jkar...@chromium.org> >>> wrote: >>> >>>> >>>> >>>> On Thu, Jun 22, 2023 at 7:49 AM Yoav Weiss <yoavwe...@chromium.org> >>>> wrote: >>>> >>>>> Thanks for working on this important problem! >>>>> >>>>> This API is an interesting one to think through, as it's quite >>>>> different from other APIs, even Privacy Sandbox ones. While most Privacy >>>>> Sandbox APIs carve out specific bits of entropy from 3P cookies to enable >>>>> web functionality to continue to work, only with more targeted data, >>>>> Topics >>>>> seems to enable a use-case (targeted advertising) by moving some of the >>>>> targeting work from the server onto the user agent itself. >>>>> >>>>> In my view it makes sense to include "ecosystem health" into a broad & >>>>> holistic view of the user's needs, and hence it makes sense for the user >>>>> agent to take on such work in order to enable ecosystem monetization, >>>>> *while >>>>> ensuring the user's agency*. Therefore, I think this is a fine >>>>> precedent to make, under the assumption the user indeed has agency and is >>>>> making an informed decision about enabling this API and controlling their >>>>> choice of Topics. At the same time, API owners are not UX experts, and the >>>>> UX of whatever consent flow browsers end up shipping is a product >>>>> decision, >>>>> rather than a part of the Blink intent process. As a result, approving >>>>> this >>>>> API requires a certain amount of faith that different user-agents will do >>>>> the right thing with it. But I guess that's already true for >>>>> permission-bound features, where we trust the UA's UX team to provide >>>>> appropriate mitigations for security and privacy risks. >>>>> >>>>> >>>>> On Wed, Jun 21, 2023 at 8:57 PM Josh Karlin <jkar...@chromium.org> >>>>> wrote: >>>>> >>>>>> Thanks for the questions Alex. Responses inline: >>>>>> >>>>>> >>>>>> > I don't see a full "considered alternatives" section in the >>>>>> Explainer. What other options were explored for this API and/or design? >>>>>> >>>>>> >>>>>> Yes. Before Topics we had another API, FLoC <https://web.dev/floc/>. >>>>>> We learned early on in the OT process that we did not want to move >>>>>> forward >>>>>> with it. Discussion of how FLoC migrated into Topics can be seen in this >>>>>> section >>>>>> <https://github.com/patcg-individual-drafts/topics#evolution-from-floc> >>>>>> of the explainer. >>>>>> >>>>> >>>>> I highly appreciate the evolution of the API and the many learnings >>>>> incorporated from the FLoC experiments. >>>>> >>>>> >>>>>> Another alternative would be to provide this sort of cross-site data >>>>>> only within a worklet, as Protected Audiences and Shared Storage do, and >>>>>> require that the ad be rendered within a fenced frame. An API like that >>>>>> is >>>>>> not off the table in the future, but at this stage we felt it prudent to >>>>>> make a simple API that could offer value in this space that has high >>>>>> levels >>>>>> of privacy in addition to the more complex and capable APIs that require >>>>>> private rendering. >>>>>> >>>>>> >>>>>> >>>>>> > Does this naturally need to live on `document`? Was `navigator` (or >>>>>> some other root object) considered? >>>>>> >>>>>> >>>>>> There is an issue >>>>>> <https://github.com/patcg-individual-drafts/topics/issues/71> for >>>>>> this, and I asked for advice >>>>>> <https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1137279345> >>>>>> on this on the TAG review but did not receive a response. We chose >>>>>> document >>>>>> at the time because the topics returned are conditional on the caller, >>>>>> and >>>>>> changing didn’t seem particularly compelling (e.g., it wasn’t abundantly >>>>>> clear where it should rightfully go). >>>>>> >>>>>> >>>>>> >>>>>> > Is the name `browsingTopics` meant to signify that other sorts of >>>>>> topics may become available? If no, why not just `topics`? And if so, >>>>>> should that be a flag that's passed instead? >>>>>> >>>>>> >>>>>> We do not anticipate other *Topics APIs. At this point I honestly >>>>>> can’t remember how we landed on browsingTopics instead, but I know there >>>>>> was discussion. FWIW, it’s less likely to conflict with expando >>>>>> properties >>>>>> <https://github.com/search?q=document.topics+language%3AJavaScript&type=code>. >>>>>> Do you feel strongly about this? >>>>>> >>>>>> >>>>>> >>>>>> What feedback (if any) came from the OT? >>>>>> >>>>>> >>>>>> Lots! Criteo >>>>>> <https://medium.com/criteo-engineering/is-googles-topics-api-a-viable-replacement-for-interest-based-advertising-297076192bd> >>>>>> pointed out ~5 different things in their link that I have above that >>>>>> they’d >>>>>> like to see improved for utility, many of which are part of our future >>>>>> non-breaking plans. Others pointed out >>>>>> <https://github.com/patcg-individual-drafts/topics/issues/73> that >>>>>> the ratio of noised Topics was proportionate to reach, which wasn’t >>>>>> appropriate, so we fixed that. Yet others pointed out >>>>>> <https://github.com/patcg-individual-drafts/topics/issues/75> that >>>>>> it was easy to detect the random topic, so we fixed that. For more, >>>>>> please >>>>>> see the response to the “Web developers” section in “Risks” above. >>>>>> >>>>>> Josh >>>>>> >>>>>> >>>>>> On Wed, Jun 21, 2023 at 12:06 PM Alex Russell < >>>>>> slightly...@chromium.org> wrote: >>>>>> >>>>>>> The spec looks well-written, and I'm dissapointed by the lack of >>>>>>> technical feedback from the TAG. >>>>>>> >>>>>>> Because the TAG doesn't seem to be engaging at the level of platform >>>>>>> consistency and quality in this review, I have some questions of the >>>>>>> sort I >>>>>>> try not to ask (in the hopes that the TAG has those bases covered): >>>>>>> >>>>>>> >>>>>>> - I don't see a full "considered alternatives" section in the >>>>>>> Explainer. What other options were explored for this API and/or >>>>>>> design? >>>>>>> - Does this naturally need to live on `document`? Was >>>>>>> `navigator` (or some other root object) considered? >>>>>>> - Is the name `browsingTopics` meant to signify that other sorts >>>>>>> of topics may become available? If no, why not just `topics`? And if >>>>>>> so, >>>>>>> should that be a flag that's passed instead? >>>>>>> - What feedback (if any) came from the OT? >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>> >>>>>>> On Tuesday, June 20, 2023 at 8:33:41 PM UTC-7 Domenic Denicola wrote: >>>>>>> >>>>>>>> I was the spec mentor for Yao's work on this feature, and am >>>>>>>> chiming in to provide the requested spec maturity summary >>>>>>>> <https://www.chromium.org/blink/launching-features/#:~:text=If%20your%20specification%20isn%27t%20a%20modification%20of%20an%20existing%20specification%2C%20include%20a%20one%2Dline%20spec%20maturity%20summary%20from%20someone%20outside%20your%20team%20(like%20your%20spec%20mentor)%20who%20has%20done%20a%20review.> >>>>>>>> . >>>>>>>> >>>>>>>> I am very happy with the rigor of this specification. The >>>>>>>> algorithms and APIs are given in full detail, and I am as confident as >>>>>>>> I >>>>>>>> can be that another implementer would be able to follow and create an >>>>>>>> interoperable implementation. I'm also happy with how some of the >>>>>>>> design >>>>>>>> discussions went, e.g. we recently made changes to the >>>>>>>> Sec-Browsing-Topics >>>>>>>> HTTP request header which improved its parse-ability and robustness. >>>>>>>> >>>>>>>> The slicing of the specification into implementation-defined vs. >>>>>>>> interoperable behavior is tricky, and as Josh notes, can evolve over >>>>>>>> time. >>>>>>>> E.g. this PR >>>>>>>> <https://github.com/patcg-individual-drafts/topics/pull/203> proposes >>>>>>>> making the "top 5 topics" algorithm implementation-defined. (But, it >>>>>>>> keeps >>>>>>>> Chrome's version in a non-normative note, which I think is really >>>>>>>> helpful!) >>>>>>>> And there are browser vendor identifiers and version numbers baked >>>>>>>> into the >>>>>>>> return values of the spec. It's hard to say whether this setup will >>>>>>>> *guarantee* us the ability to evolve the API going forward, but I >>>>>>>> think the team has done a good job setting up the infrastructure to >>>>>>>> avoid >>>>>>>> any known failure modes. >>>>>>>> >>>>>>>> I will note that the open issues list >>>>>>>> <https://github.com/patcg-individual-drafts/topics/issues?q=is%3Aopen> >>>>>>>> for >>>>>>>> the specification is enormous, but my experience with Privacy Sandbox >>>>>>>> specifications is that their issues list turn into discussion forums >>>>>>>> pretty >>>>>>>> easily. I'm happy to trust the team's appraisal (under "Anticipate spec >>>>>>>> changes") that there aren't any open issues which will be significant >>>>>>>> disruptions to the specification. >>>>>>>> >>>>>>>> On Wed, Jun 21, 2023 at 2:40 AM Josh Karlin <jkar...@chromium.org> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Contact emails >>>>>>>>> >>>>>>>>> jkar...@chromium.org, yao...@chromium.org, leeronisr...@google.com >>>>>>>>> >>>>>>>>> Explainer >>>>>>>>> >>>>>>>>> https://github.com/patcg-individual-drafts/topics >>>>>>>>> >>>>>>>> >>>>> That's a great explainer! One thing I found a bit lacking in it is an >>>>> outline of the use cases that this API tackles. Another question that came >>>>> to mind while reviewing other intents was around the differences in >>>>> use-cases between this and Protected Audience. Are they destined for >>>>> different kinds of advertisers? Different use cases? Something else? >>>>> >>>> >>>> They are indeed different use cases. Interest based advertising >>>> (Topics) is much broader (larger number of ads to choose from) than >>>> retargeting (Protected Audience). Interest based advertising allows an >>>> advertiser to say, "I'd like to advertise my product to people interested >>>> in these categories" whereas retargeting allows an advertiser to say, "this >>>> user was interested in some products on my page, I'd like to show them some >>>> more". You can imagine how it might be tractable to store metadata for the >>>> retargeting type ads on the users device, whereas it's less practical for >>>> interest based ads (easily millions of possible ads to select between). >>>> That is why Topics is quite limited in the information it can share since >>>> it needs to be made available to the caller, whereas Protected Audiences >>>> allows for more specific ad selection, but from a limited set of ads, and >>>> the ad must leverage private rendering. >>>> >>> >>> That's extremely useful, thanks!! (Maybe this can be added to the >>> explainer?) >>> >>> >>>> >>>> >>>>> >>>>> >>>>>>>>> Specification >>>>>>>>> >>>>>>>>> https://patcg-individual-drafts.github.io/topics/ >>>>>>>>> >>>>>>>>> Summary >>>>>>>>> >>>>>>>>> The intent of the Topics API is to provide callers (including >>>>>>>>> third-party ad-tech or advertising providers on the page that run >>>>>>>>> script) >>>>>>>>> with coarse-grained advertising topics that the page visitor might >>>>>>>>> currently be interested in for the purposes of advertising. These >>>>>>>>> topics >>>>>>>>> will supplement the contextual signals from the current page and can >>>>>>>>> be >>>>>>>>> combined to help find an appropriate advertisement for the visitor >>>>>>>>> without >>>>>>>>> the advertiser having to track the user’s detailed browsing history >>>>>>>>> as is >>>>>>>>> done with third-party cookies and fingerprinting today. >>>>>>>>> >>>>>>>>> Blink Component >>>>>>>>> >>>>>>>>> Blink>TopicsAPI >>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ETopicsAPI> >>>>>>>>> >>>>>>>>> TAG Review >>>>>>>>> >>>>>>>>> Early design review for the Topics API · Issue #726 >>>>>>>>> <https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1379908459> >>>>>>>>> >>>>>>>>> TAG review status >>>>>>>>> >>>>>>>>> Pending >>>>>>>>> >>>>>>>>> Risks >>>>>>>>> >>>>>>>>> Interoperability and Compatibility >>>>>>>>> >>>>>>>>> Gecko: Negative ( >>>>>>>>> https://github.com/mozilla/standards-positions/issues/622) >>>>>>>>> >>>>>>>>> WebKit: Negative ( >>>>>>>>> https://github.com/WebKit/standards-positions/issues/111 >>>>>>>>> <https://github.com/WebKit/standards-positions/issues/111#issuecomment-1359609317> >>>>>>>>> ) >>>>>>>>> >>>>>>>>> To reduce risk in the event that we later decide to replace this >>>>>>>>> API with one that has more browser support, the API can be effectively >>>>>>>>> disabled without breaking pages by rejecting the promise or returning >>>>>>>>> empty >>>>>>>>> lists of topics. >>>>>>>>> >>>>>>>>> Web developers: We’ve had significant OT participation >>>>>>>>> <https://github.com/patcg-individual-drafts/topics/blob/main/topics-tester-list.md> >>>>>>>>> and feedback in our periodic W3C PATCG calls >>>>>>>>> <https://github.com/patcg-individual-drafts/topics/tree/24c87897e32974c1328b74438feb97bf2ec43375/meetings>, >>>>>>>>> discussions on various GitHub issues >>>>>>>>> <https://github.com/patcg-individual-drafts/topics/issues>, >>>>>>>>> Chrome-facilitated office hours, discussion with industry trade groups >>>>>>>>> representing a variety of stakeholder groups, and more. Some initial >>>>>>>>> feedback on utility has been published by Criteo >>>>>>>>> <https://medium.com/criteo-engineering/is-googles-topics-api-a-viable-replacement-for-interest-based-advertising-297076192bd>, >>>>>>>>> Google Ads >>>>>>>>> <https://github.com/google/ads-privacy/blob/master/Testing%20IBA%20with%20Privacy%20Preserving%20Signals.pdf> >>>>>>>>> and Retargetly >>>>>>>>> <https://retargetly.com/blog-en/a-brief-dive-into-retargetlys-experience-testing-googles-privacy-sandbox>. >>>>>>>>> We recently announced >>>>>>>>> <https://developer.chrome.com/blog/topics-enhancements/> upcoming >>>>>>>>> improvements to utility (not API surface changing) based on that >>>>>>>>> initial >>>>>>>>> feedback. >>>>>>>>> >>>>>>>>> Activation >>>>>>>>> >>>>>>>>> Starting in August 2023, enrollment >>>>>>>>> <https://developer.chrome.com/en/blog/announce-enrollment-privacy-sandbox/> >>>>>>>>> will be required to use the API. This is not a compat risk in the >>>>>>>>> sense >>>>>>>>> that the API will simply reject for callers if they are not enrolled. >>>>>>>>> >>>>>>>>> Other signals: >>>>>>>>> >>>>>>>>> WebView application risks >>>>>>>>> >>>>>>>>> None >>>>>>>>> >>>>>>>>> Debuggability >>>>>>>>> >>>>>>>>> There is a useful internals page: chrome://topics-internals, which >>>>>>>>> shows the user’s current topics, allows for querying the API’s >>>>>>>>> classifier, >>>>>>>>> and provides developer experimentation tooling. >>>>>>>>> >>>>>>>>> >>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>> >>>>>>>>> All but WebView >>>>>>>>> >>>>>>>>> >>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>> ? >>>>>>>>> >>>>>>>>> IDL surface is tested >>>>>>>>> <https://wpt.fyi/results/browsing-topics?label=experimental&label=master&aligned>, >>>>>>>>> the actual returned topics are not as they are browser dependent. >>>>>>>>> >>>>>>>>> >>>>>>>>> Note for the failing tests: Chrome will roll out this feature via >>>>>>>>> Chrome >>>>>>>>> Variations >>>>>>>>> <https://developer.chrome.com/docs/web-platform/chrome-variations/>, >>>>>>>>> rather than enabling the runtime features >>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md> >>>>>>>>> directly. This means related WPTs need to be virtual, and it isn't >>>>>>>>> supported in wpt.fyi. >>>>>>>>> >>>>>>>>> Requires code in //chrome? >>>>>>>>> >>>>>>>>> No >>>>>>>>> >>>>>>>>> Launch bug >>>>>>>>> >>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1286877 >>>>>>>>> >>>>>>>>> >>>>>>>>> Anticipated spec changes >>>>>>>>> >>>>>>>>> As mentioned above, we anticipate changes to the classification >>>>>>>>> model, the taxonomy, the top topics selection algorithm, and possibly >>>>>>>>> some >>>>>>>>> parameters in the future as we try to improve the API’s utility over >>>>>>>>> time. >>>>>>>>> The API already provides version numbers with each returned topic for >>>>>>>>> each >>>>>>>>> of these features, as changes of this nature were anticipated from the >>>>>>>>> beginning. These changes will not break sites. Developers may need to >>>>>>>>> retrain their models and adapt to the new underlying algorithms, so >>>>>>>>> we will >>>>>>>>> announce the changes via channels such as blink-dev FYI as well as on >>>>>>>>> the >>>>>>>>> various support mailing lists. >>>>>>>>> >>>>>>>>> >>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>> >>>>>>>>> https://chromestatus.com/feature/5680923054964736 >>>>>>>>> >>>>>>>>> Links to previous Intent discussions >>>>>>>>> >>>>>>>>> Intent to prototype: >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/59uTw_dxM3M/m/vF9lF9BVAgAJ >>>>>>>>> >>>>>>>>> >>>>>>>>> Intent to experiment: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/oTwd6VwCwqs/m/pk7JPbXLAQAJ >>>>>>>>> >>>>>>>>> >>>>>>>>> Intent to extend origin trial: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/SD8Ot2gpz4g/m/A9uA-_cGAwAJ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/gpmaOi3of_w/m/SyMclFhMAAAJ >>>>>>>>> >>>>>>>>> >>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/CBrV-2DrYFI/m/RTojC6kHAgAJ >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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/CAANMuaNc94moaqPPWepai4THP1rOvXoxvixS%3Dostu2QGMLPtvA%40mail.gmail.com >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaNc94moaqPPWepai4THP1rOvXoxvixS%3Dostu2QGMLPtvA%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/fae46cf2-dbf8-41bf-8e64-c7cfb6844c01n%40chromium.org >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fae46cf2-dbf8-41bf-8e64-c7cfb6844c01n%40chromium.org?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/CAANMuaM1RZP4tKq4x7UvADOhYemyqtOhH5dgKUJK131sLWoS%3DA%40mail.gmail.com >>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaM1RZP4tKq4x7UvADOhYemyqtOhH5dgKUJK131sLWoS%3DA%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/CAL5BFfVbQDFhz_zmLHbm3DdN0nn8EtdmhfxFXbd4kYb%3DwOLmSQ%40mail.gmail.com >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVbQDFhz_zmLHbm3DdN0nn8EtdmhfxFXbd4kYb%3DwOLmSQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >> >> -- >> Forewarned is worth an octopus in the bush. >> >> -- >> 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/CAA6DcCfwqzyUNRW_f3JJCA_WtdJu036fSjphOp%2Bm4x3fmra6xQ%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA6DcCfwqzyUNRW_f3JJCA_WtdJu036fSjphOp%2Bm4x3fmra6xQ%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/CAFUtAY86BwABa2WTbf0_houXFuLaCWjVfHxWAmZ6nV4LFwb4KA%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY86BwABa2WTbf0_houXFuLaCWjVfHxWAmZ6nV4LFwb4KA%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/CAANMuaN5HD77S8DPt5TRe-Ys8Yq9JcF9RQuzNHwXwoHWyCjZKg%40mail.gmail.com.
