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. 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.
