Review request for Protected Audience

[JensenPaul]

Braw mornin' TAG!

I'm requesting a TAG review of Two Uncorrelated Requests, Then Locally-Executed Decision On Victory ("TURTLEDOVE").

TURTLEDOVE provides a privacy advancing API to facilitate interest group based advertising. TURTLEDOVE shifts the interest data and the final ad decision browser-side instead of server-side, offering many advantages: strong privacy guarantees, as well as time limits on group membership, transparency into how the advertiser interest groups are built and used, and granular or global controls over this type of ad targeting.

• Explainer: as of 22 Aug, see FLEDGE (although the name is "Protected Audience"). Previous explainer: Two Uncorrelated Requests, Then Locally-Executed Decision On Victory ("TURTLEDOVE")
• Security and Privacy self-review: See below
• GitHub repo: WICG/turtledove
• Primary contacts (and their relationship to the specification):
  • Michael Kleber (@michaelkleber), Google
  • Paul Jensen (@JensenPaul), Google
• Organization/project driving the design: Google
• External status/issue trackers for this feature: Chrome Status

Further details:

• [✓] I have reviewed the TAG's Web Platform Design Principles
• The group where the incubation/design work on this is being done: WICG
• The group where standardization of this work is intended to be done ("unknown" if not known): unknown
• Existing major pieces of multi-stakeholder review or discussion of this design:
  • Issue trackers: https://github.com/WICG/turtledove/issues
• Major unresolved issues with or opposition to this design:
  • There are many issues under discussion in the issue tracker but no major opposition.
• This work is being funded by: Google

You should also know that...

• For details of the first TURTLEDOVE experiment see FLEDGE.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

🐛 open issues in our GitHub repo for each point of feedback

Security/Privacy Questionnaire

This section contains answers to the W3C TAG Security and Privacy Questionnaire.

1. What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
TURTLEDOVE performs the auction using worklets that cannot access or communicate with the publisher page or the network to prevent exposing information to web sites.
TURTLEDOVE renders the ad in a fenced frame to prevent exposing information to web sites.
TURTLEDOVE keeps the interest-group ad request uncorrelated to prevent exposing information about the web page or about the person visiting it.
2. Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
Yes, see above answer for ways information exposure is minimized.
3. How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
TURTLEDOVE should not deal with personal information, PII or information derived from them. Callers of the API may make choices (for example, which interest groups to add a browser to) based on this sort of information, so group membership is not exposed to sites, as in question 1.
4. How do the features in your specification deal with sensitive information?
Same answer as # 3.
5. Do the features in your specification introduce a new state for an origin that persists across browsing sessions?
Yes, but as discussed in question 1 the information is prevented from being exposed to sites.
6. Do the features in your specification expose information about the underlying platform to origins?
TURTLEDOVE may expose whether the user has enabled or disabled features like TURTLEDOVE.
7. Does this specification allow an origin to send data to the underlying platform?
No
8 Do features in this specification allow an origin access to sensors on a user’s device
No
9. What data do the features in this specification expose to an origin? Please also document what data is identical to data exposed by other features, in the same or different contexts.
As question 1 discusses, the data is prevented from being exposed to sites.
10. Do features in this specification enable new script execution/loading mechanisms?
Yes, running an auction will load and execute the bidding, scoring, and reporting worklets though these worklets are executed in separate JavaScript contexts without access to any web page, storage or the network.
11. Do features in this specification allow an origin to access other devices?
No
12. Do features in this specification allow an origin some measure of control over a user agent’s native UI?
No
13. What temporary identifiers do the features in this specification create or expose to the web?
None.
14. How does this specification distinguish between behavior in first-party and third-party contexts?
TURTLEDOVE defines various steps to control access to its APIs in third-party contexts. See the paragraph that starts with “The browser will only allow the” here.
15. How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
If FLEDGE is active, Incognito mode will use an in-memory interest group store that is separate from the one used by the default browsing mode. This mirrors the behavior of browsing history, cookies, and the HTTP cache, so the interest groups are forgotten once that incognito browsing profile terminates.
16. Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yes.
17. Do features in your specification enable origins to downgrade default security protections?
No
18. What should this questionnaire have asked?
N/A

[torgo]

