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> >> . >> > -- 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/CAL5BFfXtCHN1XTsrDdUXbiXEUm%2BSC5N7OEo3JH3qwSZGHZq7eQ%40mail.gmail.com.
