Re: [blink-dev] Intent to Ship: Topics API

[Yoav Weiss]

LGTM1 to ship


On Fri, Jun 23, 2023 at 9:50 PM Josh Karlin  wrote:

>
>
> On Fri, Jun 23, 2023 at 3:27 PM Rick Byers  wrote:
>
>> On Thu, Jun 22, 2023 at 4:48 PM Josh Karlin  wrote:
>>
>>>
>>> On Thu, Jun 22, 2023 at 12:05 PM Rick Byers  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.
>
>
>
>>
>> On Thu, Jun 22, 2023 at 8:06 PM Sangwhan Moon  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 

Re: [blink-dev] Intent to Ship: Topics API

[Josh Karlin]

On Fri, Jun 23, 2023 at 3:27 PM Rick Byers  wrote:

> On Thu, Jun 22, 2023 at 4:48 PM Josh Karlin  wrote:
>
>>
>> On Thu, Jun 22, 2023 at 12:05 PM Rick Byers  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.



>
> On Thu, Jun 22, 2023 at 8:06 PM Sangwhan Moon  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
>> 

Re: [blink-dev] Intent to Ship: Topics API

[Rick Byers]

On Thu, Jun 22, 2023 at 4:48 PM Josh Karlin  wrote:

>
> On Thu, Jun 22, 2023 at 12:05 PM Rick Byers  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  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
> 

Re: [blink-dev] Intent to Ship: Topics API

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



> Is the name `browsingTopics` meant to signify that other sorts of topics may 
> become available? If no, why not just `topics`? And if so, should that be a 
> flag that's passed instead?




We do not anticipate other *Topics APIs. At this point I honestly can’t 
remember how we landed on browsingTopics instead, but I know there was 
discussion. FWIW, it’s less likely to conflict with expando properties. Do you 
feel strongly about this?







What feedback (if any) came from the OT?




Lots! Criteo pointed out ~5 different things in their link that I have above 
that they’d like to see improved for utility, many of which are part of our 
future non-breaking plans. Others pointed out that the ratio of noised Topics 
was proportionate to reach, which wasn’t appropriate, so we fixed that. Yet 
others pointed out that it was easy to detect the random topic, so we fixed 
that. For more, please see the response to the “Web developers” section in 
“Risks” above.



Josh




On Wed, Jun 21, 2023 at 12:06 PM Alex Russell  wrote:

The spec looks well-written, and I'm dissapointed by the lack of technical 
feedback from the TAG. 


Because the TAG doesn't seem to be engaging at the level of platform 
consistency and quality in this review, I have some questions of the sort I try 
not to ask (in the hopes that the TAG has those bases covered):


I don't see a full "considered alternatives" section in the Explainer. What 
other options were explored for this API and/or design?
Does this naturally need to live on `document`? Was `navigator` (or some other 
root object) considered?
Is the name `browsingTopics` meant to signify that other sorts of topics may 
become available? If no, why not just `topics`? And if so, should that be a 
flag that's passed instead?
What feedback (if any) came from the OT?
Best,


Alex




On Tuesday, June 20, 2023 at 8:33:41 PM UTC-7 Domenic Denicola wrote:

I was the spec mentor for Yao's work on this feature, and am chiming in to 
provide the requested spec maturity summary.


I am very happy with the rigor of this specification. The algorithms and APIs 
are given in full detail, and I am as confident as I can be that another 
implementer would be able to follow and create an interoperable implementation. 
I'm also happy with how some of the design discussions went, e.g. we recently 
made changes to the Sec-Browsing-Topics HTTP request header which improved its 
parse-ability and robustness.


The slicing of the specification into implementation-defined vs. interoperable 
behavior is tricky, and as Josh notes, can evolve over time. E.g. this PR 
proposes making the "top 5 topics" algorithm implementation-defined. (But, it 
keeps Chrome's version in a non-normative note, which I think is really 
helpful!) And there are browser vendor identifiers and version numbers baked 
into the return values of the spec. It's hard to say whether this setup will 
guarantee us the ability to evolve the API going forward, but I think the team 
has done a good job setting up the infrastructure to avoid any known failure 
modes.


I will note that the open issues list for the specification is enormous, but my 
experience with Privacy Sandbox specifications is that their issues list turn 
into discussion forums pretty easily. I'm happy to trust the team's appraisal 
(under "Anticipate spec changes") that there aren't any open issues which will 
be significant disruptions to the specification.


On Wed, Jun 21, 2023 at 2:40 AM Josh Karlin  wrote:


Contact emails

Re: [blink-dev] Intent to Ship: Topics API

[Josh Karlin]

On Thu, Jun 22, 2023 at 12:05 PM Rick Byers  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



