Intent to Ship: Topics API

[Josh Karlin‏]

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

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

[Domenic Denicola‏]

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.

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

[Alex Russell‏]

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

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Josh Karlin‏]

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?

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

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.

[Yoav Weiss‏]

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 <jka...@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. 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.

I highly appreciate the evolution of the API and the many learnings incorporated from the FLoC experiments.

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?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaM1RZP4tKq4x7UvADOhYemyqtOhH5dgKUJK131sLWoS%3DA%40mail.gmail.com.

[Josh Karlin‏]

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.

 

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.

[Yoav Weiss‏]

That's extremely useful, thanks!! (Maybe this can be added to the explainer?)

[Michael Kleber‏]

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 and here 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

--

Forewarned is worth an octopus in the bush.

[Rick Byers‏]

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.

Thanks,

    Rick

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.

[Josh Karlin‏]

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.

Josh

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY86BwABa2WTbf0_houXFuLaCWjVfHxWAmZ6nV4LFwb4KA%40mail.gmail.com.

[Sangwhan Moon‏]

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.

[Rick Byers‏]

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? 

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

Thanks Sangwhan. I'm interested to hear the latest thinking from TAG. Given the long discussed 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 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. 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 Karlin‏]

On Fri, Jun 23, 2023 at 3:27 PM Rick Byers <rby...@chromium.org> wrote:

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? 

Yes. Shipping with document.browsingTopics but later deprecating and changing to window.browsingTopics or whatever that issue resolves to sgtm.

 

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.

[Yoav Weiss‏]

LGTM1 to ship

[Mike Taylor‏]

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.

[Chris Harrelson‏]

LGTM3

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.

[Rick Byers‏]

Agreed that we shouldn't block any longer on TAG feedback before shipping the 1.0, so LGTM4 (not that it's needed). But hopefully ongoing engagement will be constructive in building more industry alignment beyond what we ship as 1.0.

Rick

[Sangwhan Moon‏]

I suppose the ship is sailing at this point, but another round of feedback is expected to go out this week.

We're intentionally keeping the discussion member only for the plenary to sign off and release. I would expect some of the feedback to be fairly easy to take action on.

Sangwhan

On Jun 27, 2023, at 9:03, Rick Byers <rby...@chromium.org> wrote:



[Rick Byers‏]

Thanks Sangwhan. Given that the team is already exploring changing even the API entrypoint post-launch, I'm sure that there will continue to be opportunities to make changes and improvements. Farm from the "ship sailing" at any given point, I think this whole space is a journey that'll involve lots of course adjustments along the way. 

   Rick

[Alex Russell‏]

IDK why the ship needs to sail if the TAG is intending to weight in. It's (highly) frustrating that the TAG has failed to provide meaningful technical guidance here when even a cursory glance at the design raises questions (like the location of the API). I haven't voted on this intent, but I would suggest the TAG take this up with haste and that the Intent owners take that feedback in stride. Permission to launch !== a suicide pact.

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.

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.

--
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/CAFUtAY86BwABa2WTbf0_houXFuLaCWjVfHxWAmZ6nV4LFwb4KA%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/CAFUtAY9i%2Bc5diiGm9MBatSgvAQq8_cJa6c6aLtZdNioDKAY5Ew%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/CAL5BFfXcjw1ONZm-5Vr4e%3Dn6gAwt_m33HQ761f%2BZ2OQQj_ZWpw%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.

[Yoav Weiss‏]

On Wed, Jun 28, 2023 at 5:47 PM Alex Russell <sligh...@chromium.org> wrote:

IDK why the ship needs to sail if the TAG is intending to weight in.

When LGTMing, I assumed that Sangwhan's comment about feedback was about the API's location, which Josh already said can be addressed later by migrating to whatever location would get consensus.

As Rick said, there are likely to be opportunities to incorporate even more substantial feedback if needed.

 

It's (highly) frustrating that the TAG has failed to provide meaningful technical guidance here when even a cursory glance at the design raises questions (like the location of the API). I haven't voted on this intent, but I would suggest the TAG take this up with haste and that the Intent owners take that feedback in stride. Permission to launch !== a suicide pact.

I have no idea what that last sentence means..

 

LGTM3

LGTM1 to ship

Josh

 

Thanks,

    Rick

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.

--
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/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+...@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+...@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.

--
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/CAFUtAY86BwABa2WTbf0_houXFuLaCWjVfHxWAmZ6nV4LFwb4KA%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/CAFUtAY9i%2Bc5diiGm9MBatSgvAQq8_cJa6c6aLtZdNioDKAY5Ew%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/CAL5BFfXcjw1ONZm-5Vr4e%3Dn6gAwt_m33HQ761f%2BZ2OQQj_ZWpw%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.

[Mike Taylor‏]

On 6/30/23 4:28 PM, Yoav Weiss wrote:

On Wed, Jun 28, 2023 at 5:47 PM Alex Russell <sligh...@chromium.org> wrote:

