Intent to Ship: Protected Audience: reporting timeouts & multiple-bids

[Paul Jensen]

Contact emails

paulj...@chromium.org

Explainer

Protected Audience reporting timeouts: https://github.com/WICG/turtledove/pull/1101

Protected Audience multiple-bids: https://github.com/WICG/turtledove/pull/1048

Specification

Protected Audience reporting timeouts: https://github.com/WICG/turtledove/pull/1102

Protected Audience multiple-bids: https://github.com/WICG/turtledove/pull/1138

Summary

Protected Audience (PA) reporting timeouts:

After a PA auction finishes selecting an ad and that ad is allowed to start rendering, the browser then runs a JavaScript function from the seller(s) and winning buyer to assemble reports that are sent back to their servers. These functions are currently given 50ms to run, after which they're aborted. We've heard feedback from users of the API that 50ms may not be sufficient to assemble the reports and may result in broken billing and other basic functionality, resulting in lower website revenue.  We’re proposing making the timeout configurable up to 5s. (This JavaScript generally runs in a separate process, i.e. off the main thread.)

Protected Audience multiple-bids:

Presently buyers participating in PA ad selection auctions are only allowed to return one bid per interest group stored on a user's device. This has a couple downsides:

1. When that one bid does not pass the k-anonymity threshold, the bid generation logic must be invoked again which can be slow, potentially doubling auction runtime.

2. This preferences adtechs that store more interest groups on device as a way to get more bids into the auction. Many interest groups on device is something we publicly have stated is undesirable: https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/latency#fewer_interest_group_owners

To fix this we're allowing bidding scripts to return multiple bids.

Blink component

Blink>InterestGroups

TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723

TAG review status

Completed for Protected Audience, resolved unsatisfied.

Risks

Interoperability and Compatibility

Both features represent optional new behavior that shouldn’t break existing usage.

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

Edge: Edge has announced plans to support the Ad Selection API which shares much of its API surface with Protected Audience.

Web developers:

Protected Audience reporting timeouts: Multiple companies requesting on Github issue and WICG meeting though notes are missing several comments from others.

Protected Audience multiple-bids: 3+ companies requesting on Github issue, discussed in 6 different WICG meetings.

Debuggability

PA reporting and bidding scripts are debuggable in DevTools.  Generated bids also show up in the Application -> Storage -> Interest Groups DevTools pane.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, 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 both features shortly.

Flag name on chrome://flags

None

Finch feature name

FledgeReportingTimeout, FledgeMultiBid

Requires code in //chrome?

False

Estimated milestones

Shipping on desktop and Android in M124.

Anticipated spec changes

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5095020001755136

This intent message was generated by Chrome Platform Status.

[Yoav Weiss (@Shopify)]

On Monday, May 6, 2024 at 10:03:16 PM UTC+2 Paul Jensen wrote:

Contact emails

paulj...@chromium.org

Explainer

Protected Audience reporting timeouts: https://github.com/WICG/turtledove/pull/1101

Protected Audience multiple-bids: https://github.com/WICG/turtledove/pull/1048

Specification

Protected Audience reporting timeouts: https://github.com/WICG/turtledove/pull/1102

Protected Audience multiple-bids: https://github.com/WICG/turtledove/pull/1138

Summary

Protected Audience (PA) reporting timeouts:

After a PA auction finishes selecting an ad and that ad is allowed to start rendering, the browser then runs a JavaScript function from the seller(s) and winning buyer to assemble reports that are sent back to their servers. These functions are currently given 50ms to run, after which they're aborted. We've heard feedback from users of the API that 50ms may not be sufficient to assemble the reports and may result in broken billing and other basic functionality, resulting in lower website revenue.  We’re proposing making the timeout configurable up to 5s. (This JavaScript generally runs in a separate process, i.e. off the main thread.)

I'm concerned about this timeout, tbh.

It feels very arbitrary and if set by the wrong party, it can create some adversarial effects.

Can you expand on why do we need a configurable timeout here, rather than just increasing it for everyone?

If a configurable timeout is indeed needed, am I correct that the timeout would be set by the publisher, and its consequences would be felt by the seller?

Also, can you expand on "This JavaScript generally runs in a separate process"? Where is it run?

Protected Audience multiple-bids:

Presently buyers participating in PA ad selection auctions are only allowed to return one bid per interest group stored on a user's device. This has a couple downsides:

1. When that one bid does not pass the k-anonymity threshold, the bid generation logic must be invoked again which can be slow, potentially doubling auction runtime.

2. This preferences adtechs that store more interest groups on device as a way to get more bids into the auction. Many interest groups on device is something we publicly have stated is undesirable: https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/latency#fewer_interest_group_owners

To fix this we're allowing bidding scripts to return multiple bids.

Blink component

Blink>InterestGroups

TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723

TAG review status

Completed for Protected Audience, resolved unsatisfied.

RisksInteroperability and Compatibility

Both features represent optional new behavior that shouldn’t break existing usage.

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

Edge: Edge has announced plans to support the Ad Selection API which shares much of its API surface with Protected Audience.

I'd love for the Edge team to review this, if at all possible.

I know it's exceeding the bounds of our process, but given the lack of interest in reviewing this from the TAG, Mozilla and Apple, and the ongoing complexity of this feature, it's be great to try and get some deep technical review from a different browser team.

[Paul Jensen]

On Wed, May 15, 2024 at 8:36 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

On Monday, May 6, 2024 at 10:03:16 PM UTC+2 Paul Jensen wrote:

Contact emails

paulj...@chromium.org

Explainer

Protected Audience reporting timeouts: https://github.com/WICG/turtledove/pull/1101

Protected Audience multiple-bids: https://github.com/WICG/turtledove/pull/1048

