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 <jkar...@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 >>> <https://www.chromium.org/blink/guidelines/web-platform-changes-guidelines/> >>> 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 >>> <https://github.com/mozilla/standards-positions/issues/622> 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 >>> <https://github.com/patcg-individual-drafts/topics/issues/71> 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 <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 <https://web.dev/floc/>. We >> learned early on in the OT process that we did not want to move forward >> with it. Discussion of how FLoC migrated into Topics can be seen in this >> section >> <https://github.com/patcg-individual-drafts/topics#evolution-from-floc> of >> the explainer. Another alternative would be to provide this sort of >> cross-site data only within a worklet, as Protected Audiences and Shared >> Storage do, and require that the ad be rendered within a fenced frame. An >> API like that is not off the table in the future, but at this stage we felt >> it prudent to make a simple API that could offer value in this space that >> has high levels of privacy in addition to the more complex and capable APIs >> that require private rendering. >> >> >> >> > Does this naturally need to live on `document`? Was `navigator` (or >> some other root object) considered? >> >> >> There is an issue >> <https://github.com/patcg-individual-drafts/topics/issues/71> for this, >> and I asked for advice >> <https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1137279345> >> on >> this on the TAG review but did not receive a response. We chose document at >> the time because the topics returned are conditional on the caller, and >> changing didn’t seem particularly compelling (e.g., it wasn’t abundantly >> clear where it should rightfully go). >> >> >> 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 > <https://privacysandbox.com/open-web/#the-privacy-sandbox-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 > <https://docs.google.com/document/d/1LdqUfUILyzM5WEcOgeAWGupQILKrZHidEXrUxevyi_Y/edit> > 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 > <https://docs.google.com/document/d/1RC-pBBvsazYfCNNUSkPqAVpSpNJ96U8trhNkfV0v9fk/edit#heading=h.x5bhg5grhfeo>. > 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 >> >> >> >>> >>> 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 >>>> <https://github.com/patcg-individual-drafts/topics/blob/main/topics-tester-list.md> >>>> and here >>>> <https://github.com/WICG/turtledove/blob/main/fledge-tester-list.md> >>>> 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 <yoavwe...@chromium.org> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Thu, Jun 22, 2023 at 4:05 PM Josh Karlin <jkar...@chromium.org> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> On Thu, Jun 22, 2023 at 7:49 AM Yoav Weiss <yoavwe...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> Thanks for working on this important problem! >>>>>>> >>>>>>> This API is an interesting one to think through, as it's quite >>>>>>> different from other APIs, even Privacy Sandbox ones. While most Privacy >>>>>>> Sandbox APIs carve out specific bits of entropy from 3P cookies to >>>>>>> enable >>>>>>> web functionality to continue to work, only with more targeted data, >>>>>>> Topics >>>>>>> seems to enable a use-case (targeted advertising) by moving some of the >>>>>>> targeting work from the server onto the user agent itself. >>>>>>> >>>>>>> In my view it makes sense to include "ecosystem health" into a broad >>>>>>> & holistic view of the user's needs, and hence it makes sense for the >>>>>>> user >>>>>>> agent to take on such work in order to enable ecosystem monetization, >>>>>>> *while >>>>>>> ensuring the user's agency*. Therefore, I think this is a fine >>>>>>> precedent to make, under the assumption the user indeed has agency and >>>>>>> is >>>>>>> making an informed decision about enabling this API and controlling >>>>>>> their >>>>>>> choice of Topics. At the same time, API owners are not UX experts, and >>>>>>> the >>>>>>> UX of whatever consent flow browsers end up shipping is a product >>>>>>> decision, >>>>>>> rather than a part of the Blink intent process. As a result, approving >>>>>>> this >>>>>>> API requires a certain amount of faith that different user-agents will >>>>>>> do >>>>>>> the right thing with it. But I guess that's already true for >>>>>>> permission-bound features, where we trust the UA's UX team to provide >>>>>>> appropriate mitigations for security and privacy risks. >>>>>>> >>>>>>> >>>>>>> On Wed, Jun 21, 2023 at 8:57 PM Josh Karlin <jkar...@chromium.org> >>>>>>> wrote: >>>>>>> >>>>>>>> Thanks for the questions Alex. Responses inline: >>>>>>>> >>>>>>>> >>>>>>>> > I don't see a full "considered alternatives" section in the >>>>>>>> Explainer. What other options were explored for this API and/or design? >>>>>>>> >>>>>>>> >>>>>>>> Yes. Before Topics we had another API, FLoC <https://web.dev/floc/>. >>>>>>>> We learned early on in the OT process that we did not want to move >>>>>>>> forward >>>>>>>> with it. Discussion of how FLoC migrated into Topics can be seen in >>>>>>>> this >>>>>>>> section >>>>>>>> <https://github.com/patcg-individual-drafts/topics#evolution-from-floc> >>>>>>>> of the explainer. >>>>>>>> >>>>>>> >>>>>>> I highly appreciate the evolution of the API and the many learnings >>>>>>> incorporated from the FLoC experiments. >>>>>>> >>>>>>> >>>>>>>> Another alternative would be to provide this sort of cross-site >>>>>>>> data only within a worklet, as Protected Audiences and Shared Storage >>>>>>>> do, >>>>>>>> and require that the ad be rendered within a fenced frame. An API like >>>>>>>> that >>>>>>>> is not off the table in the future, but at this stage we felt it >>>>>>>> prudent to >>>>>>>> make a simple API that could offer value in this space that has high >>>>>>>> levels >>>>>>>> of privacy in addition to the more complex and capable APIs that >>>>>>>> require >>>>>>>> private rendering. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > Does this naturally need to live on `document`? Was `navigator` >>>>>>>> (or some other root object) considered? >>>>>>>> >>>>>>>> >>>>>>>> There is an issue >>>>>>>> <https://github.com/patcg-individual-drafts/topics/issues/71> for >>>>>>>> this, and I asked for advice >>>>>>>> <https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1137279345> >>>>>>>> on this on the TAG review but did not receive a response. We chose >>>>>>>> document >>>>>>>> at the time because the topics returned are conditional on the caller, >>>>>>>> and >>>>>>>> changing didn’t seem particularly compelling (e.g., it wasn’t >>>>>>>> abundantly >>>>>>>> clear where it should rightfully go). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> > Is the name `browsingTopics` meant to signify that other sorts of >>>>>>>> topics may become available? If no, why not just `topics`? And if so, >>>>>>>> should that be a flag that's passed instead? >>>>>>>> >>>>>>>> >>>>>>>> We do not anticipate other *Topics APIs. At this point I honestly >>>>>>>> can’t remember how we landed on browsingTopics instead, but I know >>>>>>>> there >>>>>>>> was discussion. FWIW, it’s less likely to conflict with expando >>>>>>>> properties >>>>>>>> <https://github.com/search?q=document.topics+language%3AJavaScript&type=code>. >>>>>>>> Do you feel strongly about this? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> What feedback (if any) came from the OT? >>>>>>>> >>>>>>>> >>>>>>>> Lots! Criteo >>>>>>>> <https://medium.com/criteo-engineering/is-googles-topics-api-a-viable-replacement-for-interest-based-advertising-297076192bd> >>>>>>>> pointed out ~5 different things in their link that I have above that >>>>>>>> they’d >>>>>>>> like to see improved for utility, many of which are part of our future >>>>>>>> non-breaking plans. Others pointed out >>>>>>>> <https://github.com/patcg-individual-drafts/topics/issues/73> that >>>>>>>> the ratio of noised Topics was proportionate to reach, which wasn’t >>>>>>>> appropriate, so we fixed that. Yet others pointed out >>>>>>>> <https://github.com/patcg-individual-drafts/topics/issues/75> that >>>>>>>> it was easy to detect the random topic, so we fixed that. For more, >>>>>>>> please >>>>>>>> see the response to the “Web developers” section in “Risks” above. >>>>>>>> >>>>>>>> Josh >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Jun 21, 2023 at 12:06 PM Alex Russell < >>>>>>>> slightly...@chromium.org> wrote: >>>>>>>> >>>>>>>>> The spec looks well-written, and I'm dissapointed by the lack of >>>>>>>>> technical feedback from the TAG. >>>>>>>>> >>>>>>>>> Because the TAG doesn't seem to be engaging at the level of >>>>>>>>> platform consistency and quality in this review, I have some >>>>>>>>> questions of >>>>>>>>> the sort I try not to ask (in the hopes that the TAG has those bases >>>>>>>>> covered): >>>>>>>>> >>>>>>>>> >>>>>>>>> - I don't see a full "considered alternatives" section in the >>>>>>>>> Explainer. What other options were explored for this API and/or >>>>>>>>> design? >>>>>>>>> - Does this naturally need to live on `document`? Was >>>>>>>>> `navigator` (or some other root object) considered? >>>>>>>>> - Is the name `browsingTopics` meant to signify that other >>>>>>>>> sorts of topics may become available? If no, why not just >>>>>>>>> `topics`? And if >>>>>>>>> so, should that be a flag that's passed instead? >>>>>>>>> - What feedback (if any) came from the OT? >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> >>>>>>>>> Alex >>>>>>>>> >>>>>>>>> >>>>>>>>> On Tuesday, June 20, 2023 at 8:33:41 PM UTC-7 Domenic Denicola >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> I was the spec mentor for Yao's work on this feature, and am >>>>>>>>>> chiming in to provide the requested spec maturity summary >>>>>>>>>> <https://www.chromium.org/blink/launching-features/#:~:text=If%20your%20specification%20isn%27t%20a%20modification%20of%20an%20existing%20specification%2C%20include%20a%20one%2Dline%20spec%20maturity%20summary%20from%20someone%20outside%20your%20team%20(like%20your%20spec%20mentor)%20who%20has%20done%20a%20review.> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> I am very happy with the rigor of this specification. The >>>>>>>>>> algorithms and APIs are given in full detail, and I am as confident >>>>>>>>>> as I >>>>>>>>>> can be that another implementer would be able to follow and create an >>>>>>>>>> interoperable implementation. I'm also happy with how some of the >>>>>>>>>> design >>>>>>>>>> discussions went, e.g. we recently made changes to the >>>>>>>>>> Sec-Browsing-Topics >>>>>>>>>> HTTP request header which improved its parse-ability and robustness. >>>>>>>>>> >>>>>>>>>> The slicing of the specification into implementation-defined vs. >>>>>>>>>> interoperable behavior is tricky, and as Josh notes, can evolve over >>>>>>>>>> time. >>>>>>>>>> E.g. this PR >>>>>>>>>> <https://github.com/patcg-individual-drafts/topics/pull/203> proposes >>>>>>>>>> making the "top 5 topics" algorithm implementation-defined. (But, it >>>>>>>>>> keeps >>>>>>>>>> Chrome's version in a non-normative note, which I think is really >>>>>>>>>> helpful!) >>>>>>>>>> And there are browser vendor identifiers and version numbers baked >>>>>>>>>> into the >>>>>>>>>> return values of the spec. It's hard to say whether this setup will >>>>>>>>>> *guarantee* us the ability to evolve the API going forward, but >>>>>>>>>> I think the team has done a good job setting up the infrastructure >>>>>>>>>> to avoid >>>>>>>>>> any known failure modes. >>>>>>>>>> >>>>>>>>>> I will note that the open issues list >>>>>>>>>> <https://github.com/patcg-individual-drafts/topics/issues?q=is%3Aopen> >>>>>>>>>> for >>>>>>>>>> the specification is enormous, but my experience with Privacy Sandbox >>>>>>>>>> specifications is that their issues list turn into discussion forums >>>>>>>>>> pretty >>>>>>>>>> easily. I'm happy to trust the team's appraisal (under "Anticipate >>>>>>>>>> spec >>>>>>>>>> changes") that there aren't any open issues which will be significant >>>>>>>>>> disruptions to the specification. >>>>>>>>>> >>>>>>>>>> On Wed, Jun 21, 2023 at 2:40 AM Josh Karlin <jkar...@chromium.org> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Contact emails >>>>>>>>>>> >>>>>>>>>>> jkar...@chromium.org, yao...@chromium.org, >>>>>>>>>>> leeronisr...@google.com >>>>>>>>>>> >>>>>>>>>>> Explainer >>>>>>>>>>> >>>>>>>>>>> https://github.com/patcg-individual-drafts/topics >>>>>>>>>>> >>>>>>>>>> >>>>>>> That's a great explainer! One thing I found a bit lacking in it is >>>>>>> an outline of the use cases that this API tackles. Another question that >>>>>>> came to mind while reviewing other intents was around the differences in >>>>>>> use-cases between this and Protected Audience. Are they destined for >>>>>>> different kinds of advertisers? Different use cases? Something else? >>>>>>> >>>>>> >>>>>> They are indeed different use cases. Interest based advertising >>>>>> (Topics) is much broader (larger number of ads to choose from) than >>>>>> retargeting (Protected Audience). Interest based advertising allows an >>>>>> advertiser to say, "I'd like to advertise my product to people interested >>>>>> in these categories" whereas retargeting allows an advertiser to say, >>>>>> "this >>>>>> user was interested in some products on my page, I'd like to show them >>>>>> some >>>>>> more". You can imagine how it might be tractable to store metadata for >>>>>> the >>>>>> retargeting type ads on the users device, whereas it's less practical for >>>>>> interest based ads (easily millions of possible ads to select between). >>>>>> That is why Topics is quite limited in the information it can share since >>>>>> it needs to be made available to the caller, whereas Protected Audiences >>>>>> allows for more specific ad selection, but from a limited set of ads, and >>>>>> the ad must leverage private rendering. >>>>>> >>>>> >>>>> That's extremely useful, thanks!! (Maybe this can be added to the >>>>> explainer?) >>>>> >>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> >>>>>>>>>>> Specification >>>>>>>>>>> >>>>>>>>>>> https://patcg-individual-drafts.github.io/topics/ >>>>>>>>>>> >>>>>>>>>>> Summary >>>>>>>>>>> >>>>>>>>>>> The intent of the Topics API is to provide callers (including >>>>>>>>>>> third-party ad-tech or advertising providers on the page that run >>>>>>>>>>> script) >>>>>>>>>>> with coarse-grained advertising topics that the page visitor might >>>>>>>>>>> currently be interested in for the purposes of advertising. These >>>>>>>>>>> topics >>>>>>>>>>> will supplement the contextual signals from the current page and >>>>>>>>>>> can be >>>>>>>>>>> combined to help find an appropriate advertisement for the visitor >>>>>>>>>>> without >>>>>>>>>>> the advertiser having to track the user’s detailed browsing history >>>>>>>>>>> as is >>>>>>>>>>> done with third-party cookies and fingerprinting today. >>>>>>>>>>> >>>>>>>>>>> Blink Component >>>>>>>>>>> >>>>>>>>>>> Blink>TopicsAPI >>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ETopicsAPI> >>>>>>>>>>> >>>>>>>>>>> TAG Review >>>>>>>>>>> >>>>>>>>>>> Early design review for the Topics API · Issue #726 >>>>>>>>>>> <https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1379908459> >>>>>>>>>>> >>>>>>>>>>> TAG review status >>>>>>>>>>> >>>>>>>>>>> Pending >>>>>>>>>>> >>>>>>>>>>> Risks >>>>>>>>>>> >>>>>>>>>>> Interoperability and Compatibility >>>>>>>>>>> >>>>>>>>>>> Gecko: Negative ( >>>>>>>>>>> https://github.com/mozilla/standards-positions/issues/622) >>>>>>>>>>> >>>>>>>>>>> WebKit: Negative ( >>>>>>>>>>> https://github.com/WebKit/standards-positions/issues/111 >>>>>>>>>>> <https://github.com/WebKit/standards-positions/issues/111#issuecomment-1359609317> >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> To reduce risk in the event that we later decide to replace this >>>>>>>>>>> API with one that has more browser support, the API can be >>>>>>>>>>> effectively >>>>>>>>>>> disabled without breaking pages by rejecting the promise or >>>>>>>>>>> returning empty >>>>>>>>>>> lists of topics. >>>>>>>>>>> >>>>>>>>>>> Web developers: We’ve had significant OT participation >>>>>>>>>>> <https://github.com/patcg-individual-drafts/topics/blob/main/topics-tester-list.md> >>>>>>>>>>> and feedback in our periodic W3C PATCG calls >>>>>>>>>>> <https://github.com/patcg-individual-drafts/topics/tree/24c87897e32974c1328b74438feb97bf2ec43375/meetings>, >>>>>>>>>>> discussions on various GitHub issues >>>>>>>>>>> <https://github.com/patcg-individual-drafts/topics/issues>, >>>>>>>>>>> Chrome-facilitated office hours, discussion with industry trade >>>>>>>>>>> groups >>>>>>>>>>> representing a variety of stakeholder groups, and more. Some initial >>>>>>>>>>> feedback on utility has been published by Criteo >>>>>>>>>>> <https://medium.com/criteo-engineering/is-googles-topics-api-a-viable-replacement-for-interest-based-advertising-297076192bd>, >>>>>>>>>>> Google Ads >>>>>>>>>>> <https://github.com/google/ads-privacy/blob/master/Testing%20IBA%20with%20Privacy%20Preserving%20Signals.pdf> >>>>>>>>>>> and Retargetly >>>>>>>>>>> <https://retargetly.com/blog-en/a-brief-dive-into-retargetlys-experience-testing-googles-privacy-sandbox>. >>>>>>>>>>> We recently announced >>>>>>>>>>> <https://developer.chrome.com/blog/topics-enhancements/> >>>>>>>>>>> upcoming improvements to utility (not API surface changing) based >>>>>>>>>>> on that >>>>>>>>>>> initial feedback. >>>>>>>>>>> >>>>>>>>>>> Activation >>>>>>>>>>> >>>>>>>>>>> Starting in August 2023, enrollment >>>>>>>>>>> <https://developer.chrome.com/en/blog/announce-enrollment-privacy-sandbox/> >>>>>>>>>>> will be required to use the API. This is not a compat risk in the >>>>>>>>>>> sense >>>>>>>>>>> that the API will simply reject for callers if they are not >>>>>>>>>>> enrolled. >>>>>>>>>>> >>>>>>>>>>> Other signals: >>>>>>>>>>> >>>>>>>>>>> WebView application risks >>>>>>>>>>> >>>>>>>>>>> None >>>>>>>>>>> >>>>>>>>>>> Debuggability >>>>>>>>>>> >>>>>>>>>>> There is a useful internals page: chrome://topics-internals, >>>>>>>>>>> which shows the user’s current topics, allows for querying the API’s >>>>>>>>>>> classifier, and provides developer experimentation tooling. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Will this feature be supported on all six Blink platforms >>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)? >>>>>>>>>>> >>>>>>>>>>> All but WebView >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Is this feature fully tested by web-platform-tests >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>>>>>>>> ? >>>>>>>>>>> >>>>>>>>>>> IDL surface is tested >>>>>>>>>>> <https://wpt.fyi/results/browsing-topics?label=experimental&label=master&aligned>, >>>>>>>>>>> the actual returned topics are not as they are browser dependent. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Note for the failing tests: Chrome will roll out this feature >>>>>>>>>>> via Chrome Variations >>>>>>>>>>> <https://developer.chrome.com/docs/web-platform/chrome-variations/>, >>>>>>>>>>> rather than enabling the runtime features >>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/HEAD/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md> >>>>>>>>>>> directly. This means related WPTs need to be virtual, and it isn't >>>>>>>>>>> supported in wpt.fyi. >>>>>>>>>>> >>>>>>>>>>> Requires code in //chrome? >>>>>>>>>>> >>>>>>>>>>> No >>>>>>>>>>> >>>>>>>>>>> Launch bug >>>>>>>>>>> >>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1286877 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Anticipated spec changes >>>>>>>>>>> >>>>>>>>>>> As mentioned above, we anticipate changes to the classification >>>>>>>>>>> model, the taxonomy, the top topics selection algorithm, and >>>>>>>>>>> possibly some >>>>>>>>>>> parameters in the future as we try to improve the API’s utility >>>>>>>>>>> over time. >>>>>>>>>>> The API already provides version numbers with each returned topic >>>>>>>>>>> for each >>>>>>>>>>> of these features, as changes of this nature were anticipated from >>>>>>>>>>> the >>>>>>>>>>> beginning. These changes will not break sites. Developers may need >>>>>>>>>>> to >>>>>>>>>>> retrain their models and adapt to the new underlying algorithms, so >>>>>>>>>>> we will >>>>>>>>>>> announce the changes via channels such as blink-dev FYI as well as >>>>>>>>>>> on the >>>>>>>>>>> various support mailing lists. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Link to entry on the Chrome Platform Status >>>>>>>>>>> >>>>>>>>>>> https://chromestatus.com/feature/5680923054964736 >>>>>>>>>>> >>>>>>>>>>> Links to previous Intent discussions >>>>>>>>>>> >>>>>>>>>>> Intent to prototype: >>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/59uTw_dxM3M/m/vF9lF9BVAgAJ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Intent to experiment: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/oTwd6VwCwqs/m/pk7JPbXLAQAJ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Intent to extend origin trial: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/SD8Ot2gpz4g/m/A9uA-_cGAwAJ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/gpmaOi3of_w/m/SyMclFhMAAAJ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/CBrV-2DrYFI/m/RTojC6kHAgAJ >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> You received this message because you are subscribed to the >>>>>>>>>>> Google Groups "blink-dev" group. >>>>>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>>>>> it, send an email to blink-dev+unsubscr...@chromium.org. >>>>>>>>>>> To view this discussion on the web visit >>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaNc94moaqPPWepai4THP1rOvXoxvixS%3Dostu2QGMLPtvA%40mail.gmail.com >>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaNc94moaqPPWepai4THP1rOvXoxvixS%3Dostu2QGMLPtvA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>>>>> . >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>> You received this message because you are subscribed to the Google >>>>>>>>> Groups "blink-dev" group. >>>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>>>>> To view this discussion on the web visit >>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fae46cf2-dbf8-41bf-8e64-c7cfb6844c01n%40chromium.org >>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/fae46cf2-dbf8-41bf-8e64-c7cfb6844c01n%40chromium.org?utm_medium=email&utm_source=footer> >>>>>>>>> . >>>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "blink-dev" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaM1RZP4tKq4x7UvADOhYemyqtOhH5dgKUJK131sLWoS%3DA%40mail.gmail.com >>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaM1RZP4tKq4x7UvADOhYemyqtOhH5dgKUJK131sLWoS%3DA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>>> . >>>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "blink-dev" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to blink-dev+unsubscr...@chromium.org. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVbQDFhz_zmLHbm3DdN0nn8EtdmhfxFXbd4kYb%3DwOLmSQ%40mail.gmail.com >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfVbQDFhz_zmLHbm3DdN0nn8EtdmhfxFXbd4kYb%3DwOLmSQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>> >>>> >>>> -- >>>> 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+unsubscr...@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 >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAA6DcCfwqzyUNRW_f3JJCA_WtdJu036fSjphOp%2Bm4x3fmra6xQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+unsubscr...@chromium.org. >>> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY86BwABa2WTbf0_houXFuLaCWjVfHxWAmZ6nV4LFwb4KA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY86BwABa2WTbf0_houXFuLaCWjVfHxWAmZ6nV4LFwb4KA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to blink-dev+unsubscr...@chromium.org. > To view this discussion on the web visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9i%2Bc5diiGm9MBatSgvAQq8_cJa6c6aLtZdNioDKAY5Ew%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9i%2Bc5diiGm9MBatSgvAQq8_cJa6c6aLtZdNioDKAY5Ew%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAANMuaMh3gdczzseqr_7ZJA3BHqfCCZUwD35B-CjaG9tNm6qtQ%40mail.gmail.com.
