PSA: Protected Audience k-Anonymity Enforcement

[Russ Hamilton]

We plan to start enabling the k-anonymity enforcement feature for the Protected Audience API (Intent to Ship). K-anonymity enforcement has long been a part of the Protected Audience API’s plan for improving user privacy by limiting ads that can win Protected Audience auctions to those ads that are k-anonymous. The k-anonymity enforcement feature limits the ability of advertisers to target specific users by requiring each ad be shown to a minimum number of users. This enforcement will initially apply to up to 20% of unlabeled traffic only, meaning the groups that are part of Chrome-facilitated testing for third-party cookie deprecation will not be enforced for k-anonymity during the testing period. After the testing period, enforcement will apply to all traffic (see timeline details at https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity).

[Mike Taylor]

Hi Russ,

Can you say more about the compatibility implications for such a change? AFAIU, things shouldn't "break" for users or throw errors behind the scenes, correct?

thanks,
Mike

On 1/26/24 12:59 AM, 'Russ Hamilton' via blink-dev wrote:

We plan to start enabling the k-anonymity enforcement feature for the Protected Audience API (Intent to Ship). K-anonymity enforcement has long been a part of the Protected Audience API’s plan for improving user privacy by limiting ads that can win Protected Audience auctions to those ads that are k-anonymous. The k-anonymity enforcement feature limits the ability of advertisers to target specific users by requiring each ad be shown to a minimum number of users. This enforcement will initially apply to up to 20% of unlabeled traffic only, meaning the groups that are part of Chrome-facilitated testing for third-party cookie deprecation will not be enforced for k-anonymity during the testing period. After the testing period, enforcement will apply to all traffic (see timeline details at https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/k-anonymity).

--
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/CAAG-DU2%3DfH8Q5gDDVms%2BajMA4WzS%3DvQBRPQj8jaiVzJkCdCz7g%40mail.gmail.com.

[Russ Hamilton]

Most users should not notice a difference. The main difference is going to be which ads are allowed to win Protected Audience auctions. Some non-k-anonymous ads that would have previously won the Protected Audience auction will not win and the auction will return a different, k-anonymous ad as the winner. In the case where there are no k-anonymous bids in an auction then that auction will return without a winner. Protected Audience auctions already return with no winner in some cases, such as when there are no bids, so this does not introduce a new behavior.

[Mike Taylor]

Thanks - it looks like there are no real compatibility concerns from perspective of sites _breaking_ for users. Given that, a PSA for this change sounds fine to me.

later,
Mike

[Russ Hamilton]

Recently, we became aware that Chrome was mistakenly applying k-anonymity enforcement on reporting to a portion of Mode A and Mode B testing traffic. This did not affect ad selection and therefore should have had little or no impact on auction dynamic or pressure.  To mitigate this issue, we briefly turned off k-anonymity enforcement on all Chrome traffic. We have landed a high confidence fix for this issue and have started ramping back up k-anonymity enforcement on eligible traffic1 that has the fix. 

The application of k-anonymity enforcement in Mode A and Mode B traffic did not affect ad selection, i.e. no winning ads were removed because the creative URLs were below the k-anonymity threshold and the creative URLs would continue to be available in reportWin() and reportResult().  The k-anonymity enforcement on reporting means that some Mode A and Mode B traffic may have been inadvertently missing interestGroupName, buyerReportingId, or buyerAndSellerReportingId in reportWin(), and buyerAndSellerReportingId in reportResult(), in cases where the value, when combined with the interest group owner, bidding script URL, and ad creative URL was not jointly k-anonymous. Adtech scripts should properly handle the lack of these values in reportWin() and reportResult() as they’ve always been intended and specified as optional and missing when they don’t meet the k-anonymity threshold. However, we understand that the current implementations may not have reached this stage of development.  Here’s a timeline of how k-anonymity enforcement was ramped:

Jan 24 - Feb 12	<1%
Feb 12 - Mar 7	<4%
Mar 7 - Mar 13	<13%
Mar 13 - Mar 22	1%
Mar 22 - Apr 2	k-anon enforcement disabled, ~0%
Apr 2	fix deployed, ramping back up, <1%

We have started ramping  k-anonymity enforcement up on pre-stable and plan to continue ramping on eligible traffic1. We apologize for the inconvenience caused by this disruption. 

1 Eligible traffic is pre-stable and stable channels, excluding Mode A and Mode B traffic.

Best,

--Benjamin "Russ" Hamilton

[Russ Hamilton]

FYI:

We are planning to ramp k-anonymity enforcement back up to 50% of eligible traffic on Beta channel later today.

Best,

--Benjamin "Russ" Hamilton

[Russ Hamilton]

FYI:

We are currently in the process of ramping k-anonymity enforcement back up to 1% of eligible traffic on Stable channel. As before, eligible traffic is pre-stable and stable channels, excluding Mode A and Mode B traffic.

Best,

--Benjamin "Russ" Hamilton