LGTM3
On 5/29/24 4:34 AM, Yoav Weiss (@Shopify) wrote:
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
<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 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
<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.