Intent to Ship (I2S): Protected Audience
Paul Jensen
paulj...@chromium.org, kle...@google.com, ajvel...@google.com
Explainer
https://github.com/WICG/turtledove/blob/master/FLEDGE.md
Specification
https://wicg.github.io/turtledove
Summary
The Protected Audience API (formerly known as FLEDGE) provides a method of interest-group advertising without having to track individual users’ detailed browsing history as is done today with third-party cookies. Additional advantages over cookies include time limits on group membership, better user controls, and more user transparency.
Blink component
TAG review
https://github.com/w3ctag/design-reviews/issues/723
TAG review status
Pending since March 2022
Risks
Compatibility
This is not a breaking change. To use it, sites will need to call the Protected Audience API. There is no change to existing behavior for sites not calling the API. It’s worth noting that the spec uses WebIDL to describe the script runners but the implementation does not. There may be minor compat issues as we align the implementation with the WebIDL semantics over time.
Interoperability
Gecko: No signal, requested March 2023
WebKit: No signal, requested March 2023
Edge: Edge explored interest group based advertising, namely with the PARAKEET proposal. PARAKEET shares much of its API with Protected Audience but as discussed in TPAC 2022, involves proxying data to non-trusted servers in real-time whereas Protected Audience does not have long term plans to do this.
Web developers: Significant interest from many web developers. Significant Origin Trial participation. WICG FLEDGE calls are heavily attended. Interest in Protected Audience is further evidenced by the many related discussions and proposals that Protected Audience’s design draws from, most notably:
The original TURTLEDOVE from Chrome.
SPARROW from Criteo.
Outcome-based TURTLEDOVE and Product-level TURTLEDOVE from RTB House.
Dovekey from Google Ads.
PARRROT from Magnite.
TERN from NextRoll.
Demo link
https://developer.chrome.com/docs/privacy-sandbox/fledge-api/#demo
Debuggability
To learn more about debugging Protected Audience in Chrome please follow these links: https://developer.chrome.com/blog/fledge-api/#debugging https://developer.chrome.com/blog/fledge-api/#observe-fledge-events
Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
All except WebView
Is this feature fully tested by web-platform-tests?
We've tested all of the primary functionality in WPT. This API has a lot of surface area and so we're continuing to add platform tests over time.
https://wpt.fyi/results/?q=fledge
Flag name
InterestGroupStorage,AdInterestGroupAPI,Fledge,AllowURNsInIframes,BiddingAndScoringDebugReportingAPI
Requires code in //chrome?
Yes, for settings UI controls and k-anonymity server communication.
Estimated milestones
Has been in Origin Trial since M101. We intend to start an incremental ramp to 100% in Stable with Chrome Release M115.
Anticipated spec changes
We’re addressing some remaining TODOs and specifying some recently added non-breaking features (e.g. #304, #305, #310, #166).
Moving beyond our core use cases, we anticipate the need to support new functionality going forward. We don’t currently anticipate changes that would break backwards compatibility.
Support for Bidding and Auction services is in progress. This is a non-breaking additional feature.
Link to entry on the Chrome Platform Status
https://chromestatus.com/feature/5733583115255808
Links to previous Intent discussions
Intent to Prototype:
https://groups.google.com/a/chromium.org/g/blink-dev/c/w9hm8eQCmNI
Intent to Experiment:
https://groups.google.com/a/chromium.org/g/blink-dev/c/0VmMSsDWsFg/m/_0T5qleqCgAJ
Intent to Extend Origin Trial:
https://groups.google.com/a/chromium.org/g/blink-dev/c/SD8Ot2gpz4g/m/A9uA-_cGAwAJ
https://groups.google.com/a/chromium.org/g/blink-dev/c/gpmaOi3of_w/m/SyMclFhMAAAJ
https://groups.google.com/a/chromium.org/g/blink-dev/c/CBrV-2DrYFI/m/RTojC6kHAgAJ
Dominic Farolino
As the spec mentor for this feature I'll offer a spec maturity summary. @Jeffrey Yasskin and I reviewed the spec in detail recently and were pleased with the improvements that the team worked with us to make recently, especially with regards to:
Formalizing the interaction with times and dates
Adding rigor to the in parallel work (and its interaction with the main thread and the Script Runner realms)
Fetch integration
Specifying the conversions from internal spec data to JS objects when calling into the Script Runners, mostly by increasing the use of WebIDL
In a few of these points there is still work to be done, and we've been filing bugs against the specification for individual tasks that the team has committed to making progress on in the very near future. The spec overall is not yet very readable, which means external reviewers will have to spend time to understand the flow before they can give substantive feedback. From a completeness perspective, the spec still has over a dozen "TODOs" (I expect that they’ll be finished soon given how many have recently closed), including the bulk of the integration with Fenced Frames, whose completion might help other browser engines notice new interoperability issues. The team is completing these at a good pace, but this implies that in addition to finishing pieces of the spec that document the current implementation, there will probably be minor web-visible changes after shipping in M115. However, most of these changes are unlikely to break web content, and if anything bigger comes up, the Privacy Sandbox's general tools for migrating their users should be effective.
--
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/CABQTWrn8eM3wOtUY3RzmDrt7SVxR_y_6Fo02bJ%2BF1bzbwpFfkQ%40mail.gmail.com.
Yoav Weiss
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAP-uykDhn3EzgNacgnEExhiLwrdnc%2Bf7ZV6qMf%3DHk1ns1oHdTw%40mail.gmail.com.
Paul Jensen
Yoav,
Protected Audiences has been fortunate to have a ton of design contributions and feedback, but consequently has a lot of issues filed. We try to respond to all issues, as you can see by the discussion comments on nearly all issues. I went through and triaged all the issues recently. I closed many of them, created some labels and labeled many of them. Here’s where I think the open issues stand:
65 I labeled “Non-breaking Feature Request”, meaning they’re requesting new functionality that is unlikely to cause backwards compatibility issues.
29 are spec related. As Dominic said above, most of these changes are unlikely to break web content.
8 are seeking feedback rather than pointing to a problem.
4 could potentially break compatibility. I think for all of these we’ve decided to not adopt the proposed changes or we’ve decided to adopt the proposed changes but as part of our longer-term plans in the future. I should note that recently we adopted many breaking changes to our API, but did so in a way that supports backwards compatibility, so we can wean developers off of the old APIs without causing immediate significant breakage. If we chose to adopt some of these changes, I imagine we could do so in a similar non-breaking way.
86 didn’t fit well into a particular category:
Some were questions seeking to clarify details of our timeline or the explainer or design.
Some were discussions that are mostly addressed but left open so we don’t forget about remaining pieces.
Some are open discussions or examples.
I think it’s worth noting that our usage of the issue system differs from those of many other folks who ship features: We tend to use the issues as open forums as opposed to only leaving open issues that need to have decisions made. Many of the issues predate the FLEDGE explainer and represent design discussions that culminated in FLEDGE’s design.
I hope the labels I added make it clearer which are future enhancements and not likely to break backwards compatibility. I honestly think over the years before our Origin Trial and over the course of our lengthy Origin Trial we’ve addressed all the feedback for core functionality in Protected Audience and don’t anticipate breaking backwards compatibility in significant ways.
Yoav Weiss
Yoav,
Protected Audiences has been fortunate to have a ton of design contributions and feedback, but consequently has a lot of issues filed. We try to respond to all issues, as you can see by the discussion comments on nearly all issues. I went through and triaged all the issues recently. I closed many of them, created some labels and labeled many of them. Here’s where I think the open issues stand:
65 I labeled “Non-breaking Feature Request”, meaning they’re requesting new functionality that is unlikely to cause backwards compatibility issues.
29 are spec related. As Dominic said above, most of these changes are unlikely to break web content.
8 are seeking feedback rather than pointing to a problem.
4 could potentially break compatibility. I think for all of these we’ve decided to not adopt the proposed changes or we’ve decided to adopt the proposed changes but as part of our longer-term plans in the future. I should note that recently we adopted many breaking changes to our API, but did so in a way that supports backwards compatibility, so we can wean developers off of the old APIs without causing immediate significant breakage. If we chose to adopt some of these changes, I imagine we could do so in a similar non-breaking way.
86 didn’t fit well into a particular category:
Some were questions seeking to clarify details of our timeline or the explainer or design.
Some were discussions that are mostly addressed but left open so we don’t forget about remaining pieces.
Some are open discussions or examples.
I think it’s worth noting that our usage of the issue system differs from those of many other folks who ship features: We tend to use the issues as open forums as opposed to only leaving open issues that need to have decisions made. Many of the issues predate the FLEDGE explainer and represent design discussions that culminated in FLEDGE’s design.
Paul Jensen
On Tue, Jun 27, 2023 at 9:54 PM Paul Jensen <paulj...@chromium.org> wrote:Yoav,
Protected Audiences has been fortunate to have a ton of design contributions and feedback, but consequently has a lot of issues filed. We try to respond to all issues, as you can see by the discussion comments on nearly all issues. I went through and triaged all the issues recently. I closed many of them, created some labels and labeled many of them. Here’s where I think the open issues stand:
65 I labeled “Non-breaking Feature Request”, meaning they’re requesting new functionality that is unlikely to cause backwards compatibility issues.
29 are spec related. As Dominic said above, most of these changes are unlikely to break web content.
8 are seeking feedback rather than pointing to a problem.
4 could potentially break compatibility. I think for all of these we’ve decided to not adopt the proposed changes or we’ve decided to adopt the proposed changes but as part of our longer-term plans in the future. I should note that recently we adopted many breaking changes to our API, but did so in a way that supports backwards compatibility, so we can wean developers off of the old APIs without causing immediate significant breakage. If we chose to adopt some of these changes, I imagine we could do so in a similar non-breaking way.
86 didn’t fit well into a particular category:
Some were questions seeking to clarify details of our timeline or the explainer or design.
Some were discussions that are mostly addressed but left open so we don’t forget about remaining pieces.
Some are open discussions or examples.
I think it’s worth noting that our usage of the issue system differs from those of many other folks who ship features: We tend to use the issues as open forums as opposed to only leaving open issues that need to have decisions made. Many of the issues predate the FLEDGE explainer and represent design discussions that culminated in FLEDGE’s design.
Thanks for going over the issues!! To be clear, the number of issues is not a concern in itself, and is indeed an indication of the level of engagement this had.This list of compat-related issues is the only relevant bit for this intent IMO. At the same time, it'd be good to settle these issues, or at least have a clear path towards future-compat around them, before shipping. WDYT?
I think we’ve settled on paths to addressing each of the compat issues:
#444 and #586 I think we’ve settled on not pursuing for reasons expressed in the issues.
#522 has been our long term plan but we've heard feedback that it blocks adoption and usability at this stage, especially in the long-tail of advertisers. Providing a solution to audience stealing is an important goal of Protected Audience. Our current implementation offers opt-in protection via our Permission-Policy, and we're going to continue to look for an ergonomic solution that facilitates adoption sufficiently to offer the protection by default.
Mike Taylor
On 7/1/23 3:09 AM, Paul Jensen wrote:
On Wed, Jun 28, 2023 at 5:33 AM Yoav Weiss <yoav...@chromium.org> wrote:
On Tue, Jun 27, 2023 at 9:54 PM Paul Jensen <paulj...@chromium.org> wrote:
Yoav,
Protected Audiences has been fortunate to have a ton of design contributions and feedback, but consequently has a lot of issues filed. We try to respond to all issues, as you can see by the discussion comments on nearly all issues. I went through and triaged all the issues recently. I closed many of them, created some labels and labeled many of them. Here’s where I think the open issues stand:
65 I labeled “Non-breaking Feature Request”, meaning they’re requesting new functionality that is unlikely to cause backwards compatibility issues.
29 are spec related. As Dominic said above, most of these changes are unlikely to break web content.
8 are seeking feedback rather than pointing to a problem.
4 could potentially break compatibility. I think for all of these we’ve decided to not adopt the proposed changes or we’ve decided to adopt the proposed changes but as part of our longer-term plans in the future. I should note that recently we adopted many breaking changes to our API, but did so in a way that supports backwards compatibility, so we can wean developers off of the old APIs without causing immediate significant breakage. If we chose to adopt some of these changes, I imagine we could do so in a similar non-breaking way.
86 didn’t fit well into a particular category:
Some were questions seeking to clarify details of our timeline or the explainer or design.
Some were discussions that are mostly addressed but left open so we don’t forget about remaining pieces.
Some are open discussions or examples.
I think it’s worth noting that our usage of the issue system differs from those of many other folks who ship features: We tend to use the issues as open forums as opposed to only leaving open issues that need to have decisions made. Many of the issues predate the FLEDGE explainer and represent design discussions that culminated in FLEDGE’s design.
Thanks for going over the issues!! To be clear, the number of issues is not a concern in itself, and is indeed an indication of the level of engagement this had.This list of compat-related issues is the only relevant bit for this intent IMO. At the same time, it'd be good to settle these issues, or at least have a clear path towards future-compat around them, before shipping. WDYT?
I think we’ve settled on paths to addressing each of the compat issues:
#444 and #586 I think we’ve settled on not pursuing for reasons expressed in the issues.
#522 has been our long term plan but we've heard feedback that it blocks adoption and usability at this stage, especially in the long-tail of advertisers. Providing a solution to audience stealing is an important goal of Protected Audience. Our current implementation offers opt-in protection via our Permission-Policy, and we're going to continue to look for an ergonomic solution that facilitates adoption sufficiently to offer the protection by default.
#554 is something we might do, and could do in the future while offering a temporary backward-compatible period. It doesn’t have significant developer benefits, other than making it potentially more web-like, so I’m reluctant to adopt it.
Thanks Paul. Could you close out 586 and leave comments on 522
and 554 with your current thinking?
Re: 554, do you have plans to update the spec to match Chromium's implementation of setBid(), setPriority(), and setPrioritySignalsOverride()? Or do something else?
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWr%3D1ROXvBN-k6trfMvLpnE74avuc4WtmyZRrAuOHdh0zNQ%40mail.gmail.com.
Paul Jensen
On 7/1/23 3:09 AM, Paul Jensen wrote:
On Wed, Jun 28, 2023 at 5:33 AM Yoav Weiss <yoav...@chromium.org> wrote:
On Tue, Jun 27, 2023 at 9:54 PM Paul Jensen <paulj...@chromium.org> wrote:
Yoav,
Protected Audiences has been fortunate to have a ton of design contributions and feedback, but consequently has a lot of issues filed. We try to respond to all issues, as you can see by the discussion comments on nearly all issues. I went through and triaged all the issues recently. I closed many of them, created some labels and labeled many of them. Here’s where I think the open issues stand:
65 I labeled “Non-breaking Feature Request”, meaning they’re requesting new functionality that is unlikely to cause backwards compatibility issues.
29 are spec related. As Dominic said above, most of these changes are unlikely to break web content.
8 are seeking feedback rather than pointing to a problem.
4 could potentially break compatibility. I think for all of these we’ve decided to not adopt the proposed changes or we’ve decided to adopt the proposed changes but as part of our longer-term plans in the future. I should note that recently we adopted many breaking changes to our API, but did so in a way that supports backwards compatibility, so we can wean developers off of the old APIs without causing immediate significant breakage. If we chose to adopt some of these changes, I imagine we could do so in a similar non-breaking way.
86 didn’t fit well into a particular category:
Some were questions seeking to clarify details of our timeline or the explainer or design.
Some were discussions that are mostly addressed but left open so we don’t forget about remaining pieces.
Some are open discussions or examples.
I think it’s worth noting that our usage of the issue system differs from those of many other folks who ship features: We tend to use the issues as open forums as opposed to only leaving open issues that need to have decisions made. Many of the issues predate the FLEDGE explainer and represent design discussions that culminated in FLEDGE’s design.
Thanks for going over the issues!! To be clear, the number of issues is not a concern in itself, and is indeed an indication of the level of engagement this had.This list of compat-related issues is the only relevant bit for this intent IMO. At the same time, it'd be good to settle these issues, or at least have a clear path towards future-compat around them, before shipping. WDYT?
I think we’ve settled on paths to addressing each of the compat issues:
#444 and #586 I think we’ve settled on not pursuing for reasons expressed in the issues.
#522 has been our long term plan but we've heard feedback that it blocks adoption and usability at this stage, especially in the long-tail of advertisers. Providing a solution to audience stealing is an important goal of Protected Audience. Our current implementation offers opt-in protection via our Permission-Policy, and we're going to continue to look for an ergonomic solution that facilitates adoption sufficiently to offer the protection by default.
#554 is something we might do, and could do in the future while offering a temporary backward-compatible period. It doesn’t have significant developer benefits, other than making it potentially more web-like, so I’m reluctant to adopt it.
Thanks Paul. Could you close out 586 and leave comments on 522 and 554 with your current thinking?
Re: 554, do you have plans to update the spec to match Chromium's implementation of setBid(), setPriority(), and setPrioritySignalsOverride()?
Rick Byers
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABQTWrmxni_nFb60tusUdO%3D1i3ixRUWC2J86qa24u6B5e0SFpw%40mail.gmail.com.
Chris Harrelson
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-EK9ZUm%3DAk1LXxi3PLK7CArEZ1EGbeLMdXKuPQdsGsQg%40mail.gmail.com.
Mike Taylor
LGTM3