Specification

Protected Audience reporting timeouts: https://github.com/WICG/turtledove/pull/1102

Protected Audience multiple-bids: https://github.com/WICG/turtledove/pull/1138

Summary

Protected Audience (PA) reporting timeouts:

After a PA auction finishes selecting an ad and that ad is allowed to start rendering, the browser then runs a JavaScript function from the seller(s) and winning buyer to assemble reports that are sent back to their servers. These functions are currently given 50ms to run, after which they're aborted. We've heard feedback from users of the API that 50ms may not be sufficient to assemble the reports and may result in broken billing and other basic functionality, resulting in lower website revenue.  We’re proposing making the timeout configurable up to 5s. (This JavaScript generally runs in a separate process, i.e. off the main thread.)

I'm concerned about this timeout, tbh.

It feels very arbitrary and if set by the wrong party, it can create some adversarial effects.

Can you expand on why do we need a configurable timeout here, rather than just increasing it for everyone?

I think configurability is useful here for a few reasons:

1. There are potentially three different variables that may determine the optimal setting of this timeout:

1. Different devices may have different execution performance, so a fixed timeout across all devices may be suboptimal.

2. Different publisher pages may have different execution requirements.  Some may be sensitive to how much execution time is allowed for these reporting scripts, so a fixed timeout across all publisher pages may be suboptimal.

3. Different auction participants may have different execution requirements.  Some may be sensitive to how much execution time is given for them to complete execution of their reporting scripts.

2. Making it configurable allows callers of the API to experiment and tune to find the optimal timeout for particular situations.

3. Changing the default timeout could potentially upset ongoing experimentation.

 

If a configurable timeout is indeed needed, am I correct that the timeout would be set by the publisher, and its consequences would be felt by the seller?

It’s set by whoever is initiating the auction.  This could be anyone on the publisher page, including the publisher or a seller acting on their behalf. 

Also, can you expand on "This JavaScript generally runs in a separate process"? Where is it run?

On desktop, we use one process to run all bidding and scoring scripts for one origin, and that gets used for this reporting step also.  On Android, where system resources are more constrained, we use site-isolation’s heuristics to pick an appropriate process for each origin’s scripts. 

Protected Audience multiple-bids:

Presently buyers participating in PA ad selection auctions are only allowed to return one bid per interest group stored on a user's device. This has a couple downsides:

1. When that one bid does not pass the k-anonymity threshold, the bid generation logic must be invoked again which can be slow, potentially doubling auction runtime.

2. This preferences adtechs that store more interest groups on device as a way to get more bids into the auction. Many interest groups on device is something we publicly have stated is undesirable: https://developers.google.com/privacy-sandbox/relevance/protected-audience-api/latency#fewer_interest_group_owners

To fix this we're allowing bidding scripts to return multiple bids.

Blink component

Blink>InterestGroups

TAG review

For Protected Audience: https://github.com/w3ctag/design-reviews/issues/723

TAG review status

Completed for Protected Audience, resolved unsatisfied.

RisksInteroperability and Compatibility

Both features represent optional new behavior that shouldn’t break existing usage.

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

Edge: Edge has announced plans to support the Ad Selection API which shares much of its API surface with Protected Audience.

I'd love for the Edge team to review this, if at all possible.

I know it's exceeding the bounds of our process, but given the lack of interest in reviewing this from the TAG, Mozilla and Apple, and the ongoing complexity of this feature, it's be great to try and get some deep technical review from a different browser team.

Sounds like a great idea; we’ve reached out to, and CC'd, Erik Anderson for comment. 

[Paul Jensen]

Actually CC Erik this time.

[Erik Anderson]

Hi,

 

Thanks for reaching out.

 

We’ve reviewed the proposal and don’t have any significant concerns. We’ll continue providing feedback via GitHub where appropriate.

 

Thanks,

Erik

[Chris Harrelson]

LGTM1

--
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/BY5PR00MB0823537D831A5D4E2C1E6997F4EA2%40BY5PR00MB0823.namprd00.prod.outlook.com.

[Yoav Weiss (@Shopify)]

LGTM2

On Thursday, May 23, 2024 at 1:01:53 AM UTC+2 Chris Harrelson wrote:

LGTM1

On Tue, May 21, 2024 at 3:07 PM 'Erik Anderson' via blink-dev <blin...@chromium.org> wrote:

Hi,

 

Thanks for reaching out.

 

We’ve reviewed the proposal and don’t have any significant concerns. We’ll continue providing feedback via GitHub where appropriate.

 

Thanks,

Erik

 

From: Paul Jensen <paulj...@chromium.org>
Sent: Friday, May 17, 2024 5:42 AM
To: Yoav Weiss (@Shopify) <yoav...@chromium.org>
Cc: blink-dev <blin...@chromium.org>; Erik Anderson <Erik.A...@microsoft.com>
Subject: Re: Intent to Ship: Protected Audience: reporting timeouts & multiple-bids

 

Actually CC Erik this time.

 

On Fri, May 17, 2024 at 8:40 AM Paul Jensen <paulj...@chromium.org> wrote:

 

 

On Wed, May 15, 2024 at 8:36 AM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:

 

On Monday, May 6, 2024 at 10:03:16 PM UTC+2 Paul Jensen wrote:

Contact emails

paulj...@chromium.org

 

Explainer

Protected Audience reporting timeouts: https://github.com/WICG/turtledove/pull/1101

Protected Audience multiple-bids: https://github.com/WICG/turtledove/pull/1048

Please fix the explainer to remove the "in Chrome" part from the feature detection reference. 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Mike Taylor]

LGTM3

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/c1230052-6a54-49a9-833e-d6dedd1a49c3n%40chromium.org.