[blink-dev] Intent to Experiment: Protected Audience Bidding & Auction Services

[Paul Jensen]

Contact emails

pauljen...@chromium.org, behamil...@google.com

Explainer

Chrome:
https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md

Services:
https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md

Note that this explainer has a helpful onboarding section

for setting up the services.

Specification

May be influenced by Origin Trial feedback, so not yet started.  Protected
Audience auctions running on Bidding & Auction Services provide
functionality very similar to existing on-device auctions so much of the
existing spec  applies.

Summary

The Protected Audience API (formerly known as FLEDGE) is a Privacy Sandbox
proposal to serve remarketing and custom audience use cases, designed so
third parties cannot track user browsing behavior across sites. This
proposal, the Protected Audience Bidding & Auction Services proposal,
outlines a way to allow Protected Audience computation to take place on
cloud servers in a Trusted Execution Environment (TEE), rather than running
locally on a user's device. Moving computation to cloud servers can help
optimize the Protected Audience auction, and free up computational cycles
and network bandwidth for a device.

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

RisksInteroperability and Compatibility

None. This is an optional new feature of the Protected Audience API. Ad
techs can use this new feature by calling
navigator.getInterestGroupAdAuctionData() and specifying values for new
fields in the auction config. Without invoking the new function or explicit
values for those new fields, there's no functional behavioral change as a
result of this feature.

Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked in
the Mozilla forum here
, and in the
Webkit forum here 
.

Web developers: Extensive interest in this feature from adtechs, evidenced
by the myriad of discussions on Protected Audience’s issue tracker
 and weekly WICG calls
.

Goals for experimentation

Operating Bidding and Auction services in TEEs represents a major shift
from running Protected Audience auctions inside the browser.  During this
Origin Trial we’d like to gain confidence that this is possible to do at
scale and in a performant manner.  We want feedback on new API surfaces and
how these servers are operated.

Debuggability

On-device API surfaces should be debuggable in Chrome DevTools, and we’ve
added extensive mechanisms for debugging Bidding and Auction services

.

