Contact emails
jka...@chromium.org, yao...@chromium.org, leeron...@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
TAG Review
Early design review for the Topics API · Issue #726
Pending
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:
None
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.
All but WebView
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.
No
https://bugs.chromium.org/p/chromium/issues/detail?id=1286877
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.
https://chromestatus.com/feature/5680923054964736
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+...@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.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
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).
> 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?
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@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+...@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.
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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaM1RZP4tKq4x7UvADOhYemyqtOhH5dgKUJK131sLWoS%3DA%40mail.gmail.com.
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.
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.
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 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 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 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.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY86BwABa2WTbf0_houXFuLaCWjVfHxWAmZ6nV4LFwb4KA%40mail.gmail.com.
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).
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 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 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 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.
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.
On Thu, Jun 22, 2023 at 4:48 PM Josh Karlin <jka...@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 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 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 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?
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.
LGTM2. On the topic of document.browsingTopics vs. window (or
navigator...), I would ordinarily think it's not worth the churn
given the cost of outreach, but having this API behind enrollment
makes me hopeful we will have useful contacts to migrate folks
over if the interface does in fact move somewhere else one day.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXcjw1ONZm-5Vr4e%3Dn6gAwt_m33HQ761f%2BZ2OQQj_ZWpw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fbb436fd-f655-78b0-3e30-71b8417b3341%40chromium.org.
LGTM3
LGTM1 to ship
Josh
Thanks,Rick
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@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+unsubscribe@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+unsubscribe@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.
--
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+unsubscribe@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.
--
--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+unsubscribe@chromium.org.