Intent to Ship: Protected Audience: Downsampled forDebugOnly & Increase number of component ads
Orr Bernstein
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1020
Increase number of component ads: https://github.com/WICG/turtledove/pull/1003
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1023
Increase number of component ads: https://github.com/WICG/turtledove/pull/1004
Downsampled forDebugOnly:
The forDebuggingOnly.reportAdAuctionWin() and forDebuggingOnly.reportAdAuctionLoss() (fDO) APIs were added to the Protected Audience (PA) API to allow debugging from within bidding and scoring scripts in PA auctions. We originally intended to remove these APIs at third-party cookie deprecation (3PCD) time, but received feedback that they were essential for doing root cause analysis in escalation situations (i.e. critical crash). Instead of removing debug reports entirely, we now plan to heavily downsample them at 3PCD time as follows: they will only send a report with a 1/1000 probability. Furthermore, if a report is sent, the browser will not send another for 3 years (“lockout”), and if a report is not sent (999/1000 of the time), future calls to the fDO API from the calling origin will be ignored for 2 weeks 90% of the time and 1 year 10% of the time (“cooldown”). To avoid biasing towards new browser installs (which aren’t in lockout or cooldown), we may place new browser installs initially in a shorter lockout period. For now, until 3PCD, we’ll expose whether a fDO caller is in the “lockout” or “cooldown” periods.
Increase number of component ads:
Today, PA allows selection of ads containing 20 component ads (aka product level ads). We plan to increase this number from 20 to 40 as we received feedback that ads with higher numbers of components were critical (e.g. for ads that rotate through 3 sets of 12 products).
The parent proposal, Protected Audience, is still pending: https://github.com/w3ctag/design-reviews/issues/723
Pending
Downsampled forDebugOnly: No expected breakage before 3PCD as the downsampling will not be performed until then. For now only the status of whether a fDO caller is in the “lockout” or “cooldown” periods is exposed. After 3PCD, the downsampling will surely disrupt some potential uses of the reporting channel, but this is an essential privacy requirement of the Protected Audience API.
Increase number of component ads: This is an increase to the limit, so no breakage is expected.
Gecko & WebKit: No signal on parent proposal, Protected Audience. Asked in the Mozilla forum here, and in the Webkit forum here.
Web developers:
Downsampled forDebugOnly: Discussed here and in person here.
Increase number of component ads: Discussed here and in person here.
Use of both APIs is debuggable via DevTools debugging of Protected Audience bidding and scoring scripts.
It will be supported on all platforms that support Protected Audience, so all but WebView.
We plan to land web-platform-tests for both features shortly.
None
FledgeEnableFilteringDebugReportStartingFrom, FledgeAdComponentLimit
False
Shipping on desktop and Android in M122.
None related to these features.
https://chromestatus.com/feature/5099305180594176
This intent message was generated by Chrome Platform Status.
Yoav Weiss (@Shopify)
Contact emailsExplainer
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1020
Increase number of component ads: https://github.com/WICG/turtledove/pull/1003
Specification
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1023
Increase number of component ads: https://github.com/WICG/turtledove/pull/1004
Summary
Downsampled forDebugOnly:
The forDebuggingOnly.reportAdAuctionWin() and forDebuggingOnly.reportAdAuctionLoss() (fDO) APIs were added to the Protected Audience (PA) API to allow debugging from within bidding and scoring scripts in PA auctions. We originally intended to remove these APIs at third-party cookie deprecation (3PCD) time, but received feedback that they were essential for doing root cause analysis in escalation situations (i.e. critical crash). Instead of removing debug reports entirely, we now plan to heavily downsample them at 3PCD time as follows: they will only send a report with a 1/1000 probability. Furthermore, if a report is sent, the browser will not send another for 3 years (“lockout”), and if a report is not sent (999/1000 of the time), future calls to the fDO API from the calling origin will be ignored for 2 weeks 90% of the time and 1 year 10% of the time (“cooldown”). To avoid biasing towards new browser installs (which aren’t in lockout or cooldown), we may place new browser installs initially in a shorter lockout period. For now, until 3PCD, we’ll expose whether a fDO caller is in the “lockout” or “cooldown” periods.
Increase number of component ads:
Today, PA allows selection of ads containing 20 component ads (aka product level ads). We plan to increase this number from 20 to 40 as we received feedback that ads with higher numbers of components were critical (e.g. for ads that rotate through 3 sets of 12 products).
--
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+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/d5ba8ace-8a65-461f-9124-9fcd7a232c26n%40chromium.org.
Paul Jensen
On Thu, Feb 22, 2024 at 6:07 PM 'Orr Bernstein' via blink-dev <blin...@chromium.org> wrote:Contact emailsExplainer
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1020
Increase number of component ads: https://github.com/WICG/turtledove/pull/1003
Specification
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1023
Increase number of component ads: https://github.com/WICG/turtledove/pull/1004
Summary
Downsampled forDebugOnly:
The forDebuggingOnly.reportAdAuctionWin() and forDebuggingOnly.reportAdAuctionLoss() (fDO) APIs were added to the Protected Audience (PA) API to allow debugging from within bidding and scoring scripts in PA auctions. We originally intended to remove these APIs at third-party cookie deprecation (3PCD) time, but received feedback that they were essential for doing root cause analysis in escalation situations (i.e. critical crash). Instead of removing debug reports entirely, we now plan to heavily downsample them at 3PCD time as follows: they will only send a report with a 1/1000 probability. Furthermore, if a report is sent, the browser will not send another for 3 years (“lockout”), and if a report is not sent (999/1000 of the time), future calls to the fDO API from the calling origin will be ignored for 2 weeks 90% of the time and 1 year 10% of the time (“cooldown”). To avoid biasing towards new browser installs (which aren’t in lockout or cooldown), we may place new browser installs initially in a shorter lockout period. For now, until 3PCD, we’ll expose whether a fDO caller is in the “lockout” or “cooldown” periods.
Increase number of component ads:
Today, PA allows selection of ads containing 20 component ads (aka product level ads). We plan to increase this number from 20 to 40 as we received feedback that ads with higher numbers of components were critical (e.g. for ads that rotate through 3 sets of 12 products).
Can you expand on the implications of increasing that number? What's the tradeoff involved?
Yoav Weiss (@Shopify)
On Wed, Feb 28, 2024 at 12:24 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:On Thu, Feb 22, 2024 at 6:07 PM 'Orr Bernstein' via blink-dev <blin...@chromium.org> wrote:Contact emailsExplainer
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1020
Increase number of component ads: https://github.com/WICG/turtledove/pull/1003
Specification
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1023
Increase number of component ads: https://github.com/WICG/turtledove/pull/1004
Summary
Downsampled forDebugOnly:
The forDebuggingOnly.reportAdAuctionWin() and forDebuggingOnly.reportAdAuctionLoss() (fDO) APIs were added to the Protected Audience (PA) API to allow debugging from within bidding and scoring scripts in PA auctions. We originally intended to remove these APIs at third-party cookie deprecation (3PCD) time, but received feedback that they were essential for doing root cause analysis in escalation situations (i.e. critical crash). Instead of removing debug reports entirely, we now plan to heavily downsample them at 3PCD time as follows: they will only send a report with a 1/1000 probability. Furthermore, if a report is sent, the browser will not send another for 3 years (“lockout”), and if a report is not sent (999/1000 of the time), future calls to the fDO API from the calling origin will be ignored for 2 weeks 90% of the time and 1 year 10% of the time (“cooldown”). To avoid biasing towards new browser installs (which aren’t in lockout or cooldown), we may place new browser installs initially in a shorter lockout period. For now, until 3PCD, we’ll expose whether a fDO caller is in the “lockout” or “cooldown” periods.
Increase number of component ads:
Today, PA allows selection of ads containing 20 component ads (aka product level ads). We plan to increase this number from 20 to 40 as we received feedback that ads with higher numbers of components were critical (e.g. for ads that rotate through 3 sets of 12 products).
Can you expand on the implications of increasing that number? What's the tradeoff involved?As discussed on github here and in person here, we've heard from adtechs that large portions of their ad inventory cannot be displayed without allowing higher numbers of component ads, so increasing this number restores more publisher site revenue. The downsides to increasing this number are fairly minor: There's a negligible privacy impact as the component ads are not shared with PA reporting scripts, are required to be k-anonymous, and when displayed, each component ad can be isolated from each other in separate Fenced Frames.
Paul Jensen
On Mon, Mar 4, 2024 at 7:00 PM Paul Jensen <paulj...@chromium.org> wrote:On Wed, Feb 28, 2024 at 12:24 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:On Thu, Feb 22, 2024 at 6:07 PM 'Orr Bernstein' via blink-dev <blin...@chromium.org> wrote:Contact emailsExplainer
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1020
Increase number of component ads: https://github.com/WICG/turtledove/pull/1003
Specification
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1023
Increase number of component ads: https://github.com/WICG/turtledove/pull/1004
Summary
Downsampled forDebugOnly:
The forDebuggingOnly.reportAdAuctionWin() and forDebuggingOnly.reportAdAuctionLoss() (fDO) APIs were added to the Protected Audience (PA) API to allow debugging from within bidding and scoring scripts in PA auctions. We originally intended to remove these APIs at third-party cookie deprecation (3PCD) time, but received feedback that they were essential for doing root cause analysis in escalation situations (i.e. critical crash). Instead of removing debug reports entirely, we now plan to heavily downsample them at 3PCD time as follows: they will only send a report with a 1/1000 probability. Furthermore, if a report is sent, the browser will not send another for 3 years (“lockout”), and if a report is not sent (999/1000 of the time), future calls to the fDO API from the calling origin will be ignored for 2 weeks 90% of the time and 1 year 10% of the time (“cooldown”). To avoid biasing towards new browser installs (which aren’t in lockout or cooldown), we may place new browser installs initially in a shorter lockout period. For now, until 3PCD, we’ll expose whether a fDO caller is in the “lockout” or “cooldown” periods.
Increase number of component ads:
Today, PA allows selection of ads containing 20 component ads (aka product level ads). We plan to increase this number from 20 to 40 as we received feedback that ads with higher numbers of components were critical (e.g. for ads that rotate through 3 sets of 12 products).
Can you expand on the implications of increasing that number? What's the tradeoff involved?As discussed on github here and in person here, we've heard from adtechs that large portions of their ad inventory cannot be displayed without allowing higher numbers of component ads, so increasing this number restores more publisher site revenue. The downsides to increasing this number are fairly minor: There's a negligible privacy impact as the component ads are not shared with PA reporting scripts, are required to be k-anonymous, and when displayed, each component ad can be isolated from each other in separate Fenced Frames.I understand the benefits of increasing the number of ads, but are there any pointers to past discussion/analysis RE the privacy impact? I understand it's not huge (and it's not my role to judge the privacy risk - that's what the privacy review is for). I'd just love to better understand this :D
Yoav Weiss (@Shopify)
On Wed, Mar 6, 2024 at 12:07 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:On Mon, Mar 4, 2024 at 7:00 PM Paul Jensen <paulj...@chromium.org> wrote:On Wed, Feb 28, 2024 at 12:24 PM Yoav Weiss (@Shopify) <yoav...@chromium.org> wrote:On Thu, Feb 22, 2024 at 6:07 PM 'Orr Bernstein' via blink-dev <blin...@chromium.org> wrote:Contact emailsExplainer
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1020
Increase number of component ads: https://github.com/WICG/turtledove/pull/1003
Specification
Downsampled forDebugOnly: https://github.com/WICG/turtledove/pull/1023
Increase number of component ads: https://github.com/WICG/turtledove/pull/1004
Summary
Downsampled forDebugOnly:
The forDebuggingOnly.reportAdAuctionWin() and forDebuggingOnly.reportAdAuctionLoss() (fDO) APIs were added to the Protected Audience (PA) API to allow debugging from within bidding and scoring scripts in PA auctions. We originally intended to remove these APIs at third-party cookie deprecation (3PCD) time, but received feedback that they were essential for doing root cause analysis in escalation situations (i.e. critical crash). Instead of removing debug reports entirely, we now plan to heavily downsample them at 3PCD time as follows: they will only send a report with a 1/1000 probability. Furthermore, if a report is sent, the browser will not send another for 3 years (“lockout”), and if a report is not sent (999/1000 of the time), future calls to the fDO API from the calling origin will be ignored for 2 weeks 90% of the time and 1 year 10% of the time (“cooldown”). To avoid biasing towards new browser installs (which aren’t in lockout or cooldown), we may place new browser installs initially in a shorter lockout period. For now, until 3PCD, we’ll expose whether a fDO caller is in the “lockout” or “cooldown” periods.
Increase number of component ads:
Today, PA allows selection of ads containing 20 component ads (aka product level ads). We plan to increase this number from 20 to 40 as we received feedback that ads with higher numbers of components were critical (e.g. for ads that rotate through 3 sets of 12 products).
Can you expand on the implications of increasing that number? What's the tradeoff involved?As discussed on github here and in person here, we've heard from adtechs that large portions of their ad inventory cannot be displayed without allowing higher numbers of component ads, so increasing this number restores more publisher site revenue. The downsides to increasing this number are fairly minor: There's a negligible privacy impact as the component ads are not shared with PA reporting scripts, are required to be k-anonymous, and when displayed, each component ad can be isolated from each other in separate Fenced Frames.I understand the benefits of increasing the number of ads, but are there any pointers to past discussion/analysis RE the privacy impact? I understand it's not huge (and it's not my role to judge the privacy risk - that's what the privacy review is for). I'd just love to better understand this :DWRT the privacy impact, as it's negligible, there isn't much to discuss so there isn't much prior discussion/analysis other than in this email thread and in the two links I posted before. If there's some aspect you'd like to discuss further or dig into more, I'm happy to engage.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.
Mike Taylor
LGTM2
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/1129ace3-a003-4273-a731-b0359c8a6f87n%40chromium.org.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6333cedd-6ced-427b-9951-fae81c2698c6%40chromium.org.