On Thu, Jun 22, 2023 at 4:48 PM Josh Karlin <jkar...@chromium.org> wrote:
> > 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. > Thanks for doing the review! So for that one remaining high-compat-risk issue, are you requesting that we ship under document as spec'd but that you'd be open to moving the API as a breaking change if there's a rough consensus on where to put it at a later date? On Thu, Jun 22, 2023 at 8:06 PM Sangwhan Moon <s...@chromium.org> wrote: > > > On 2023年06月22日 03時57分08秒 (+09:00), Josh Karlin 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. 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). > > > We have an on-going thread on this, expect something (ideally) as early as > next week. > > Thanks Sangwhan. I'm interested to hear the latest thinking from TAG. Given the long discussed timeline <https://privacysandbox.com/open-web/#the-privacy-sandbox-timeline> of shipping in July, at this point I assume we're largely discussing potential future work (including breaking changes) that could be done to increase industry support and potential for eventual interoperability. So I don't think there's particular urgency to the TAG feedback. Nonetheless I'm happy to withhold my LGTM for a few more days to see if there's any new arguments folks might want to bring to bear on the API owner approval process here. By the way, re-reading the TAG discussion I want to emphasize a point that kleber@ made that I think is at the crux of some of the tension here: "From a POV more focused on web standards: as with any other non-backwards-compatible change to the web platform, we can only proceed with a deprecation and removal after considering the potential breakage. See https://www.chromium.org/blink/launching-features/#feature-deprecations for full details of the Blink process, but note for example that the guidelines <https://docs.google.com/document/d/1LdqUfUILyzM5WEcOgeAWGupQILKrZHidEXrUxevyi_Y/edit> ask "What is the cost of removing this feature?" and "What is the suggested alternative? There should be another way for developers to achieve the same functionality." A change that would cause most web sites to lose half of their revenue, without any privacy-improving alternative, is not compatible with our removal process." I agree with this 100%, and years ago expanded on it in the details of our breaking change principles <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.x5bhg5grhfeo>. Our job as API owners is to uphold principles like not taking important functionality away from web developers without viable alternatives while maximizing interoperability and multi-stakeholder alignment on the shape of the web. So I'm viewing all these PS APIs from a lense of the improvement they offer over the status quo of 3PCs. In my view there's no alternative world where Chrome lacks 3PCs by default but doesn't have new APIs like this. So the interop risk of these controversial APIs is balanced by the interop risk of Chrome retaining 3PCs indefinitely while other browsers do not (which we can see the harm of concretely with all the sites that don't work in Safari, eg. in enterprise and education environments). 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/CAFUtAY9i%2Bc5diiGm9MBatSgvAQq8_cJa6c6aLtZdNioDKAY5Ew%40mail.gmail.com.
