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. 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 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 for this, and I asked for advice 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. > 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. Do you feel strongly about this? What feedback (if any) came from the OT? Lots! Criteo 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 that the ratio of noised Topics was proportionate to reach, which wasn’t appropriate, so we fixed that. Yet others pointed out 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. 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 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 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 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 TAG Review Early design review for the Topics API · Issue #726 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) 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 and feedback in our periodic W3C PATCG calls, discussions on various GitHub 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, Google Ads and Retargetly. We recently announced upcoming improvements to utility (not API surface changing) based on that initial feedback. Activation Starting in August 2023, enrollment 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? IDL surface is tested, 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, rather than enabling the runtime features 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. -- 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. -- 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/1687478692341.2143193473.1787623677%40chromium.org.
