LGTM1 to ship
On Fri, Jun 23, 2023 at 9:50 PM Josh Karlin <jkar...@chromium.org> wrote: > > > 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/CAL5BFfXcjw1ONZm-5Vr4e%3Dn6gAwt_m33HQ761f%2BZ2OQQj_ZWpw%40mail.gmail.com.
