LGTM1
On Wednesday, November 1, 2023 at 8:11:02 PM UTC+1 or...@google.com wrote:
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
<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.
On Wednesday, October 25, 2023 at 8:01:19 PM UTC-4
mike...@chromium.org wrote:
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
<https://github.com/WICG/turtledove/pull/829>
interest group limit changes:
https://github.com/WICG/turtledove/pull/839
<https://github.com/WICG/turtledove/pull/839>
kAnonStatus: https://github.com/WICG/turtledove/pull/714
<https://github.com/WICG/turtledove/pull/714>
Specification
clearOriginJoinedAdInterestGroups():
https://github.com/WICG/turtledove/pull/844
<https://github.com/WICG/turtledove/pull/844>
interest group limit changes:
https://github.com/WICG/turtledove/pull/859
<https://github.com/WICG/turtledove/pull/859>
kAnonStatus: https://github.com/WICG/turtledove/pull/858
<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
<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
<https://github.com/WICG/turtledove/issues/402#issuecomment-1488767847>and
switching to a timeout on all IGs
<https://github.com/WICG/turtledove/pull/328>. The limit on
the number of IGs has again become a problem with the advent
of negative targeting IGs
<https://github.com/WICG/turtledove/blob/main/FLEDGE.md#621-negative-interest-groups>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
<https://github.com/WICG/turtledove/pull/859/commits/8c0969ada20c8a64920ed5b3c36a7abdb5a006b8>.
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?
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
<https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInterestGroups>
TAG review
The parent proposal, Protected Audience, is still pending:
https://github.com/w3ctag/design-reviews/issues/723
<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 forumhere
<https://github.com/mozilla/standards-positions/issues/770>,
and in the Webkit forum here
<https://github.com/WebKit/standards-positions/issues/158>.
Web developers:
clearOriginJoinedAdInterestGroups() was requested and
discussed here
<https://github.com/WICG/turtledove/issues/475>and discussed
on a WICG Protected Audience call with notes here
<https://github.com/WICG/turtledove/blob/main/meetings/2023-06-21-FLEDGE-call-minutes.md#---leave-all-igs-for-a-given-domain-475-gianni-campion>.
Interest group limit changes were requested and discussed
here <https://github.com/WICG/turtledove/issues/402>and here
<https://github.com/WICG/turtledove/issues/361>and here
<https://github.com/WICG/turtledove/issues/798>.
kAnonStatus is very important for k-anonymity planning and
adoption which has been discussed many times in the context
of Protected Audience. Here’s
<https://github.com/WICG/turtledove/issues/121>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
<https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?
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
<https://chromestatus.com/feature/6751281490427904>
This intent message was generated by Chrome Platform Status
<https://chromestatus.com/>.
--
You received this message because you are subscribed to the
Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from
it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWr%3Dj-J7P_pVgvdFyHAbki0_W_%2BVWxD%2BdswM20R6s%2BYi_aw%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWr%3Dj-J7P_pVgvdFyHAbki0_W_%2BVWxD%2BdswM20R6s%2BYi_aw%40mail.gmail.com?utm_medium=email&utm_source=footer>.