IDK why the ship needs to sail if the TAG is intending to weight in.

When LGTMing, I assumed that Sangwhan's comment about feedback was about the API's location, which Josh already said can be addressed later by migrating to whatever location would get consensus.

As Rick said, there are likely to be opportunities to incorporate even more substantial feedback if needed.

FWIW, the feedback and questions in https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1612522047 does not make me reconsider my LGTM. The questions raised around taxonomies, UX, and consent don't seem like they would require backwards incompatible changes to the API, should the feedback be acted upon.

[Chris Harrelson‏]

On Fri, Jun 30, 2023 at 7:27 AM Mike Taylor <mike...@chromium.org> wrote:

On 6/30/23 4:28 PM, Yoav Weiss wrote:

On Wed, Jun 28, 2023 at 5:47 PM Alex Russell <sligh...@chromium.org> wrote:

IDK why the ship needs to sail if the TAG is intending to weight in.

When LGTMing, I assumed that Sangwhan's comment about feedback was about the API's location, which Josh already said can be addressed later by migrating to whatever location would get consensus.

As Rick said, there are likely to be opportunities to incorporate even more substantial feedback if needed.

FWIW, the feedback and questions in https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1612522047 does not make me reconsider my LGTM. The questions raised around taxonomies, UX, and consent don't seem like they would require backwards incompatible changes to the API, should the feedback be acted upon.

I came to the same conclusion.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/5679c5c4-a68b-75ae-7033-051a86019ddf%40chromium.org.

[Yoav Weiss‏]

On Fri, Jun 30, 2023 at 5:15 PM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Jun 30, 2023 at 7:27 AM Mike Taylor <mike...@chromium.org> wrote:

On 6/30/23 4:28 PM, Yoav Weiss wrote:

On Wed, Jun 28, 2023 at 5:47 PM Alex Russell <sligh...@chromium.org> wrote:

IDK why the ship needs to sail if the TAG is intending to weight in.

When LGTMing, I assumed that Sangwhan's comment about feedback was about the API's location, which Josh already said can be addressed later by migrating to whatever location would get consensus.

As Rick said, there are likely to be opportunities to incorporate even more substantial feedback if needed.

FWIW, the feedback and questions in https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1612522047 does not make me reconsider my LGTM. The questions raised around taxonomies, UX, and consent don't seem like they would require backwards incompatible changes to the API, should the feedback be acted upon.

I came to the same conclusion.

Same here.

[Sangwhan Moon‏]

On 2023年07月01日 00時16分31秒 (+09:00), Yoav Weiss wrote:

On Fri, Jun 30, 2023 at 5:15 PM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Jun 30, 2023 at 7:27 AM Mike Taylor <mike...@chromium.org> wrote:

On 6/30/23 4:28 PM, Yoav Weiss wrote:

On Wed, Jun 28, 2023 at 5:47 PM Alex Russell <sligh...@chromium.org> wrote:

IDK why the ship needs to sail if the TAG is intending to weight in.

When LGTMing, I assumed that Sangwhan's comment about feedback was about the API's location, which Josh already said can be addressed later by migrating to whatever location would get consensus.

As Rick said, there are likely to be opportunities to incorporate even more substantial feedback if needed.

FWIW, the feedback and questions in https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1612522047 does not make me reconsider my LGTM. The questions raised around taxonomies, UX, and consent don't seem like they would require backwards incompatible changes to the API, should the feedback be acted upon.

I came to the same conclusion.

Same here.

> I assumed that Sangwhan's comment about feedback was about the API's location

It was, posted.

[Chris Harrelson‏]

On Fri, Jun 30, 2023 at 8:30 AM Sangwhan Moon <s...@chromium.org> wrote:

On 2023年07月01日 00時16分31秒 (+09:00), Yoav Weiss wrote:

On Fri, Jun 30, 2023 at 5:15 PM Chris Harrelson <chri...@chromium.org> wrote:

On Fri, Jun 30, 2023 at 7:27 AM Mike Taylor <mike...@chromium.org> wrote:

On 6/30/23 4:28 PM, Yoav Weiss wrote:

On Wed, Jun 28, 2023 at 5:47 PM Alex Russell <sligh...@chromium.org> wrote:

IDK why the ship needs to sail if the TAG is intending to weight in.

When LGTMing, I assumed that Sangwhan's comment about feedback was about the API's location, which Josh already said can be addressed later by migrating to whatever location would get consensus.

As Rick said, there are likely to be opportunities to incorporate even more substantial feedback if needed.

FWIW, the feedback and questions in https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1612522047 does not make me reconsider my LGTM. The questions raised around taxonomies, UX, and consent don't seem like they would require backwards incompatible changes to the API, should the feedback be acted upon.

I came to the same conclusion.

Same here.

> I assumed that Sangwhan's comment about feedback was about the API's location

It was, posted.

Thanks! (link for others to see) I see there some reasons to keep it on document, which is good from the perspective of not having to change the feature later.

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1688138964748.3662555220.2188652474%40chromium.org.