>
> Thanks,
> Rick
>
>
> On Thu, Jun 22, 2023 at 10:26 AM 'Michael Kleber' via blink-dev <
> blink-dev@chromium.org> wrote:
>
>> 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 

Re: [blink-dev] Intent to Ship: Topics API

[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


On Thu, Jun 22, 2023 at 10:26 AM 'Michael Kleber' via blink-dev <
blink-dev@chromium.org> wrote:

> 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
>
>
> On Thu, Jun 22, 2023 at 10:15 AM Yoav Weiss 
> wrote:
>
>>
>>
>> On Thu, Jun 22, 2023 at 4:05 PM Josh Karlin  wrote:
>>
>>>
>>>
>>> On Thu, Jun 22, 2023 at 7:49 AM Yoav Weiss 
>>> wrote:
>>>
 Thanks for working on this important problem!

 This API is an interesting one to think 

Re: [blink-dev] Intent to Ship: Topics API

['Michael Kleber' via blink-dev]

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


On Thu, Jun 22, 2023 at 10:15 AM Yoav Weiss  wrote:

>
>
> On Thu, Jun 22, 2023 at 4:05 PM Josh Karlin  wrote:
>
>>
>>
>> On Thu, Jun 22, 2023 at 7:49 AM Yoav Weiss 
>> 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 
>>> 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.
>>>
>>>
 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 

Re: [blink-dev] Intent to Ship: Topics API

[Yoav Weiss]

On Thu, Jun 22, 2023 at 4:05 PM Josh Karlin  wrote:

>
>
> On Thu, Jun 22, 2023 at 7:49 AM Yoav Weiss  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  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.
>>
>>
>>> 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
>>>
>>>
>>> On Wed, Jun 21, 2023 at 12:06 PM Alex Russell 
>>> wrote:
>>>
 The spec looks well-written, and I'm dissapointed by the lack of
 technical feedback from the TAG.

Re: [blink-dev] Intent to Ship: Topics API

[Josh Karlin]

On Thu, Jun 22, 2023 at 7:49 AM Yoav Weiss  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  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.
>
>
>> 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
>>
>>
>> On Wed, Jun 21, 2023 at 12:06 PM Alex Russell 
>> 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 

Re: [blink-dev] Intent to Ship: Topics API

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


> 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
>
>
> On Wed, Jun 21, 2023 at 12:06 PM Alex Russell 
> 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 

Re: [blink-dev] Intent to Ship: Topics API

[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


On Wed, Jun 21, 2023 at 12:06 PM Alex Russell 
wrote:

> The spec looks well-written, and I'm dissapointed by the lack of technical
> feedback from the TAG.
>
> Because the TAG doesn't seem to be engaging at the level of platform
> consistency and quality in this review, I have some questions of the sort I
> try not to ask (in the hopes that the TAG has those bases covered):
>
>
>- I don't see a full "considered alternatives" section in the
>Explainer. What other options were explored for this API and/or design?
>- Does this naturally need to live on `document`? Was `navigator` (or
>some other root object) considered?
>- Is the name `browsingTopics` meant to signify that other sorts of
>topics may become available? If no, why not just `topics`? And if so,
>should that be a flag that's passed instead?
>- What feedback (if any) came from the OT?
>
> Best,
>
> Alex
>
>
> On Tuesday, June 20, 2023 at 8:33:41 PM UTC-7 Domenic Denicola wrote:
>
>> I was the spec mentor for Yao's work on this feature, and am chiming in
>> to provide the requested spec maturity summary
>> 
>> .
>>
>> I am very happy with the rigor of this specification. The algorithms and
>> APIs are given in full detail, and I am as confident as I can be that
>> another implementer would be able to follow and create an interoperable
>> implementation. I'm also happy with how some of the design discussions
>> went, e.g. we recently made changes to the Sec-Browsing-Topics HTTP request
>> header which improved its parse-ability and robustness.
>>
>> The slicing of the specification into implementation-defined vs.
>> interoperable behavior is tricky, and as Josh notes, can evolve over time.
>> E.g. this PR  
>> proposes
>> making the "top 5 topics" algorithm implementation-defined. (But, it 

Re: [blink-dev] Intent to Ship: Topics API

[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


On Tuesday, June 20, 2023 at 8:33:41 PM UTC-7 Domenic Denicola wrote:

> I was the spec mentor for Yao's work on this feature, and am chiming in to 
> provide the requested spec maturity summary 
> 
> .
>
> I am very happy with the rigor of this specification. The algorithms and 
> APIs are given in full detail, and I am as confident as I can be that 
> another implementer would be able to follow and create an interoperable 
> implementation. I'm also happy with how some of the design discussions 
> went, e.g. we recently made changes to the Sec-Browsing-Topics HTTP request 
> header which improved its parse-ability and robustness.
>
> The slicing of the specification into implementation-defined vs. 
> interoperable behavior is tricky, and as Josh notes, can evolve over time. 
> E.g. this PR  
> proposes 
> making the "top 5 topics" algorithm implementation-defined. (But, it keeps 
> Chrome's version in a non-normative note, which I think is really helpful!) 
> And there are browser vendor identifiers and version numbers baked into the 
> return values of the spec. It's hard to say whether this setup will 
> *guarantee* us the ability to evolve the API going forward, but I think 
> the team has done a good job setting up the infrastructure to avoid any 
> known failure modes.
>
> I will note that the open issues list 
>  for 
> the specification is enormous, but my experience with Privacy Sandbox 
> specifications is that their issues list turn into discussion forums pretty 
> easily. I'm happy to trust the team's appraisal (under "Anticipate spec 
> changes") that there aren't any open issues which will be significant 
> disruptions to the specification.
>
> On Wed, Jun 21, 2023 at 2:40 AM Josh Karlin  wrote:
>
>> Contact emails
>>
>> jkar...@chromium.org, yao...@chromium.org, leeronisr...@google.com
>>
>> Explainer
>>
>> https://github.com/patcg-individual-drafts/topics 
>>
>> Specification
>>
>> https://patcg-individual-drafts.github.io/topics/ 
>>
>> Summary
>>
>> The intent of the Topics API is to provide callers (including third-party 
>> ad-tech or advertising providers on the page that run script) with 
>> coarse-grained advertising topics that the page visitor might currently be 
>> interested in for the purposes of advertising. These topics will supplement 
>> the contextual signals from the current page and can be combined to help 
>> find an appropriate advertisement for the visitor without the advertiser 
>> having to track the user’s detailed browsing history as is done with 
>> third-party cookies and fingerprinting today.
>>
>> Blink Component
>>
>> Blink>TopicsAPI 
>> 
>>
>> TAG Review
>>
>> Early design review for the Topics API · Issue #726 
>> 
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> Gecko: Negative (
>> https://github.com/mozilla/standards-positions/issues/622)
>>
>> WebKit: Negative (
>> https://github.com/WebKit/standards-positions/issues/111 
>> 
>> )
>>
>> To reduce risk in the event that we later decide to replace this API with 
>> one that has more browser support, the API can be effectively disabled 
>> without breaking pages by rejecting the promise or returning empty lists of 
>> topics.
>>
>> Web developers: We’ve had significant OT participation 
>> 
>>  
>> and feedback in our periodic W3C PATCG calls 
>> 

Re: [blink-dev] Intent to Ship: Topics API

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

On Wed, Jun 21, 2023 at 2:40 AM Josh Karlin  wrote:

> Contact emails
>
> jkar...@chromium.org, yao...@chromium.org, leeronisr...@google.com
>
> Explainer
>
> https://github.com/patcg-individual-drafts/topics
>
> Specification
>
> https://patcg-individual-drafts.github.io/topics/
>
> Summary
>
> The intent of the Topics API is to provide callers (including third-party
> ad-tech or advertising providers on the page that run script) with
> coarse-grained advertising topics that the page visitor might currently be
> interested in for the purposes of advertising. These topics will supplement
> the contextual signals from the current page and can be combined to help
> find an appropriate advertisement for the visitor without the advertiser
> having to track the user’s detailed browsing history as is done with
> third-party cookies and fingerprinting today.
>
> Blink Component
>
> Blink>TopicsAPI
> 
>
> TAG Review
>
> Early design review for the Topics API · Issue #726
> 
>
> TAG review status
>
> Pending
>
> Risks
>
> Interoperability and Compatibility
>
> Gecko: Negative (https://github.com/mozilla/standards-positions/issues/622
> )
>
> WebKit: Negative (https://github.com/WebKit/standards-positions/issues/111
> 
> )
>
> To reduce risk in the event that we later decide to replace this API with
> one that has more browser support, the API can be effectively disabled
> without breaking pages by rejecting the promise or returning empty lists of
> topics.
>
> Web developers: We’ve had significant OT participation
> 
> and feedback in our periodic W3C PATCG calls
> ,
> discussions on various GitHub issues
> ,
> Chrome-facilitated office hours, discussion with industry trade groups
> representing a variety of stakeholder groups, and more. Some initial
> feedback on utility has been published by Criteo
> ,
> Google Ads
> 
> and Retargetly
> .
> We recently announced
>  upcoming
> improvements to utility (not API surface changing) based on that initial
> feedback.
>
> Activation
>
> Starting in August 2023, enrollment
> 
> will be required