LGTM1 On Tue, May 21, 2024 at 3:07 PM 'Erik Anderson' via blink-dev < blink-dev@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 <pauljen...@chromium.org> > *Sent:* Friday, May 17, 2024 5:42 AM > *To:* Yoav Weiss (@Shopify) <yoavwe...@chromium.org> > *Cc:* blink-dev <blink-dev@chromium.org>; Erik Anderson < > erik.ander...@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 <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 > > 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/BY5PR00MB0823537D831A5D4E2C1E6997F4EA2%40BY5PR00MB0823.namprd00.prod.outlook.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/BY5PR00MB0823537D831A5D4E2C1E6997F4EA2%40BY5PR00MB0823.namprd00.prod.outlook.com?utm_medium=email&utm_source=footer> > . > -- 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/CAOMQ%2Bw8qYwTP4KwZ_%2BZKLyvz73w6oODDvys4QyJ7rG19p%3DyyOg%40mail.gmail.com.