Hi @JensenPaul thanks for sending us this. We're just picking it up this week. Just a few quick questions: what's the intended place for standardisation after WICG? Has this been discussed at all? Also can you be more specific about additional stakeholder / implementer interest in this approach? Are there other browsers who have expressed interest? Are ad networks and publishers engaged and looking to trial this approach? On the technical end - am I right that this proposal would mean that every TURTLEDOVE ad request would lead to two requests, with a "on device auction" determining what ad the user would see? Have you considered the additional bandwidth and processing requirements that would entail for the user's device? (cf https://www.w3.org/2001/tag/doc/ethical-web-principles/#sustainable).

[JensenPaul]

what's the intended place for standardisation after WICG?

I think the PATWG makes sense, once that WG exists. (The incubation may move from WICG into PATCG, if that group has capacity.)

Also can you be more specific about additional stakeholder / implementer interest in this approach? Are there other browsers who have expressed interest?

Edge is also exploring interest group based advertising, namely with the PARAKEET proposal. PARAKEET shares much of its API with FLEDGE (the first TURTLEDOVE experiment) but has a different trust model. Deployment experience is necessary to inform the choice between the trust models.

Are ad networks and publishers engaged and looking to trial this approach?

There is significant interest from many web advertising technology developers. WICG FLEDGE calls are heavily attended (often 30+ attendees representing 15+ companies). Interest in TURTLEDOVE is further evidenced by the many related discussions and proposals that TURTLEDOVE design draws from, most notably:

• SPARROW from Criteo.
• Outcome-based TURTLEDOVE and Product-level TURTLEDOVE from RTB House.
• Dovekey from Google Ads.
• PARRROT from Magnite.
• TERN from NextRoll.

On the technical end - am I right that this proposal would mean that every TURTLEDOVE ad request would lead to two requests, with a "on device auction" determining what ad the user would see? Have you considered the additional bandwidth and processing requirements that would entail for the user's device? (cf https://www.w3.org/2001/tag/doc/ethical-web-principles/#sustainable).

Today, as a person browses sites, their browser initiates network requests to store their interests server-side, and a network request is made to an ad server to select ads based on contextual signals and the user’s interests. TURTLEDOVE eliminates the need for network requests to store interests server-side, and instead stores them on-device. In TURTLEDOVE, a network request is made to an ad server to select ads based on contextual signals, but ad selection based on the user’s interests is done on-device by running JavaScript methods to calculate bid values. Reducing latency of the on-device computation is top of mind and the subject of much discussion, and many times reducing latency is accomplished by reducing the required computation and processing requirements. PARAKEET experimentation will help inform choices of what processing can be done on-device versus on a trusted server. We invite feedback on trade-offs related to using on-device resources versus those server-side.

[torgo]

Hi @JensenPaul - Thanks for the info! You've mentioned “PARAKEET” ... also Dovekey and some others. Some of these feel like competing approaches. It feels premature for TAG to offer a review when there are multiple competing proposals which are all seen as experiments. Has the group decided - is there group consensus to use this as a winning proposal? It feels like group consensus should come first. What does the path to consensus look like? Is it running multiple proposals in the field and getting data and then bringing this data back into the process?

[JensenPaul]

There were a lot of proposals in the past, most of which were either folded into later proposals or from which the later proposals drew from. To my knowledge the only two being pursued presently by web browsers are TURTLEDOVE/FLEDGE by Chrome and PARAKEET by Edge. It’s worth noting that these two remaining proposals share most of their API and they differ mostly in their trust models. Deployment experience is necessary to inform the choice between the trust models, and the Blink release process asks for a TAG review before proceeding to broader deployment. Chrome is running an Origin Trial with FLEDGE and I believe Microsoft is running a Polyfill test with PARAKEET.

[hadleybeeman]

Hello! We discussed this at our W3C TAG breakout.

We are adding this to our agenda for our upcoming face-to-face in London, and we'll come back to this in more detail then.

[miketaylr]

We're also being tripped up by some terms of art in the explainer such as the use of the word "creative" and the concept of "k-anonymity" which may be intuitive to the specification writers but are not adequately explained in the specs.

You might find https://developer.chrome.com/en/docs/privacy-sandbox/glossary/ helpful.

[JensenPaul]

We're still a bit confused as to what the latest proposal is, since the explainer still calls the feature "FLEDGE" and is still in a repo named "turtledove".

I’m actively working to bring the explainer up to date, see #775. We’re planning to rename the files. I’m trying to merge a few large pull requests before renaming the files to avoid large merge conflicts.

We're also being tripped up by some terms of art in the explainer such as the use of the word "creative" and the concept of "k-anonymity" which may be intuitive to the specification writers but are not adequately explained in the specs.

