Intent to Ship (I2S): Protected Audience

1.292 visualizzazioni
Passa al primo messaggio da leggere

Paul Jensen

da leggere,
20 giu 2023, 16:06:0620/06/23
a blink-dev
Contact emails

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

Blink>InterestGroups


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:


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

da leggere,
21 giu 2023, 14:00:5621/06/23
a Paul Jensen, Jeffrey Yasskin, blink-dev, Josh Karlin

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

da leggere,
22 giu 2023, 03:57:0322/06/23
a Dominic Farolino, Paul Jensen, Jeffrey Yasskin, blink-dev, Josh Karlin
Glancing at the open issues, I see 291 of them.. Would it be possible to go over the issues and label them so that it's clearer which are about future enhancements, which are editorial and which may have an impact on the processing model or API shape in ways that can impact future compatibility?

Paul Jensen

da leggere,
27 giu 2023, 15:54:0527/06/23
a Yoav Weiss, Dominic Farolino, Jeffrey Yasskin, blink-dev, Josh Karlin

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

da leggere,
28 giu 2023, 05:33:0928/06/23
a Paul Jensen, Dominic Farolino, Jeffrey Yasskin, blink-dev, Josh Karlin
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?

Paul Jensen

da leggere,
30 giu 2023, 14:10:0630/06/23
a Yoav Weiss, Dominic Farolino, Jeffrey Yasskin, blink-dev, Josh Karlin
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. 

Mike Taylor

da leggere,
30 giu 2023, 17:03:4030/06/23
a Paul Jensen, Yoav Weiss, Dominic Farolino, Jeffrey Yasskin, blink-dev, Josh Karlin

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?

Paul Jensen

da leggere,
30 giu 2023, 17:50:2730/06/23
a Mike Taylor, Yoav Weiss, Dominic Farolino, Jeffrey Yasskin, blink-dev, Josh Karlin
On Fri, Jun 30, 2023 at 5:03 PM Mike Taylor <mike...@chromium.org> wrote:

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?

Done. 


Re: 554, do you have plans to update the spec to match Chromium's implementation of setBid(), setPriority(), and setPrioritySignalsOverride()?

Yes, I think this makes sense, I noted this in #554.  We will make this change soon.

Rick Byers

da leggere,
6 lug 2023, 12:54:4406/07/23
a Paul Jensen, Mike Taylor, Yoav Weiss, Dominic Farolino, Jeffrey Yasskin, blink-dev, Josh Karlin
Protected audiences seems like one of the most powerful and complex features ever added to Chromium, and I'll admit I've struggled to understand it at enough depth to do a decent API owner review. I carved out a few more hours this morning and am now comfortable giving my LGTM1 to ship. My reasoning is below for those few interested.

I'm impressed and inspired by the scope of investment here across the whole online advertising industry. Just seeing the level of investment and breadth of proposals that have been explored over the past 3.5 years makes it clear there's an important problem to be solved here. I don't feel qualified (not sure anyone really is) to predict whether putting such a critical piece of the adtech architecture into browsers will ultimately succeed and prove to be good for the web or not. But it does seem like we have to try and find out. The most obvious competing path is for ad-funded content to rely on either covert tracking or login walls, both of which will be an arms race which will be hard to win without some viable alternatives like protected audiences and topics. I'm particularly concerned with login walls being strictly worse for privacy and information discovery (eg. risks content being indexable only between large publishers and search engines via business deals). Given that the only other plausible alternative for Chrome is to preserve the status quo of third-party cookies, I personally see this as a step forward in giving users more choice, transparency and control over advertising and their privacy. Critically, shipping this now creates a path by which the targeted advertising tradeoff space is likely to continue to be improved over time.

From an interop risk perspective, despite the lack of official signals, given the feedback we've seen from other implementers on features like topics, I think it's safe to assume there won't be support from other engines anytime soon. I'd be interested to hear what other chromium embedders think, but that's not technically part of our interop risk signals and I imagine we'll see soon enough what other chromium browsers do with the privacy sandbox APIs. Still, IMHO we should be open to ideas for things we could do to make it easier for other chromium browsers to adopt (or fully disable) this API. It seems clear to me that tons of work has gone into puting the API on a plausible path to interoperability, but it's also clear it's a huge effort with work still to do. Thank you Dominic, Paul and team for your investments here and keeping it up, guided by the engagement and feedback you're getting. Now that the compat-impacting spec issues have been resolved or have a clear plan to resolve, I'm comfortable saying that the minimum spec/test bar for a major new feature to chip in chromium has been met.

I am somewhat concerned about the long-term implications on web performance (given the isolation requirements) but was heartened by the work that has gone into setting quotas and limits and exploration of alternate computing models like "bidding and auction services". I feel confident that we have lots of options (many more than with 3PCs today) for adjusting the tradeoff space in the future if performance proves to be a real problem in practice.

Overall, given the ambition of what is being attempted here (and our options for course correcting or even backtracking if needed), it seems to me the feature has reached a level of maturity that it's time to ship a V1 while continuing to iterate on the spec and larger open industry debate.

Rick


Chris Harrelson

da leggere,
10 lug 2023, 12:16:1210/07/23
a Rick Byers, Paul Jensen, Mike Taylor, Yoav Weiss, Dominic Farolino, Jeffrey Yasskin, blink-dev, Josh Karlin

Mike Taylor

da leggere,
10 lug 2023, 15:23:2310/07/23
a Chris Harrelson, Rick Byers, Paul Jensen, Yoav Weiss, Dominic Farolino, Jeffrey Yasskin, blink-dev, Josh Karlin

LGTM3

Rispondi a tutti
Rispondi all'autore
Inoltra
0 nuovi messaggi