Will this feature be supported on all six Blink platforms (Windows, Mac,
Linux, Chrome OS, 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

?

No. More web-platform-test

coverage is expected when the specification is closer to completion.

Flag name on chrome://flags

Overall control is not possible via chrome://flags, though the consented
debugging support

is controlled via chrome://flags/#protected-audience-debug-token

Finch feature name

FledgeBiddingAndAuctionServerAPI

Requires code in //chrome?

Only for UI for the consented debugging support

.

Estimated milestones

We hope to start the Origin Trial sometime during M119 beta. We plan to
continue the Origin Trial for at least three milestones to give developers
time to test the API and provide feedback. Once we are confident that the
APIs are working properly, we will transition the OT from beta to stable
channel.

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/4649601971257344

Links to previous Intent discussions

Intent to prototype:
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrnSdvf7RgK2wxsmC6rWc8eRoqDZOvgwVFuEx1r2nqmAJg%40mail.gmail.com

This intent message was generated by Chrome Platform S

Re: [blink-dev] Intent to Experiment: Protected Audience Bidding & Auction Services

[Chris Harrelson]

Please fill out and start the reviews for Privacy, Security and
Debuggability in your chromestatus entry, thanks.

On Thu, Oct 12, 2023 at 3:40 PM Paul Jensen  wrote:

> Contact emails
>
> pauljen...@chromium.org, behamil...@google.com
>
> Explainer
>
> Chrome:
> https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md
>
> Services:
> https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md
>
> Note that this explainer has a helpful onboarding section
> 
> for setting up the services.
>
> Specification
>
> May be influenced by Origin Trial feedback, so not yet started.  Protected
> Audience auctions running on Bidding & Auction Services provide
> functionality very similar to existing on-device auctions so much of the
> existing spec  applies.
>
> Summary
>
> The Protected Audience API (formerly known as FLEDGE) is a Privacy Sandbox
> proposal to serve remarketing and custom audience use cases, designed so
> third parties cannot track user browsing behavior across sites. This
> proposal, the Protected Audience Bidding & Auction Services proposal,
> outlines a way to allow Protected Audience computation to take place on
> cloud servers in a Trusted Execution Environment (TEE), rather than running
> locally on a user's device. Moving computation to cloud servers can help
> optimize the Protected Audience auction, and free up computational cycles
> and network bandwidth for a device.
>
> 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
>
> RisksInteroperability and Compatibility
>
> None. This is an optional new feature of the Protected Audience API. Ad
> techs can use this new feature by calling
> navigator.getInterestGroupAdAuctionData() and specifying values for new
> fields in the auction config. Without invoking the new function or explicit
> values for those new fields, there's no functional behavioral change as a
> result of this feature.
>
> Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked
> in the Mozilla forum here
> , and in the
> Webkit forum here
> .
>
> Web developers: Extensive interest in this feature from adtechs,
> evidenced by the myriad of discussions on Protected Audience’s issue
> tracker  and weekly WICG calls
> .
>
> Goals for experimentation
>
> Operating Bidding and Auction services in TEEs represents a major shift
> from running Protected Audience auctions inside the browser.  During this
> Origin Trial we’d like to gain confidence that this is possible to do at
> scale and in a performant manner.  We want feedback on new API surfaces and
> how these servers are operated.
>
> Debuggability
>
> On-device API surfaces should be debuggable in Chrome DevTools, and we’ve
> added extensive mechanisms for debugging Bidding and Auction services
> 
> .
>
> Will this feature be supported on all six Blink platforms (Windows, Mac,
> Linux, Chrome OS, 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
> 
> ?
>
> No. More web-platform-test
> 
> coverage is expected when the specification is closer to completion.
>
> Flag name on chrome://flags
>
> Overall control is not possible via chrome://flags, though the consented
> debugging support
> 
> is controlled via chrome://flags/#protected-audience-debug-token
>
> Finch feature name
>
> FledgeBiddingAndAuctionServerAPI
>
> Requires code in //chrome?
>
> Only for UI for the consented debugging support
> 
> .
>
> Estimated milestones
>
> We hope to start the Origin Trial sometime during M119 beta. We plan to
> continue the Origin Trial for at least three milestones to give developers
> time to test the API and provide feedback. Once we are confident that the
> APIs are working properly, we will transition t

Re: [blink-dev] Intent to Experiment: Protected Audience Bidding & Auction Services

[Mike Taylor]

Hi Paul,

Can you clarify what the proposed end milestone will be?

thanks,
Mike

On 10/13/23 10:46 AM, Chris Harrelson wrote:
Please fill out and start the reviews for Privacy, Security and 
Debuggability in your chromestatus entry, thanks.


On Thu, Oct 12, 2023 at 3:40 PM Paul Jensen  
wrote:



Contact emails

pauljen...@chromium.org, behamil...@google.com


Explainer

Chrome:

https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md



Services:

https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md



Note that this explainer has a helpful onboarding section

for
setting up the services.


Specification

May be influenced by Origin Trial feedback, so not yet started. 
Protected Audience auctions running on Bidding & Auction Services
provide functionality very similar to existing on-device auctions
so much of the existing spec
applies.


Summary

The Protected Audience API (formerly known as FLEDGE) is a Privacy
Sandbox proposal to serve remarketing and custom audience use
cases, designed so third parties cannot track user browsing
behavior across sites. This proposal, the Protected Audience
Bidding & Auction Services proposal, outlines a way to allow
Protected Audience computation to take place on cloud servers in a
Trusted Execution Environment (TEE), rather than running locally
on a user's device. Moving computation to cloud servers can help
optimize the Protected Audience auction, and free up computational
cycles and network bandwidth for a device.


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

None. This is an optional new feature of the Protected Audience
API. Ad techs can use this new feature by calling
navigator.getInterestGroupAdAuctionData() and specifying values
for new fields in the auction config. Without invoking the new
function or explicit values for those new fields, there's no
functional behavioral change as a result of this feature.


Gecko & WebKit: No signal on parent proposal, Protected Audience.
Asked in the Mozilla forumhere
, and
in the Webkit forum here
.


Web developers: Extensive interest in this feature from adtechs,
evidenced by the myriad of discussions on Protected Audience’s
issue tracker and
weekly WICG calls .


Goals for experimentation

Operating Bidding and Auction services in TEEs represents a major
shift from running Protected Audience auctions inside the
browser.  During this Origin Trial we’d like to gain confidence
that this is possible to do at scale and in a performant manner. 
We want feedback on new API surfaces and how these servers are
operated.


Debuggability

On-device API surfaces should be debuggable in Chrome DevTools,
and we’ve added extensive mechanisms for debugging Bidding and
Auction services

.


Will this feature be supported on all six Blink platforms
(Windows, Mac, Linux, Chrome OS, 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

?

No. Moreweb-platform-test

coverage
is expected when the specification is closer to completion.


Flag name on chrome://flags

Overall control is not possible via chrome://flags, though the
consented debugging support

Re: [blink-dev] Intent to Experiment: Protected Audience Bidding & Auction Services

['Paul Jensen' via blink-dev]

> Please fill out and start the reviews for Privacy, Security and
Debuggability in your chromestatus entry, thanks.
These are all in review now.  Sorry, I forgot about this new step.

> Can you clarify what the proposed end milestone will be?
I hope the Origin Trial to last M119 through M121, though I strongly
suspect I'll need to extend this further to provide sufficient time to test.

On Wed, Oct 18, 2023 at 12:04 PM Mike Taylor  wrote:

> Hi Paul,
>
> Can you clarify what the proposed end milestone will be?
>
> thanks,
> Mike
> On 10/13/23 10:46 AM, Chris Harrelson wrote:
>
> Please fill out and start the reviews for Privacy, Security and
> Debuggability in your chromestatus entry, thanks.
>
> On Thu, Oct 12, 2023 at 3:40 PM Paul Jensen 
> wrote:
>
>> Contact emails
>>
>> pauljen...@chromium.org, behamil...@google.com
>>
>> Explainer
>>
>> Chrome:
>> https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md
>>
>> Services:
>> https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md
>>
>> Note that this explainer has a helpful onboarding section
>> 
>> for setting up the services.
>>
>> Specification
>>
>> May be influenced by Origin Trial feedback, so not yet started.
>> Protected Audience auctions running on Bidding & Auction Services provide
>> functionality very similar to existing on-device auctions so much of the
>> existing spec  applies.
>>
>> Summary
>>
>> The Protected Audience API (formerly known as FLEDGE) is a Privacy
>> Sandbox proposal to serve remarketing and custom audience use cases,
>> designed so third parties cannot track user browsing behavior across sites.
>> This proposal, the Protected Audience Bidding & Auction Services proposal,
>> outlines a way to allow Protected Audience computation to take place on
>> cloud servers in a Trusted Execution Environment (TEE), rather than running
>> locally on a user's device. Moving computation to cloud servers can help
>> optimize the Protected Audience auction, and free up computational cycles
>> and network bandwidth for a device.
>>
>> 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
>>
>> None. This is an optional new feature of the Protected Audience API. Ad
>> techs can use this new feature by calling
>> navigator.getInterestGroupAdAuctionData() and specifying values for new
>> fields in the auction config. Without invoking the new function or explicit
>> values for those new fields, there's no functional behavioral change as a
>> result of this feature.
>>
>> Gecko & WebKit: No signal on parent proposal, Protected Audience.  Asked
>> in the Mozilla forum here
>> , and in the
>> Webkit forum here
>> .
>>
>> Web developers: Extensive interest in this feature from adtechs,
>> evidenced by the myriad of discussions on Protected Audience’s issue
>> tracker  and weekly WICG calls
>> .
>>
>> Goals for experimentation
>>
>> Operating Bidding and Auction services in TEEs represents a major shift
>> from running Protected Audience auctions inside the browser.  During this
>> Origin Trial we’d like to gain confidence that this is possible to do at
>> scale and in a performant manner.  We want feedback on new API surfaces and
>> how these servers are operated.
>>
>> Debuggability
>>
>> On-device API surfaces should be debuggable in Chrome DevTools, and we’ve
>> added extensive mechanisms for debugging Bidding and Auction services
>> 
>> .
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, Chrome OS, 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
>> 
>> ?
>>
>> No. More web-platform-test
>> 
>> coverage is expected when the specification is closer to completion.
>>
>> Flag name on chrome://flags
>>
>> Overall control is not possible via chrome://flags, though the consented
>> debugging support
>> 

Re: [blink-dev] Intent to Experiment: Protected Audience Bidding & Auction Services

[Mike Taylor]

LGTM to experiment from M119 to M121 (inclusive). Extending another 3 
milestones if needed will be fairly mechanical, given our current policy 
 
on OT length.


On 10/19/23 6:48 AM, Paul Jensen wrote:
> Please fill out and start the reviews for Privacy, Security and 
Debuggability in your chromestatus entry, thanks.

These are all in review now.  Sorry, I forgot about this new step.

> Can you clarify what the proposed end milestone will be?
I hope the Origin Trial to last M119 through M121, though I strongly 
suspect I'll need to extend this further to provide sufficient time to 
test.


On Wed, Oct 18, 2023 at 12:04 PM Mike Taylor  
wrote:


Hi Paul,

Can you clarify what the proposed end milestone will be?

thanks,
Mike

On 10/13/23 10:46 AM, Chris Harrelson wrote:

Please fill out and start the reviews for Privacy, Security and
Debuggability in your chromestatus entry, thanks.

On Thu, Oct 12, 2023 at 3:40 PM Paul Jensen
 wrote:


Contact emails

pauljen...@chromium.org, behamil...@google.com


Explainer

Chrome:

https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md



Services:

https://github.com/privacysandbox/fledge-docs/blob/main/bidding_auction_services_api.md



Note that this explainer has a helpful onboarding section

for
setting up the services.


Specification

May be influenced by Origin Trial feedback, so not yet
started.  Protected Audience auctions running on Bidding &
Auction Services provide functionality very similar to
existing on-device auctions so much of the existing spec
applies.


Summary

The Protected Audience API (formerly known as FLEDGE) is a
Privacy Sandbox proposal to serve remarketing and custom
audience use cases, designed so third parties cannot track
user browsing behavior across sites. This proposal, the
Protected Audience Bidding & Auction Services proposal,
outlines a way to allow Protected Audience computation to
take place on cloud servers in a Trusted Execution
Environment (TEE), rather than running locally on a user's
device. Moving computation to cloud servers can help optimize
the Protected Audience auction, and free up computational
cycles and network bandwidth for a device.


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

None. This is an optional new feature of the Protected
Audience API. Ad techs can use this new feature by calling
navigator.getInterestGroupAdAuctionData() and specifying
values for new fields in the auction config. Without invoking
the new function or explicit values for those new fields,
there's no functional behavioral change as a result of this
feature.


Gecko & WebKit: No signal on parent proposal, Protected
Audience.  Asked in the Mozilla forumhere
,
and in the Webkit forum here
.


Web developers: Extensive interest in this feature from
adtechs, evidenced by the myriad of discussions on Protected
Audience’s issue tracker
and weekly WICG
calls .


Goals for experimentation

Operating Bidding and Auction services in TEEs represents a
major shift from running Protected Audience auctions inside
the browser.  During this Origin Trial we’d like to gain
confidence that this is possible to do at scale and in a
performant manner.  We want feedback on new API surfaces and
how these servers are operated.


Debuggability

On-device API su