I authored and merged this commit to help explain these terms in the explainer and #827 to help explain these terms in the spec.

Can you or someone please take the time to update the explainer and specs appropriately so that it's clear (not only to us but to the developer community at large) what is being trialed?

I authored and merged #775 to accomplish this.

[torgo]

Many thanks @JensenPaul ! We'll take a look. 👀

[torgo]

Hi @JensenPaul - We're coming back to this and re-reviewing based on the info you've provided. We remain concerned with the processing burden that this spec proposes to place on the user's device (in terms of battery life, bandwidth, performance in general). We recognize that that's in service of privacy – however, the question remains: are these use cases fundamental enough the functioning of the web to justify adding such a complex subsystem.

We recognize that this does more than the Topics API proposal. However considering the Topics API proposal also proposes subject-related groups and this proposes "interest groups", is there scope to reuse Topics for that part of this API?

Also - interest groups are a group of people with a common interest - but we don't understand how such a group would "bid" (first bullet point in the explainer summary). It seems like as a user you would not have control over what interest group you are part of - as this is set by the "owner" of the group. Even if the user has the ability to opt out of being part of such a group, given the number of possible groups sthey could be part of, this could constitute unreasonable privacy labor. We've already highlighted some concerns regarding this approach in Topics – particularly when it comes to protected characteristics / marginalized groups. It appears that Protected Audience would suffer from the same issues.

You've stated that relaxing the network access constraints of Fenced Frames for this API is "temporary" - what is needed to reinstate this constraint? Do you have a planned path for this? Is there a risk that adding this constraint back will be difficult once this API is in use?

[hadleybeeman]

Hi @JensenPaul and @michaelkleber. We are looking at this in our TAG f2f in London.

It looks like we are waiting for responses from you to @torgo's questions. What are your thoughts?

[lknik]

Let me add this detail for context - I've got quite lengthy assessment of Protected Audience. Hope it helps.

[JensenPaul]

Hi @JensenPaul - We're coming back to this and re-reviewing based on the info you've provided.

I’m glad to hear that. Thank you again for reviewing Protected Audience.

We remain concerned with the processing burden that this spec proposes to place on the user's device (in terms of battery life, bandwidth, performance in general).

These concerns are also top of mind for the team developing Protected Audience as well. We’ve prioritized solutions to address resource usage and reduce latency, e.g. moving some filtering server-side, reusing JS contexts in multiple different ways, moving some bid computations to servers, moving all bid computations to servers, parallelizing the auction with other site requests, facilitating more on-server filtering.

We recognize that that's in service of privacy – however, the question remains: are these use cases fundamental enough the functioning of the web to justify adding such a complex subsystem.

We believe that facilitating remarketing and custom audience advertising post third-party cookie deprecation maintains critical web site revenue and is thus fundamental to the functioning of the web and justifies adding the Protected Audience API to the web.

We recognize that this does more than the Topics API proposal. However considering the Topics API proposal also proposes subject-related groups and this proposes "interest groups", is there scope to reuse Topics for that part of this API?

We think that the Topics API and the Protected Audience API address different ways of thinking about advertising, and that Topics is not well-suited for addressing the PA use cases. Specifically, PA is about allowing parties in the ad tech ecosystem to do the job of observing behavior (just on a single website!) and forming an opinion of what ads to show as a result. There is a lot of variation in what advertisers are trying to do, so it doesn't seem like a browser API can completely replace all the depth and innovation of that "recognizing that someone might be your audience" job.

Also - interest groups are a group of people with a common interest - but we don't understand how such a group would "bid" (first bullet point in the explainer summary).

There may be a key misunderstanding here. An "Interest Group" is created and owned by some party, for example by an ad tech representing an advertiser. The IG itself is represented by a blob of data stored in the browser; that data includes a set of ads that the IG may later show (if it wins an auction), a JS bidding function (that lets it participate in the auction), and so on. But the decisions on how the IG behaves are all in the hands of the ad tech owner of the IG.
The set of "people whom a particular ad tech has placed in an IG with a particular name" might well be a group of people with a common interest, but that large group of people does not in any way control what the IG does, they are instead the people who might see ads the IG contains.

It seems like as a user you would not have control over what interest group you are part of - as this is set by the "owner" of the group. Even if the user has the ability to opt out of being part of such a group, given the number of possible groups sthey could be part of, this could constitute unreasonable privacy labor. We've already highlighted some concerns regarding this approach in Topics – particularly when it comes to protected characteristics / marginalized groups. It appears that Protected Audience would suffer from the same issues.

