On Wed, May 15, 2024 at 8:36 AM Yoav Weiss (@Shopify) < yoavwe...@chromium.org> wrote:
> > > On Monday, May 6, 2024 at 10:03:16 PM UTC+2 Paul Jensen wrote: > > Contact emails > > pauljen...@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 > > <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 > <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EInterestGroups> > > > 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 > <https://github.com/mozilla/standards-positions/issues/770>, and in the > Webkit forum here > <https://github.com/WebKit/standards-positions/issues/158>. > > > Edge: Edge has announced plans to support the Ad Selection API > <https://github.com/WICG/privacy-preserving-ads/blob/main/README.md> > 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. > > > > Web developers: > > Protected Audience reporting timeouts: Multiple companies requesting on Github > issue <https://github.com/WICG/turtledove/issues/959> and WICG meeting > though notes > <https://github.com/WICG/turtledove/blob/main/meetings/2024-02-07-FLEDGE-call-minutes.md#topic-2-reporting-and-top-level-worklet-timeouts-httpsgithubcomwicgturtledoveissues959> > are missing several comments from others. > > Protected Audience multiple-bids: 3+ companies requesting on Github issue > <https://github.com/WICG/turtledove/issues/595>, discussed in 6 different WICG > meetings > <https://github.com/search?q=repo%3AWICG%2Fturtledove+path%3A%2F%5Emeetings%5C%2F%2F+595&type=code> > . > > > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ? > > 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 > <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+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrk0cyQboOmRBoq1QSs5hyfF4YSnYr6s7P6Z2CWQeAkPcA%40mail.gmail.com.
