Intent to Ship: Protected Audience clearOriginJoinedAdInterestGroups() & interest group limit changes & kAnonStatus

[Paul Jensen]

Contact emails

paulj...@chromium.org

Explainer

clearOriginJoinedAdInterestGroups(): https://github.com/WICG/turtledove/pull/829

interest group limit changes: https://github.com/WICG/turtledove/pull/839

kAnonStatus: https://github.com/WICG/turtledove/pull/714

Specification

clearOriginJoinedAdInterestGroups(): https://github.com/WICG/turtledove/pull/844

interest group limit changes: https://github.com/WICG/turtledove/pull/859

kAnonStatus: https://github.com/WICG/turtledove/pull/858

Summary

clearOriginJoinedAdInterestGroups():

It can be helpful to leave all interest groups (IGs) that were joined on a particular top-frame origin (TFO). A site could keep track, in first-party state, of IGs they’ve joined on a particular TFO and leave each via the Protected Audience’s existing leaveAdInterestGroup() API, but there are ways the actual and presumed IG states could diverge. This feature adds a new API, clearOriginJoinedAdInterestGroups(), to explicitly leave all IGs joined on the calling TFO. This new API essentially resets the browser’s IG store for the calling TFO which can be useful to ensure the browser’s state is kept up to date and in sync with the IG owner’s expectations and prevent this divergence and not require the IG owners to keep track redundantly. 

interest group limit changes:

Chrome’s Protected Audience implementation limits the number of IGs that one IG owner can place the user into.  This limit originally served to limit user device storage resource usage and user device compute resources during auctions.  We found better, more accurate, and less biased ways to accomplish both of these goals without limiting the number of IGs that one owner can place the user into, namely switching to a size limit on all IGs and switching to a timeout on all IGs.  The limit on the number of IGs has again become a problem with the advent of negative targeting IGs that don’t use significant storage or compute resources.  We’re proposing raising the current limit to 2000 normal IGs and 20000 negative IGs.

kAnonStatus:

To help adtechs plan and measure in preparation for k-anonymity enforcement in Protected Audiences, the kAnonStatus API surfaces whether an ad is k-anonymous to event-level win reporting, prior to enforcing k-anonymity requirements.  This lets adtechs better understand how often their ads will meet the k-anonymity requirements.

Blink component

Blink>InterestGroups

TAG review

The parent proposal, Protected Audience, is still pending: https://github.com/w3ctag/design-reviews/issues/723

TAG review status

Pending

Risks

Interoperability and Compatibility

clearOriginJoinedAdInterestGroups() and kAnonStatus are new additional APIs so we do not expect them to cause compatibility breakage.  The interest group limit changes are increases from previous limits, so we do not expect them to cause compatibility breakage.

Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked in the Mozilla forum here, and in the Webkit forum here.

Web developers:

clearOriginJoinedAdInterestGroups() was requested and discussed here and discussed on a WICG Protected Audience call with notes here.

Interest group limit changes were requested and discussed here and here and here.

kAnonStatus is very important for k-anonymity planning and adoption which has been discussed many  times in the context of Protected Audience.  Here’s an old ask for similar behavior.

Debuggability

Calls to clearOriginJoinedAdInterestGroups() can be debugged in DevTools like other API calls, and also show up in the DevTools Application Storage Interest Group panel.

kAnonStatus is visible from DevTools debugging of reportWin() scripts.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

It will be supported on all platforms that support Protected Audience, so all but WebView.

Is this feature fully tested by web-platform-tests?

We plan to land web-platform-tests for all three features shortly.

Flag name on chrome://flags

None

Finch feature name

FledgeClearOriginJoinedAdInterestGroups, FledgePassKAnonStatusToReportWin, InterestGroupStorageMaxGroupsPerOwner

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop and Android in M119.

Anticipated spec changes

None related to these features.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/6751281490427904

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

Hi Paul,

On 10/19/23 7:01 PM, Paul Jensen wrote:

Contact emails

paulj...@chromium.org

Explainer

clearOriginJoinedAdInterestGroups(): https://github.com/WICG/turtledove/pull/829

interest group limit changes: https://github.com/WICG/turtledove/pull/839

kAnonStatus: https://github.com/WICG/turtledove/pull/714

Specification

clearOriginJoinedAdInterestGroups(): https://github.com/WICG/turtledove/pull/844

interest group limit changes: https://github.com/WICG/turtledove/pull/859

kAnonStatus: https://github.com/WICG/turtledove/pull/858

Noting that 2 of these PRs haven't landed yet.

Summary

clearOriginJoinedAdInterestGroups():

It can be helpful to leave all interest groups (IGs) that were joined on a particular top-frame origin (TFO). A site could keep track, in first-party state, of IGs they’ve joined on a particular TFO and leave each via the Protected Audience’s existing leaveAdInterestGroup() API, but there are ways the actual and presumed IG states could diverge. This feature adds a new API, clearOriginJoinedAdInterestGroups(), to explicitly leave all IGs joined on the calling TFO. This new API essentially resets the browser’s IG store for the calling TFO which can be useful to ensure the browser’s state is kept up to date and in sync with the IG owner’s expectations and prevent this divergence and not require the IG owners to keep track redundantly.

This comment was really helpful for me to understand this change: https://github.com/WICG/turtledove/issues/475#issuecomment-1720258511

interest group limit changes:

Chrome’s Protected Audience implementation limits the number of IGs that one IG owner can place the user into.  This limit originally served to limit user device storage resource usage and user device compute resources during auctions.  We found better, more accurate, and less biased ways to accomplish both of these goals without limiting the number of IGs that one owner can place the user into, namely switching to a size limit on all IGs and switching to a timeout on all IGs.  The limit on the number of IGs has again become a problem with the advent of negative targeting IGs that don’t use significant storage or compute resources.  We’re proposing raising the current limit to 2000 normal IGs and 20000 negative IGs.

I see that these limits are defined as implementation-specific. If another browser were to implement Protected Audience, what are the practical implications for different IG limits between browsers? Would sites need to write browser-specific code?

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWr%3Dj-J7P_pVgvdFyHAbki0_W_%2BVWxD%2BdswM20R6s%2BYi_aw%40mail.gmail.com.

[Orr Bernstein]

Sorry for the delay in response. All of the PRs have since landed.

Regarding your question on the interest group limit changes, these limits are intended to be guardrails against exceptional behavior, and not meant to be reached under normal conditions. In the best practices we previously published at https://developer.chrome.com/docs/privacy-sandbox/protected-audience-api/latency/#fewer-interest-groups-bidding, we encourage buyers to use fewer interest groups. Though other implementations may choose different specific values for these limits, they're intended to remain as guardrails; sites will not need to write browser-specific code to account for these.

Thanks.

[Yoav Weiss]

LGTM1

[Mike Taylor]

LGTM2

[Chris Harrelson]

LGTM3

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/675a94c2-d883-4faf-ae1e-1445e56e0ded%40chromium.org.

[Orr Bernstein]

Thank you, all!