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