Dan: thoughts on turtledove: it's in WICG. Why isn't it in Privacy CG? Where is this going for standardization after WICG? Says "unknown" but what is the thinking? Its not clear from the link provided on multi-stakeholder descussion whether there is any interest from additional implementers or stakeholders in this API. Can they please be more specific? It's not immediately clear how this relates to the topics API since it looks like this is trying to achieve the same aims but there's no reference to the topics API in the review request or the explainer. It looks like this proposes each ad request be doubled - one request for a contextual ad and one request for an ad "indicating an advertiser-identified interest" - at a minimum this would would double bandwidth requirements for ads which would be problematic from a power consumption / network usage PoV. As I understand it, the contextual request and the interest-group request are sent at the same time (and the browser decides which one to display). However the interest-group request does not contain contextual data such as the URL the person is visiting. This is claimed to be a privacy benefit but couldn't the ad network easily correlate these requests considering all the additional metadata they might have access to including timing and IP? (They have some mitigations listed... ) The idea of an on-device auction is worrying from a power consumption perspective especially when the user is likely on a smartphone. It seems like they are thinking through some of the privacy issues - however the proposal is rooted in "how do we support the existing ad ecosystem".

Dan: leaves comment

Amy: how does it related to topics API? Also could be an OK way to add targeted ads but maybe we shouldn't have a specific API for targeted ads for the web platform?

Dan: not sure of the provenance - and why it doesn't reference TOPICS...

Amy: In WICG.

Dan: Two technical issues.. one is doesn't this mean every ad request will now be two ad requests? One request for untargeted and one for targeted, doubles the amount of energy/bandwidth/etc being used. The other thing is what's to stop .. I'm not convinced that these requests cannot be correlated on the backend in an ad network. They claim that there are mitigations against the network being able to correlate the requests so you wouldn't be able to tell which page you're on or who you are, but the contextual ad mechanism would know which page you're on. What's to stop the ad network correlating those by ip address or other fingerprinting information available through http headers etc?

Amy: no - i don't have an answer... they say there are mitigations in the privacy & security questionnaire.. it would be nice to know if they are concrete technical mitigations... The stuff about the double requests... the concept of running an ad auction on the user's device seems quite heavy..

Dan: yes.

Amy: in the goals of the API there is a lot of stuff about opting out -- possibly having this stuff more in the browser gives the end user more control. A browser of a company that sells ads might not be motivated to surface that UI in a useful way necesarilly.

Dan: the wording seemed weird about that stuff.. talking about how users can turn off targeted ads if they don't want to see them.. but wouldn't the ad network still be correlating the information about them? It's not about the user not seeing the ads, it's about the .. the user seeing targeted ads is a symptom of the ad networks holding a bunch of data.. but I understand they think there are technical mitigations against correlation but I feel like they need to ask more. They haven't responded to th equestion from 8 days ago

Amy: will leave a comment

Hadley: was wondering about the browsers joining interest groups part of the process.. the user or the browser is opted into a set of groups that can be used to advertise against .. would be good to find out how they think that will work and not run wildly out of control.

Dan: we have a comment from the requester. Saying there's a tradeoff between network based computation and clientside computation. Doing it on the clientside means yu're having better speed and reduced latency and reduced network usage. That kind of addresses the question I had about using the network more. So where do we go now? What's the implementation plan? What do they mean by experiment?

Sangwhan: with FLoC they implemented it as a chrome extension and pushed it out to some people and a small subset of the google ad network used that extension to serve ads as a prototype. I think tha'ts what they'll do with this as well. The final implementation itself is probably inside the browser.

Dan: how thorough a review should we do at this point, vs waiting to hear feedback from their trial?

Sangwhan: it's sensitive enough.. there are several competing ones

Amy: there are other competing proposals that are similar but different. Would be weird if we reviewed one but not the others

Hadley: why have we got so many competing proposals without collaboration?

Amy: I understand incubating lots of things if you have enough people to throw at the problem, but bringing one to TAG review at this stage is premature.

Sangwhan: is there grou pconsensus that this is the best proposal, or is this here bcause of the blink process? Which are obsolete? What are the relations? We could push back and only review what the group has agreed on. Not sure if this is one of the final proposals

Amy: We don't want to discourage early review in general but it's weird to review one when there's a whole load of proposals in the space

Sangwhan: they want to do an origin trial and implement it inside Chrome, not an extension.

