Actually CC Erik this time. On Fri, May 17, 2024 at 8:40 AM Paul Jensen <pauljen...@chromium.org> wrote:
> > > 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/CABQTWrnKbpfirkMOg0to73O%2BtCMkDTMyXFjyN%2Be8bbFqK%3DiWYw%40mail.gmail.com.