We also feel that presenting users with the list of all groups they were a part of might be cumbersome as the list could be long and users couldn’t be expected to understand the names of the interest groups. We took a different approach, and in our settings UI, display the names of the sites the user visited that added interest groups, as this is something the user can understand. For example the browser I’m writing this in shows angi.com, truecar.com, and wayfair.com which are all sites I remember visiting recently. Protected Audience has two design choices that make explaining to the user about their interest groups possible:

1. Each interest group comes from a single site that the user visited in the last 30 days. This requirement makes the list of sites that joined the user to interest groups both relateable and understandable. If a user browses to a displeasing site and wants to remove the interest groups that it joined from their history, we can easily clear them in the Protected Audience settings UI, and we also do this automatically when they clear site data for that site.

2. The list of ads is stored in the interest group. This makes it plausible to convey to a user what an interest group relates to by displaying the exact ads they might see from an interest group. (We haven't implemented this or finalized the details of our UI yet.)

You've stated that relaxing the network access constraints of Fenced Frames for this API is "temporary" - what is needed to reinstate this constraint?

The network access constraint could be reinstated when a trusted-server reporting framework and alternate ad delivery mechanism (e.g. ads stored in the browser or served from a trusted server) are settled and in place. The user reidentification risk associated with ad rendering with network access is already substantially decreased by the k-anonymity requirements on ads. There are also other ways to decrease the user reidentification risk associated with ad rendering with network access, for example mitigating side channels like IP address which Chrome is pursuing currently.

[lknik]

@JensenPaul thanks for the comprehensive reply! This is a nice clarification. One question from me, though: why not add an option to inspect IGs for those users who would like doing so?

[plinss]

The TAG have discussed this at length, and the following represents our consensus review of the proposal.

We understand that Protected Audience is a substitute mechanism to enable ad targeting, specifically where targeting is based on specific actions that someone took on other sites. This use case was previously supported by cross-site cookies.

The TAG is supportive of efforts to improve web privacy, particularly the withdrawal of cross-site cookies, which make the unwanted practices of tracking and profiling too easy. We consider the long-standing ability to track and profile web users without their informed consent a flaw in the web platform, so we do not generally support proposals that aim to restore or maintain this status quo, or to work around privacy measures that are introduced elsewhere.

We recognize that the web is not perfect. There are lots of ways that cross-site information still leaks, especially when it comes to navigation. But we do insist that new work leaves the web in a better state than it was found - our goal as web platform developers acting in good faith is to patch these vulnerabilities, and not create new means of cross-site recognition.

If Protected Audience exists to support ad targeting based on cross-site information, it has to ensure that it does not enable cross-site recognition. The TAG notes several features in the design that currently do not meet this standard. For instance, Fenced Frames are not mandatory; using an iframe to render an ad makes it trivial to leak the ad that wins an auction; or, where buyers and sellers supply their own key-value servers, which are given detailed information about the set of interest groups that have been registered.

We understand that those flaws are intended to be temporary, but that still means that there will be one to two years where Protected Audience exists with these vulnerabilities, which is not acceptable. If those are eventually fixed, we do not see a way to avoid the problems of leaking information as a result of interactions with a malicious ad.

We encourage the proponents of this feature to provide more convincing and rigorous analysis of the privacy properties of the proposed design. A number of claims are made about the privacy properties of the system, but no comprehensive analysis has been performed.

We appreciate the argument that advertising can provide material support for the creation of content, which might have indirect benefits for web users, although we are not in agreement that "remarketing and custom audience advertising" are "fundamental" to the functioning of the web. We should aim to avoid entrenching specific business or economic models into the design of the web platform through technical standards. We encourage the proponents to dedicate efforts to finding alternative ways to materially support web content creators which do not have the privacy concerns of Protected Audience.

Given the privacy harms and added complexity to address a narrow set of use cases, we do not support this feature being added to the web platform.

[slightlyoff]

just came back to this from a different thread (an I2S for a related control) and I'm deeply concerned with the tone and content of @plinss's last comment here. We do not come to the TAG for a go/no-go decision, we ask the TAG for constructive technical feedback and platform consistency guidance. It's fine to say "this is all wrong", but my expectation of TAG feedback is that these sorts of replies are constructed about why features are technically wrong. The last message is heavy on atmospherics and judgement and contains no new technical content. What's going on here?

I'm dismayed that the TAG appears confused about how it can best be of service to the project of improving the platform.

/cc @chrishtr