Dan: what is the path to consensus?

Sangwhan: maybe getting data and deciding based on that

Dan: proposed comment

Hi Paul - 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?

Dan: they haven't responded to my feedback - I will ping Chris H. from google.

Hadley: similar position to attribute reporting.

looks stalled - we need to have a focussed session on this

Amy: they want to ship as an experiment... as Fledge... not sure whether we should be looking at fledge or turtledove https://github.com/WICG/turtledove

Dan: I'll leave a comment apologizing for taking so long and asking them for an update.

Dan: leaves comment

hi @JensenPaul - we [understand](https://github.com/w3ctag/design-reviews/issues/838#issuecomment-1634120833) that this proposal has been renamed **protected audience** - can you confirm and let us know status? Should we keep this item open, or has the design changed so significantly that we should be opening up a new review?  If should keep this open, should we re-name this?  Can you update us on any dependencies we should be aware of?  Many thanks!

Hadley: UA making the decision which servers to trust... seems like a way it could all fall apart. How would you know if UA was unscrupulous?

Rossen: how is the user data managed? is it per account? if I have my own session and I'm logged in mas myself and then I log out so my daughter can use the computer for school, is she going to be targeted with running shoes because that's what I was looking at before that?

Hadley: not clear. Arguably unless you'd cleared your cookies with 3p cookies that would happen?

Rossen: with the browser account which usually has the ability to integrate with web content as well. I'd be surprised if they didn't think about this.

Hadley: explainer says browser keeps track of the set of interest groups joined. Up to the browser how to handle it?

[discussion about taking state out of the web and into the browser. Eg. browser account management is not standardized in any way, whereas with 3p cookies browser is just a transport/storage mechanism. Giving more power to browser, a direction we want to go in? ]

Hadley: browser provides protection against microtargeting by only showing ads shown to a sufficiently large number of people - how does the browser find out how many people saw an ad? In a way that preserves privacy of user?

Rossen: is the identifier the ad? I can imagine an ad id that I can ping the server and the server gives me back a number.. as long as I don't send any more data to the server

Amy: is the server motivated to lie to make sure people see the ad?

Rossen: there's that. And I have to go back and tell the server +1

Peter: the browser is also running the ad auction so I don't know if the browser has to go back to the server. Part of the auction process to know who won.

Peter: the api for running an ad auction.. there's a lot of urls.. hard to understand how this could be abused. A lot of vectors for abuse

Hadley: and a lot of traffic.

Peter: true, but the current ad network genereates a lot of traffic. This is probably less. Not uncommon for an ad auction to go through 20-30 different vendors

Hadley: does this make all of those requests my problem on my network?

Peter: also it's talking to soembody to run the ad auction. What's stopping them from passing this on upstream?

Hadley: and what's stopping the browser from .. right now ad blockers can operate because the browser is separate from the advertising process, so you can ask your browser to treat ads differently. What's stopping browsers from saying you can't use the web unless you participate in our ad network?

Amy: competition between browsers, but that's not ideal because not everyone knows there are other browsers..

Hadley: and what if every browser went that route for money?

[discussion about browser as UA vs browsers as advertiser agent]

Hadley: this biases the system towards ad networks that are aligned with the browser. Not good for competition.

Amy: it kind of moves the probem rather than solving the problem

Peter: I see where it can improve privacy for individuals, a little -- I'm not sure it goes far enough. But i have very big concerns.

Amy: why do they need this as well as Topics? They have an 'alternatives considered' section that mentions Floc but I'm not sure if that's still current since Floc is Topics now...

[trying to figure out difference between this and Topic.. "remarketing".. more specific about having had an interaction, rather than generally this kind of person]

Amy: is it the same mechanism as topics? but more granular? So one of the mitigations for privacy in Topics was to make it less granular

Peter: browser can offer user to join groups for an item. Site gets to decide level of granularity to register

Hadley: can the site pay more to have a monopoly on the kinds of ads the user sees afterwards?

Peter: the only reason a site would make that call is because they intend to advertise to you later on other sites

Hadley: like opening up your 3p cookies to others who want to know you have a 3p cookie about a particular thing

Peter: I think this is all this accomplishes. And reduces information about what can be stored in the cookie. Concerend about how far that can be pushed. WE've already seen how advertisers can target individuals on the basis of data we never thought would be unique or personally identifiable. The one thing about this I do like is at least ideas in the explainer about UI controls. allows the UA to do things like keep track of what ads you've been shown and why. Who targeted you, what interest groups you're in, why you're on the list, block an advertiser. User could theoretically switch the whole things off, which is like blocking 3p cookies. If you're buidling a privacy prserving browser you can shut this off.

Amy: user settings for this is not realistic or reasonable - same feedback that we gave to Topics

Peter: it doesnt' give the user the ability to opt in - but surfaces the information after the fact. If every interest groups popped up a permission prompt

Hadley: everyone would be horrified

Amy: ... for 5 minutes, until prompt blind and agreeing with everything.

Amy: point them at the Topics feedback and say it all still applies?

The [feedback we left for the Topics API](https://github.com/w3ctag/design-reviews/issues/726#issuecomment-1612522047) is applicable to this API as well. The coarse nature of the set of possible topics has been proposed as a mitigation to some of our concerns there, whereas the set of interest groups proposed here seems far more fine-grained, an unrestricted. As we said for Topics, user controls for opting out of particular topics/interests are not sufficient to indicate informed consent to being tracked in this way.

some discussion on how this relates to Topics

discussion on how ad blockers or ad blocking web browsers might not implement or disable these ad tech specific APIs

Amy: locally executed decision about what ad to show instead of executed on the server...

[discussion about "ad creatives"]

Sangwhan: glossary about video. Wider glossary now gated behind a login

Dan: what does "temporarily relaxed version of a Fenced Frame" mean? Does fenced frames not service their use case? Can we clarify?

Amy: it would be helpful if there was a glossary from the PATCG...

Dan: the explainer should be self contained and explain the advertising jargon they use

Amy: we can add a bit to the issue template that says "are there any specialist terms of art you use in your explainer? Please include a link to your glossary here"

Dan: added issue https://github.com/w3ctag/process/issues/32

Dan: they got back to us just now with some additional clarity and info - will review and hope we can discuss in breakout C this week.

Amy: feels like it's doing the same thing as TOPICS, but more granular, and for the advertisers instead of for users... a load of ad-tech jargon but they have now sent us a glossary. ... a lot of work for advertisers on the user's device... from a privacy perspective it might be better .. but all the auction stuff is happening on the user's device... can't be good from a battery and network requests point of view

Dan: arguably not great for battery life ... power consumption ...

Amy: and just for performance in general...

Amy: I wonder if they have tested it on not the top end phones/machines

Yves: this is the auction....

Amy: but they don't mention TOPICS anywhere in their explainer...

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?

Dan: leaves comment

Martin: contextualize the whole thing... overall context is - number of people want to make sure ads continue to work - the ways it currently works are terrible for privacy... Google are looking at ways in which they can make small trade (privacy loss) for huge utility for advertisers. First area is attribution measurement (PatCG) - you put an ad on one website, measure it somewhere else. That allows advertisers to get a lot of value in a context where they get good strong privacy protections

Dan: that's an area where there are 3+ proposals in flight.. different types of measurement and they don't seem to be synced up, and this is frustrating

Martin: the PATCG's primary task right now is sorting out the three aggregator proposals. Two are starting to look like they're getting closer together, but we have a major question to resolve between those two and the other one. We can talk about that another time.

... The second thing is Topics. The idea is take some information about your browsing activity and give it to every website you visit so they can enrich their contextual targeting with information about you. I don't like it, the design isn't very compelling, but different perspectives might come to a different conclusion based on the same research.

... And the third thing is protected audience is convoluted. It doesn't have good privacy properties. If the baseline is a web which respects contextual integrity to some degree, it breaks down all of those barriers in a lot of different ways. The system of patches to cover up the holes are interesting, complicated, and oftimes not actually very effective.

There are multiple states to think about this proposal - the ultimate end state they're aiming towards, and all of the intermediate states with respect to their strategy for getting towards that end state. Currents tate - 3p cookies are a thing, and protected audience provides zero privacy protections relative to 3p cookies. That's the baseline right now. As google roles out the 3p cookies deprectation, the plan is to remove the very worst of the privacy holes in the proposal - intermediate stage. Lots of things on the roadmap for 2025-6 that are features related to that that they'll keep for some amount of time then introduce some amount of time and remove from 2026. Sometime in a two year timeframe they're going to start implementing stricter controls, and that's not the final state they're aiming towards.

The basic goal they're trying to achieve is to have sites build up information in the browser about you based on their observations of your activity. Then to use that information for ad targeting, without necessarily reveleaing what they've recorded about you or what the results of the ad targeting where. You'll browse and do some things of interest to advertisers - look at a product or read an article - and the advertisers will record that as an item of interest, which goes into a db in the browser. At a later point you'll go to another website, and that site will want to do remarketing or advertising based on that db. It sets up an auction, which is essentially a series of isolated js realms which run snippets of code from people who registered these interests. They can access cross site information in these js realms and use this information to make bids. you'll have multiple annotations across the web owned by a particular advertising business. The ad business will enter the auction, get ... look at items of interest, and decide what to bid on in the context. Fed information from the context, from the person setting up the auction, and the annotation they made, will go into this js realm. The person running the auction gets a set of js realms - they'll see each bid in an isolated context, with private information that has been accrued. They ask does this meet my standards for a bid in this auction? I might discount it or eliminate it. The ad might not be appropriate in the context. The browser will take the winning bid after bidding and screening, then show the ad. It can't just show the ad.. it has been derived from private information. It has to show it in an isolated context, so the webpage doesn't know what ad has been placed. Idea is some aggregated reporting system that will report on what ads were shown and hook into the attribution measurement that we were talking about earlier, so people who placed these ads know whether or not they were working.

Dan: what stops the ad network from knowing more information about the user's browsing history in this scenario? Why is it not possible for the ad network or some 3p to simply query and exfiltrate that data back out of the browser?

Martin: currently nothing. Currently deployed as it all runs and the URL is spat out the other end, you can just ask for it. Throughout the bidding process, the person making the bid can insert whatever information they want into the url, the screening person can add something extra, then at the end you can harvest that information. But the idea is that the js realms will be isolated completely and they won't be able to communicate with the outside world. This is an information flow control system where you have elevated privileges in terms of access to information, but lower priviligeds for exfiltrating that information. I have my reservations about the way in which that is possible, but that's the idea.

Dan: what's mozilla doing relating to this?

Martin: I'm engaged for communicating with regulators and folks like you. Mozilla doesn't see any prospect for implementing anything this elaborate, and with these privacy prospects. We think the prospects of it being sufficiently private in the near to medium term are basically zero. The amount of effort required to get it sufficiently private is phenomenal. We don't believe the current design is capable of maintaining the isolation required.

Dan: how this impacts marginalised communities more than other web users?

Martin: my primary focus is does it provide the properties that google claims it provides. Might want to consider whether it has good effects on equity or creates interesting power imbalances in the way the web is structured. From that perspective I've not spent a lot of time on that. I don't think it changes the situation significantly from what we see today. I'd say the overriding goal for this project is to preserve the status quo.

Dan: we in the TAG are taking a fairly strong view on deprecation of 3p cookies.

The other question.. isn't that what Topics is doing? How is it related? It's also collecting interests related to users browsing history. Why would I be implementing both topics and this?

Martin: I can't make firm statements about this. The way google talks about it is that they're complementary technologies. Topics provides a small amount of information about a person, it integrates well into existing targeting sysstem without too much work. This one is more complicated, difficult to set up and operate, vast amount of effort required just to get bootstrapped. They've got to set up servers and domains and they don't know what's going on because of reporting mechanisms. Topics is a small subsidy in light of the lack of cross site information coming into your ad targeting system. A very weak signal about someone's interests, and this would allow delivery of more specialised advertising experiences but at a much higher cost.

Amy: thanks for that - very helpful - we heart about why mozilla is following this. Do you know about other implementers?

Martin: I know MS are implementing. They're doing their own implementations - not just picking up the chromium code - with their own opinions... server infrastructure side... Haven't seen any other browser engine demonstrate interest...

Yves: on top of the companies themselves, there is the pressure of regulators that want to chime in on what is required or not. That may impact what different companies will implement in the end. It's a difficult question.

Martin: one of the reasons I think google are very much interested in this stuff is that they see the regulatory pressure from eg. the CMA is relevant here. They want to make sure that when 3p cookies go away then people whose business depeend on advertising, particularly small publishers, don't have significant reduction in the efficacy of their advertising. I don't know how to assess those claims and I don't know if anyone has a good graps of that. Research presented under constraints and conditions that are very unclear. Hard to know what the volume of the impact is on a news publisher. The research helps us understand there is going to be some amount of inmpact, but not how much, when they're competing with folks with a similar disadvantage.

Sangwhan: I don't knwo the full context of the limitations of claims google is working on, but the response I've received from the privacy sandbox folks is that the advertising industry that is not google thinks that the fact that google as a big ad company plus a big browser company having access to all this information even when 3p cookies are disabled gives them an unfair advantage, so they should have some level of information they need to serve ads, and that is what makes 3p cookie deprecation in chrome very complicated

Martin: small publisher industry folks are concerned about their advertising efficiacy relative to big players like googles. Removal of 3p cookies makes the value of 1p information that much greater. That skews the market in favour of big players like google. Some people claim that gives them an unfair advantage

Dan: we had a session with michael kleber where we go through this.

Martin: the CMA is interested in what everyone thinks, and taking this project very seriously. They understand the technical characteristcs of what's going on. The primary remit is the competition aspects, but understand that the privacy impact is important.

Hadley: we've talked about, with both this proposal and tpics, shifting the role of the UA from representing and protecting the user to representing and acting on behalf of the advertisers

Martin: more in relation to Topics.. uninformed legal opinion... if the UA truly is acting on behalf of the user and collecting information about their interests and giving it to other, that's the user acting to give information to people, which means they're far less constrained in how they use it. I don't subscribe to the absolute view that the UA has no obligation to anyone other than the users. There are interesting collective governance questions. Robin gave a talk on governance and responsibility. There is a role for the UA to act on behalf of users in the aggregate. Their interests might be represented 100% to the exclusion of all other actors, but the quities of all other actors in the system are so dramatically affected by the loss of 3p cookies, making some small allowance on the part of users for a significant gain for advertisers has a big effect for allowing the system to continue to operate. If the UA makes decisions in the aggregate with opt outs etc, such that people are able to support their business througha dvertising more effectively, then people will have access to content without subscriptions, and the net benefit to users outweighs the use of those APIs. I don't think that's a good trade with protected audience or topics. I think it's a good trade for the attribution work. Finger in the air analysis, will depend on things like the parameters chosen.

Hadley: helpful.. why is this more in relation to topics than protected audience?

Martin: there's a useful distinction. If you look at the ultimate goal of something like protected audience, the structure is such that advertisers get to use private information but they don't get to collect it, so the uses are tightly constrained and limited. The effectiveness of limitations on a technical level are something to examine. But the idea behind the whole thing is the uses are clearly constrained and concretely if protected audience works as intended, the only thing that advertisers will learn is aggregated information about the efficacy about particular advertising strategies - that's the goal that's being set. In theory that's attainable, in practice, a good number of years worth of R&D to go into that.

Sangwhan: there are many proposals being put forward .. some are competing, some are different ways of approaching a similar goal. What it boils down to and what we've been hearing at google is google's proposals are the ones that advertisers seem to be excited about therefore that's why they want to do it. I imagine there are other concerns and proposals also getting traction. We want the PATCG to sort out a winning solution. But finding consensus on a topic with no right answer is really hard.

Martin: at least on the attribution front we have a process in place now where we can make a decision. There are clear tradeoffs being made. Some prospect of reaching a conclusion sometime next year. The harder questions are wrt to topics and protected audience. A number of people believe this is not worth doing. Meta don't think this is a good idea. One of the properties of protected audience is that you don't get to know what ads are being displayed - that's a dealbreaker. MS say they can make this work, can implement the correct brand safety controls. But we haven't started on that conversation.

Sangwhan: on the non-google proposals, what reaction have we heard from smaller ad companies like criteo?

Martin: criteo have been constructively engaged. They're investing to some degree, and this is their jobs and they're taking it seriously. Not a clear signal about preferences. We've talked about optimisation for ad placements etc. They've done some work. There's a huge market out there, so there's a spectrum.

Dan: hIt feels like there are certain browsers who just don't want to use 3p cookies, and others who don't. We hear a lot of different arguments about why 3p cookies can't be deprecated, but browsers that don't use them are still use-able... Thoughts?

Martin: On those disabled 3p cookies, the storage drives an enormous hole. There are user engagement gestures and things in heuristics, but they have a massive play. At the same time, there is a desire to wind down those exceptions and find ways to put poeple in control of what's going on. I was an early proponent of FedCM work, but implementation has gone down a pretty bad path, but we're still broadly supportive. We have an implementation but haven't turned it on.

Dan: let's have a separate discussion about that

Martin: Yes. Also, all the anti-fraud and stuff.... it's languishing in a CG, and needs far more weight put behind it. WE've looked at the various proposals, like Web environment integrity. It's dead. The team were distressed at the reaction from teh community, didn't understand that. I've got a blog post coming this week on Privacy Pass, which is related. We don't think that works either. That leave s us with a hole... Areas with prospects: real world ID, gov ID, etc. Huge risk on other side, but yes. That will be something to take very slowly. One of the problems with Google's approach is they wanted to get everything in place before deprecating 3p cookies, a 10 year project in 3 years. Not worked well

Sangwhan: a lot of these hiccups are related to that. Not all of the team are browser people, they solve the problem they're given. Web environment integrity is a good example. Some people in Chrome think it's a bad idea.

Martin: there were a number of people who reviewed it. The folks who presented it to me said, "we thought this was in a bad place when we first saw it, but we now think it's better." One of my colleagues found it risky. And then it blew up.

Amy: We discussed user opt-outs... I couldn't find anything on that. With topics, we found a mitigation where user can opt out of a topic, one by one. (Privacy labour there isn't reasonable.) But with protected audience, there deosn't seem to be a limit.

And it seems like most of the work is happening on the users device. Seems excessive.

Martin: primarily, yes. But there is a mode where the auction is executed in a trusted environment in the cloud somewhere. Ends up costing more in networking and less in processing, but I think not. We'd like opt outs to be indistinguishable from regular user behaviour. the api continues to look like it's working... we don't have a convincing solution for protected audience.

Amy: That's well as a principle, but there shold be a way to enable the user to opt out.

Martin: it's possible to opt out... you could turn the whole thing off... you can still have the API accept interest groups... store info on what groups are there.. then you can "fake it" and pretend that the auction failed every time.. Will look like a new user, etc... but ultimitately the advertiser won't know.

Amy: we've heard that it's reasonable to look at each topic and opt out of each one... i don't think it's reasonable.

Martin: haven't looked at this.

Max: proposal says shifting from server side to browser side will have stronger privacy guarantees - any analysis or data to support this?

Martin: no. Isolation properties of the system - information goes into browser and websites can ask you to perform queries, run auctions, and ads are shown. There's so much leakage out of this system that I don't think claims about being able to maintain isolation are reasonable at this point. Maybe there's a future version that have privacy properites we can stand behind, but the current system is not reasonable.

...I think the TAG is in a position to decline reviews. This one is a signifiant amount of work, is a proprietary proposal. You could say something on whether the system should exist or not, like looking at whether opt-out is possible -- but I would not go into any significant detail.

Martin: doesn't make sense to do protected audience without fenced frames

Matthew: they haven't responded to our questions asked in November

Amy: There are a lot of issues with this, I don't want us to waste loads of time and effort to find a path forward when it's fundamentally flawed

Hadley: nudged them, labelled as stalled

Amy: we talked about closing this unreviewed at the f2f discussion

Matthew: we talked about what the impact of closing vs not closing would be. Is it worth trying to communication with that team? Also wanted to ask - is one of the objections to the api the registration? Not sure if they've changed that. That's a big aspect of it.

Dan: attestation and enrollment

Amy: yes that's good to raise .. they've got that on several of their privacy sandbox things now.

Dan: I'd like to separate that from the APIs themselves... suggested a separate review for the enrollement attestation thing. We could start a discussion, or a finding on this? Should it be a design principle?

Dan: I think we should start a design principle...

Amy: I might already be captured by design or ew principles on centralization or others...

Yves: RFC9518

Amy: should we prioritise moving the review along for the privacy sandbox requests instead?
Amy: they replied to our questions from the f2f -- they wrote "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". I disagree with the statemennt that you need targeted advertising in order for the web to exist.

Matthew: I respect that position - originally the CMA said "this isn't a good way to do it" because centralizes the stack with google only. So they advocated a proposal... since that they closed their investigation - but they [CMA] are monitoring ... But is there a third way? An option between "not having any revenue" and "it all going through one organization"... If you do accept that advertising is part of the web - isn't there another way - creation of a market...

Dan: but is targeting necessary? Contextual... etc...

Dan: even if you agree that advertising is necessary, does that imply that user tracking and remarketing are all part of that? e.g. blog post https://blog.sentry.io/we-removed-advertising-cookies-heres-what-happened/ that talks about alternative approaches to ads and marketing.

Amy: +1

Dan: we've heard about companies experiences with reomving 3p cookies and not having the same tools available to them, but they've bene able to work around them by using other techniques - not targeting but contextual

Yves: I think Robin posted something around those lines. When they say functionality of the web requires 3p cookies or advertising... it's not true, it's not part of the architecture of the web. It's a business model for many companies around the world. That's fine, but it doesn't mean the architecture of the web has to be bent towards that use case only

Amy: +1

Matthew: we've got several different places on the spectrum.. the intereting thing is where are the competing proposals that are at these different places on the spectrum? Why is there only one? There was another company wanting a market... and we've talked about different approaches.. I wonder where they're being discussed. It's not our remit to come up with alternatives. Be interesting to see serious discussion of them going on.

Amy: some in PATCG. Also not all of them need new apis or changes to web arch. Be good to discuss with Martin.

bumped to plenary

discussion on what we can say

Martin: some fairly fundamental flaws... it fails on achiveing the goals it sets out for itself.

Matthew: as the technical architecture group - are there technical limitations? Is this implementable? If not then we could close on that basis - our technical concerns.

Martin: I think that's a reasonable positon to take.

Dan: we could say it's not a fundamental part of the web if we think it's not a fundamental part of the web...

Matthew: not strictly a technical thing... We need to represent the people that elected us.

Dan: you're right that we need to represent the w3c community, however I think one thing that's part of that is that the w3c community have chosen candidates who have strong views on privacy, which I see as a mandate

Martin: I don't think our role here is the same as a rep in a representative democracy. We've been delegated this responsibility. To that end we need to be true to that to some extent, but what we're really here for is to provide technical guidence at the platform level - that's a broad remit, and we can exercise our discretion. There's a separate control that the w3c as a whole has, which is through the rec process. If protected audience ever gets to the point where it goes to a WG and comes out the other side I expect it would look different, then the w3c has an opportunity to say something about it. I can be true to my own principles, and tha'ts what I'm going to do in any of these things.

Amy: all technology is inherantly political.. pretending it's not is taking a stance in favour of the status quo

Martin: this is how the IAB approaches this problem.. when you ground your arguements in things in which you have expertise, your arguements are much stronger. As the TAG our expertise is perceived as being in a particular area - that's a far stronger position to take. We need to be careful to cleave to the things we're perceived as being competent at. Privacy is one of those things, so we can make arguements on that basis.

Dan: besides the technical comments can we make callbacks to the privacy principles document?

Martin: concerned about this issue https://github.com/WICG/turtledove/issues/990

Matthew: might consensus emerge around the attribution reporting...? or another area?

Martin: TAG has looked at fenced frames ... this is the fundamental flaw with fenced frames... And this is necessary for protected audience...

Dan: what happens when user is using a browser that doesn't allow 3rd party cookies...

Martin: coping mechanisms... e.g. contextual... asking people for primary identifiers... fingerprinting... fingerprinting-adjacent (e.g. looking at characteristics of things people are doing and applying modelling to match interest...) ... pseudo-science. Also very proprietary... Throwing ML at the info they have...

Yves: other browsers are not currently subject to the same scrutiny as Google Chrome is... Plain removal or 3rd party cookies leads to political issues because of concentrations of power.

Martin: isolation is unattainable as they've dscribed it. Core property of web platform - you interact with a site, and that site can keep it from other sites that you visit in the browser. The website has an interest in keeping its shared secrets with you separate from other websites you might visit. It's cooperative. There's another form of sandboxing that's increasingly important - preventing a site that you visit from learning that you visited another site when those sites both actively want to know that the same persion visited them. The sandbox we have is not built for that, fundamentally. We need to be up front and acknowledge that's a flaw in the web platform. We don't necessarily know how to fix but we're in the process of fixing it anyway

Dan: removing 3p cookies is part of that. The issue is - there are other ways to do this cross site recognition, there are already holes in the platform.

Martin: google asks websites to commit that they won't perform cross site recognition. I don't know why you'd ask them not to do that at the same time as giving them tools to do it, it's at odds. If you believed in that registration and committment it would be fine...

Dan: reliance on fenced frames.. which doesn't offer the protections when used in this context that it should be

Martin: it cannot

Dan: we gave a positive reivew on the original version of fenced frames, they requested a rereview because they changed it. That's still open.

Matthew: it's not our job to say how to fix fenced frames, although hard to say this if it's fundamentally impossible

Martin: i suggest no response...