Re: [w3ctag/design-reviews] Review request for Protected Audience (Issue #723)

> Hi [@JensenPaul](https://github.com/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](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#35-filtering-and-prioritizing-interest-groups), reusing JS contexts in [multiple](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#:~:text=The%20%22group%2Dby,be%20used%20instead.) [different](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#:~:text=The%20%22frozen%2Dcontext,the%20interest%20group.) ways, [moving some bid computations to servers](https://github.com/privacysandbox/protected-auction-services-docs/blob/main/key_value_service_trust_model.md#support-for-user-defined-functions-udfs), [moving all bid computations to servers](https://github.com/WICG/turtledove/blob/main/FLEDGE_browser_bidding_and_auction_API.md), [parallelizing the auction with other site requests](https://github.com/WICG/turtledove/blob/main/FLEDGE.md#211-providing-signals-asynchronously), [facilitating more on-server filtering](https://github.com/WICG/turtledove/pull/928).

> 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](https://github.com/w3ctag/design-reviews/issues/726). 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](https://w3ctag.github.io/privacy-principles/#dfn-privacy-labor). We've already highlighted some [concerns](https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1612522047) 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](http://angi.com/), [truecar.com](http://truecar.com/), and [wayfair.com](http://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.

1. 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](https://groups.google.com/a/chromium.org/g/blink-dev/c/9s8ojrooa_Q).

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/723#issuecomment-1910815616
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/723/1910815616@github.com>