Intent to Ship: Protected Audience: Downsampled forDebugOnly & Increase number of component ads

655 views
Skip to first unread message

Orr Bernstein

unread,
Feb 22, 2024, 12:07:10 PMFeb 22
to blink-dev, paulj...@chromium.org
Contact emails

paulj...@chromium.org


Explainer

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).


Blink component

Blink>InterestGroups


TAG review

The parent proposal, Protected Audience, is still pending: https://github.com/w3ctag/design-reviews/issues/723


TAG review status

Pending


Risks


Interoperability and Compatibility

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.


Debuggability

Use of both APIs is debuggable via DevTools debugging of Protected Audience bidding and scoring scripts.


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?

We plan to land web-platform-tests for both features shortly.


Flag name on chrome://flags

None


Finch feature name

FledgeEnableFilteringDebugReportStartingFrom, FledgeAdComponentLimit


Requires code in //chrome?

False


Estimated milestones

Shipping on desktop and Android in M122.


Anticipated spec changes

None related to these features.


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5099305180594176


This intent message was generated by Chrome Platform Status.


Yoav Weiss (@Shopify)

unread,
Feb 28, 2024, 12:24:35 PMFeb 28
to Orr Bernstein, blink-dev, paulj...@chromium.org
On Thu, Feb 22, 2024 at 6:07 PM 'Orr Bernstein' via blink-dev <blin...@chromium.org> wrote:
Contact emails

paulj...@chromium.org


Explainer

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?
 
--
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

unread,
Mar 4, 2024, 1:00:13 PMMar 4
to Yoav Weiss (@Shopify), Orr Bernstein, blink-dev
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 emails

paulj...@chromium.org


Explainer

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.

Yoav Weiss (@Shopify)

unread,
Mar 6, 2024, 12:07:53 PMMar 6
to Paul Jensen, Orr Bernstein, blink-dev
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 emails

paulj...@chromium.org


Explainer

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 

Paul Jensen

unread,
Mar 11, 2024, 4:21:36 PMMar 11
to Yoav Weiss (@Shopify), Orr Bernstein, blink-dev
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 emails

paulj...@chromium.org


Explainer

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 

WRT 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.

Yoav Weiss (@Shopify)

unread,
Mar 13, 2024, 11:45:09 AMMar 13
to blink-dev, Paul Jensen, Orr Bernstein, blink-dev, Yoav Weiss
LGTM1

On Monday, March 11, 2024 at 4:21:36 PM UTC-4 Paul Jensen wrote:
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 emails

paulj...@chromium.org


Explainer

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 

WRT 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.

Fair enough. I'd have loved more discussion on this, but it's not a blocker.
 
 


 
 
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Mike Taylor

unread,
Mar 13, 2024, 12:09:12 PMMar 13
to Yoav Weiss (@Shopify), blink-dev, Paul Jensen, Orr Bernstein

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

unread,
Mar 21, 2024, 1:06:49 PMMar 21
to Mike Taylor, Yoav Weiss (@Shopify), blink-dev, Paul Jensen, Orr Bernstein
Reply all
Reply to author
Forward
0 new messages