LGTM3 On 5/29/24 4:34 AM, Yoav Weiss (@Shopify) wrote:
LGTM2On 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 <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 <https://github.com/WICG/turtledove/pull/1101> Protected Audience multiple-bids: https://github.com/WICG/turtledove/pull/1048 <https://github.com/WICG/turtledove/pull/1048>Please fix the explainer <https://github.com/WICG/turtledove/pull/1048/files#r1615583702> to remove the "in Chrome" part from the feature detection reference.Specification Protected Audience reporting timeouts: https://github.com/WICG/turtledove/pull/1102 <https://github.com/WICG/turtledove/pull/1102> Protected Audience multiple-bids: https://github.com/WICG/turtledove/pull/1138 <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. 1. Different devices may have different execution performance, so a fixed timeout across all devices may be suboptimal. 1. 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. 1. 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 <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 forumhere <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 <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 theGoogle Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org <mailto: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/c1230052-6a54-49a9-833e-d6dedd1a49c3n%40chromium.org <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c1230052-6a54-49a9-833e-d6dedd1a49c3n%40chromium.org?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/b79fa9bf-3912-411e-8c7a-99e2817682fa%40chromium.org.
