dbaron: I think the implications are pretty interesting. I've forgotten more than I knew about it, somehow.

dbaron: there are various browsers that treat more than an origin as "lumped together" - this would gives sites some control over that grouping.

hober: I have a concern. Say I'm a nefarious actor, and I go to companies and say "please put this thing on your web server that says I'm part of your first party set". Seems like a way to subvert the understanding of the first party/third party distinction.

dbaron: Mike has some mitigations for this. For example, you can ask one party to do this, but if you ask two they have to put each other in their first party sets and they have to do it in a synchronised way.

hober: That's probably good enough? Though I'm hesitant to ever say "good enough" in relation to security. I can ask colleagues for feedback. Google homepage has like 100 different domains, this is a difficult problem to solve without everyone having to maintain whitelists.

torgo: Good idea to ask for feedback; please ask your colleagues to weigh in on the issue directly. How about we bump this a few weeks... I'm going to put it on 4/2, we can come back and see if we have any substantive feedback. Do any other implementers have any feedback on this? Microsoft?

hober: I assume Mike and John (Wilander) are already talking about this, I don't think I have a lot to add...

Lukasz (in minutes before he left): MW's reply on GH looks good to me.

Dan: David, have you read mike's comment?

David: not yet

Dan: move to face-to-face; Mike is joining us there

Dan: we have had some feedback.

Ken: agree that is what is happening on the web today. Same issues when working on the web app manifest, microsoft commented they had multiple domains they considered the same. Not an invented thing, actually an issue.

Hadley: my instinct would be to put a lot of time and energy int listing everything this is going to break. Same origin policy... and issue a finding. I don't know if we've got TAG consensus. It feels like this group are arguing that thes ame orogin policy doesn't work fo rthem so they want to change the web. I'm not convinced on fthe use case, and second the knock on effects of doing this..

Dan: yes, concerned with the knock on effects. The potential for abuse. They are talking about how we'll have these allowlists for ... there's always an angle, a commercial angle, business angle, a we-know-these-people angle

Hadley: very different from whether someone gets a TLS cert from a cert authority, authority is not passing any judgement or saying anything about how someone interacts with the site. They're just saying "we've issued this certificate to this website".

Amy: what happens if different browsers implement different allowlists?

¯_(ツ)_/¯

Hadley: in an unhelpful world each site could have different allowlists per browser..

Yves: some mistakes might disclose information from a site to the owner of the allowlist. if you accidentally add another site to the FPS that you are owning then you can get informationa bout new cookie from there and retreive it.

Hadley: interesting hack.. if you can get into a site's allowlist and add your own site to it suddenly you've got... could you borrow their auth tokens? Get someone to log in yoru site and have access to others?

Yves: go over the restriction that those cookies won't be reused, or can use them as remote login

Dan: what user visibility will be present? It seems like they're assuming there will be a user facing prompt that says .. that allows users to accept that the browser will treat these different domains as the same organisation. That seems to be.. not well thought through. Other potential for abuse is an ad network that is able to claim "we're the same org" and has a relaitonship with a browser maker, will therefore have a very strong competitive advantage, over an ad network that doesn't have a relationship with a brwoser vendor because they can say that their ads are all .. they can take advantage of the FPS allowlist. There's an antitrust almost thing?

Hadley: antitrust isn't our thing. User expectations and user trust is our thing. If the browser is no longer just serving the user but is serving the ad network that' screws up the web.

Dan: question.. considering the feedback from Mozilla and webkit community is that they find this deeply flawed. Is there any way.. under what conditions is a first party set like proposal acceptable? What are the mitigations that we and the rest of the community would find acceptable? Eg. full visibility of the allowlists within the browser UI prompting ability to turn off the feature. Things like that? Visibility to ad blocking extensions. The list of things that would need to be in the mitigations or privacy and security in order to make it acceptable, if that exists at all.

Hadley: good quesiton. If we take the example of facebook and instagram, which are two we've talked about being put together in a set, I can't imagine without designating browser UI a scenario in which we'd feel comfortable with users having the expectation that one is the other, that logging into one means you're logging into the other, that they have the same cookie access. All of the mitigations you've talkeda bout can try to teach users that the web is doing something new and different, which may work..... but.. I'm struggling to think of something we could do with the existing features that would help someone understand that if they've given access to facebook to their microphone that instagram should have it too.

Amy: whatsapp is even worse in that set

Hadley: different use cases, they are used in different ways, eg. location

Dan: one place that permission prompts is mentioned in the explainer is avoiding the use of valuable screen real estate or presenting confusing permission prompts.. which sounds like exactly what you're talking about in that they are subverting users expectations. If you give instagram access to your camera, are we then.. if fb and instagram are in the same FPS are we giving facebook access to the camera as well? Which users would probably not agree to. They say it's an explicit non-goal to to have information exchange between unrelated sites for ad targeting or conversion measurement. I agree with Hadley that we need to have a more detailed feedback document at least. It could be a finding depending.. a finding would be a nuclear option. I would rather find a way forward where eg. it could say FPS only applies to these targeted cases and doesn't apply to permission prompts for access to bluetooth or camera etc. It could really narrow the scope.

Hadley: right about finding being a nuclear option, that sounds sensible. Probably good to have that conversation, I'd still be frustrated. But better than having a wide scope.

Dan: have a dedicated TAG/google breakout on this? Where we invite Mike and ..

Ken: I would be supportive of that.

Dan: discuss in plenary. Also a question of this is being discusssed in the privacyCG, would like Tess's feedback as well. Tess might be aware more than we are of what mitigations are being discussed.

Hadley: sounds good. If it were something that were just being discussed in the privacyCG my instinct would be to let them continue to hash it out, but we're seeing other specs being built on it

Dan: we're seeing other specs referencing it as ground truth and my impression from attending the privacyCG call is that they were not very receptive to feedback.

Hadley: anywhere in ethical web principles that the user agent should serve the user? Part of my problem with this is the potential for my user agent to have advertisers needs in mind ahead of my privacy needs. That feels like an ethical thing. We hit it in priority of consistencies but I dn't know if we say anything explicitly about the role of the user agent. We do say atthe last principle UAs represent preferences on the user's behalf, respect user authority. Something there.

Dan: we could put an extra sentence in The Web is for All People or the Web Must Enhance Individuals Control and Power

Hadley: open issue

Dan: the concerning thing is the way it changes the Web's security model. And the knock-on effects of that change. The other question - what changes with FPS? is it just configuration? People are already doing this. I can go onto youtube and it'll ask me to log in and it'll just dance me over to google, oauth me, and I'm back to youtube authenticated as my google identity. This already happens. Sites are already able to do this across domains. What changes with first party sets? Is it easier? Faster?

hadley: or without the user seeing it

Dan: I sat in on this privacyCG call and saw how aggressively google is pushing this forward in a product management way as opposed to a technical spec way... I left feedback. How are we going to mitigate against misue, creating a third party ad network by redefining third party and first party? One of the answers was "we" will make sure that all the domains in the FPS are the same org

Tess: who determines that?

Dan: in what sense are they affiliated? In some senses amazon.com and .co.uk are the same, but for data protection they are not. Different regulatory regimes. Facebook and Salesforce are very strongly in favour. Use cases I'm hearing are not thinking through regulatory and data protection issues, that concerns me. Might be other things we need to examine more closely. Google are trying to build other specs on top of this spec. We've pushed back. Hopefully we can examine different parts and feedback architectural issues.

Peter: lukas has been blogging about CNAME abuse..

Dan: Discuss more in breakout

Dan: I've been thinking about this... Hadley's opinion was we should write more substantive feedback. That feedback should center around the fact that the web security model is based on origin and origin is tied to the domain name system. The proposal on the table from the FPS folks by design is that the current origin system does not work for the use cases they want to accommodate and we're uncomfortable with making such a basic change to a fundamental layer of the web architecture without being extremely careful and that some of the discussion that's come back when we've asked questions has indicated to me that there's not full consideration of the implications, despite there being a lot of work going on. Things like "we" will make sure all the FPS belong to the same organisation, and how do you do that? Very handwavey. In practice is impossible. Because the browser would need allowlists, and talking about allowing these orgs to set up their own FPS so.. We need a document that pushes back on this concept which articulates the conditins under which we would be happy for FPS to exist as part of the web. Those conditions need to be it's limited in this way, only works in this way. Eg. we asked does this apply to permissions? If I give my permission to insagram to use my camera am I also allowing facebok? The response was no it doesnt apply to permissions. SO what does it apply to? Some is in the spec, but it's not very clear, and especially the name is FPS it sounds like everything where we're thinking about first party and third party this will apply. We need to come up with consensus that the TAG can sign onto which is pushing back or listing what we think are the criteria that we would like to see implemented in the FPS proposal. And the fact we've had negative feedback from other implementers. Even if we say we think it would be okay under these criteria there's no guarantee that other implementers would also say it. We shuld also take that into account.

Amy: +1 can help write

Sangwhan: it's not good.....

Dan: they have a section about why it's not intended to support ad networks

Sangwhan: it will

Dan: it will and there's a designa pproach here which is that from a google pov protecting user privacy is about protecting privacy between the user and google. From a Brave pov google is one of the things to protect the user from. There's a mismatch there of the threat model.

Sangwhan: these companies go to great lengths to track you, CNAME cloaking, ad companies have been using. FPS on DNS level.. suborigin on your domain.

Amy: the bit about it's not supporting 3rd party ad network - right, it only supports google's ad network. It upsets ad tech people and people who are against surveillance capitalism.

Dan: Facebook and Salesforce also came out in favour of this propsoal.

Amy: it supports compamies that run big ad networks.

Dan: there's an arguement Andrew Betts made in the discussion about AMP. When you have ad networks with sufficient power they can compel third parties to do whatever they want. If you've got an ad network that is supplying revenue for parties like the guardian or somebody they'll be very incentivsed to instrument their webpages in whatever way the ad network wants to get more revenue from that ad network, including in ways that leak their users information without the users knowledge. We can start a document with me Amy and Hadley and come back to the TAG

Sangwhan: any piece of tech that looks innocent is going to be abused to serve ads.. CNAMEs looked very innocent..

Dan: any sufficiently advanced web technology will eventually be used to serve ads.

Dan: there has been some back and forth between krgovind and John from Apple. Maybe we should schedule a breakout breakout between Hadley, Amy and me? The point Hadley made about wanting to have a more full response to FPS if we want to be impactful.

[extra breakout scheduled for tomorrow]

• agree the feecback we want to give, pick times for a special breakout

Tess: if we tightened up same origin policy somehow.. if we slowly changed the default for cookies to be same origin only slowly over time we might not object to that architecturally, maybe for compatibility, but not philosophically. Making same origin policy more consistent and faithfully applied. That this is loosening it is the concern. Good to word it as change is scary to an important piece.

Dan: FPS expands the scope of origin. Maybe better to rephrase to be more dispassionate.

Tess: you could use loosen instead of expand, weakening instead of attack. Be more specific when talking about being cautious about change, about weakening the policy. Example - if someone were trying to fix holes in the same origin policy that exist now like same origin cookies, our concern with that kind of change would not be philosophical it would be pragmatic. That would be strengthening the same origin policy. Not that all change is concerning.

Amy: I can't find actual concrete use cases for why they want sites to be able to declare sets

Tess: some browers have hard coded lists for tying domains together, for authentication and autofill stuff.

Tess: crawling all of the .well-known to build a comprehensive set might be challening....

Tess: inject js needs to be softened.. there are user centered features that rely on browsers doing script injection, eg. reader modes. can be at the users behest, that isn't invasive.

Dan: makes things more complicated for web devs. We have a principle about not having too many manifest type things.

Tess: we're correct in saying hold off on building stuff on a rickety foundation... but if we say there's not evidence for the additional complexity..

Dan: we also need to talk about scope for us to be comfortable with this architectural change

Tess: be specific, make a list of use cases. We can say "in its current form".

Tess: we don't know what all the problems are, we don't know what they're trying to solve. To the extent we've identified concrete use cases we believe they can be addressed in other ways. We need them to show their work.

Tess: is there something we can cite about not building new things on top of new things. Add on top of stable things. Incremental things. I'll look around.

Dan: it needs to be implemented by multiple browsers to be viable

Moved to next wee

Dan: no update yet. They're still working on it.

Tess: that's fine. PrivacyCG f2f coming up

[bumped to w/o 5-24]

Dan: I had a conversation with Kaustubha, asked her to comment on the TAG issue with the stuff they've done to help us concentrate our effort on what we should review.

Amy: no response on my issue

Dan: I've emailed the requestor ...

[bumped]

Dan: Last discussed in Privacy CG last week

Amy: the enforcement stuff doesn't sound like it belongs in a w3c spec

Dan: agree

Yves: getting traction from different vendors... position of power with regard to who you accept.

Dan: would be an interesting data point to know if another browser is interested? The last I heard from MS was that they were interested in a technical-only enforcement. In the PrivacyCG minutes Kaustubha talks about the policy thing.. Asks "Do we think controllership is publicly-verifiable?" and gets into enforcement policy of who gets to be in a FPS

Yves: how do you enforce that?

Dan: right? What's the redress mechanism if it's wrong?

Yves: can it be user overridden? Should the user say two companies should be differnt things?

Dan: and in some countries the regional data authority thinks they're different things even with common ownership. We keep pointing out the issues with having some kind of enforcement mechanism that is not technical and we should be stronger on that point

Yves: mitigation could be giving the user the possibility to split FPS? and opening the gate to extensions that can do that

Amy: Concerned about that - pushing it to something else - ie an extension - to address the privacy harms... Lots of people aren't going to bother with extensions or sorting FPSs themselves even if there are privacy harms

Amy: data on ownership of legal entities - there's little to no public data on beneficial company ownership. IEE is a concept they've invented. There are hoards of investigavie journalists spending all their time talking about company ownership structures... It's not realistic just saying 'we can look for some company ownership data' - they get to some of this later in the privacy cg minutes

Dan: Different in every country - the feedback should be - this is not stuff for a w3c spec

reviewing open PRs on First Party sets

Dan: PR 65 still mentions enforcement agency..

Amy: not sure of enforcement agency becomes optional - could be multiple? - or still a requirement

Yves: how it works across international borders... It's moving with discussion in privacycg, on hold until they have a statement?

Amy: worried about a technical-only enforcement thing - it may only be solvable as a legal/jurisdictional issue which just puts it out of scope for w3c. Maybe the discussion can continue and they need to figure something out... but maybe it's not possible.

Dan: Maybe first party sets technical spec just needs to punt on the enforcement and say it's out of scope for w3c? But then that opens the door to...

Amy: saying 'how are you going to enforce this to avoid abuse?'

Hi we are tracking some good discussions going on in the [Privacy CG](https://github.com/privacycg/meetings/blob/main/2021/telcons/09-09-minutes.md).  It looks like there is some substantive discussion going on there about enforcement policies.  Our view is still that any kind of centralized policy-based enforcement of which parties may claim to be together in a set is problematic and that a technical-only enforcement mechanism may be preferable. However they may not be a technical-only enforcement mechanism that works in the real world because of the complex structure of ownership of legal entities and data sharing legislation globally.  We await the outcome of these discussions in the Privacy CG and would be happy to spend time reviewing PRs as appropriate.

Amy: asked https://github.com/privacycg/first-party-sets/pull/45#pullrequestreview-689239363 :

In general I think I'd like to see a lot more about what happens when a UA doesn't implement FPS when others do (including what happens to older browsers that are never going to get updated); and when different UAs ship with different FPS lists. How badly can things break from an end user pespective, and from a site owner/admin perspective?

The case I'm particularly worried about is sites blocking access to UAs that don't implement FPS (because they're old, or because they choose not to for privacy reasons) or users who have FPS turned off.

... but don't see a response, will open an issue.

Amy: interesting issue about purpose of FPS

Dan: k provided a respoonse...

Hadley: ua policy doc is thorough - I'm getting closer to seeing what she's trying to accomplish - establiisng a definition of web site... that's making more sense. I'm still concerned about the abuse potential. She outlines an independent enforcement entity - i'd like to know who this is and how they're funded and what their motivations are - and does it cover the entire web? I'm thinking how much of this is for the western developd world - and further fragments the web. Is the web just a complex and ongoing software project for large companies. We shouldn't sleepwalk into that.

Amy: I also read the UA policy and had similar thoughts. Still a contradiction - K says a site can be in only one set - and in the policy doc it says... "site authors may choose to form multiple first party sets" - they are using domains and sites to mean different things.

Hadley: I highlighted that we need to talk about that. e.g. Google as owners of google.com, google.co.uk - and youtube as owner of youtube.com, youtube.co.uk.. but both under the same parent company

Amy: domains can't be in more than one set.

Sangwhan: all the google properties will be in one set...?

Amy: it'd be helpful to have a use case for that explained.. One party can participate in multiple sets with different domains.

Dan: facebook have a whole bunch of domains associated with facebook and a whole bunch associated with whatsapp. The way they're using this is all the fb domains are in one fps and all the whatsapp ones ar ein another fps, but technically it's the same party because they're both facebook. The party of facebook can have multiple sets.

Hadley: we should ask k to flesh that out.

Amy: what's the legal data question - if one party can put different domains in different sets there are data sharing issues... e.g. facebook has facebook.com domain and it's in a set with some other advertizers ... whatsapp with a different set of advertizers.. can data flow between those?

Peter: it seems like a legal & regulatory restriction.. you couldn't restrict it technically...

Amy: a couple of other things... i thought the stuff about implementing the UI surface in the browser sounds really good. If the browser surfaces it to the user... but I have the impression we can't standardize UI...

Hadley: we do sometimes put hints in ...

Amy: it seemed like we can't have normative text on this...

Peter: i don't think we can't have normative text - if there's a compelling argument spec could say it.

Amy: how testable is it?

Dan: we have reviewed lately apis normative text around notifications. W'ere not telling the browser how to raise the notification but we are saying they msut have a permission request. APIS that say you must ask the users permission.

Ken: apis just have the hook.. then you can always say yes, doesn't actually have to add the prompt

Amy: they suggested popups as a potential solution - didn't sound like a good direction. and that same quote about parent company owner/operator. that might not be applicable internationally, and might not be future proof wrt company structure.

Hadley: some people use parent companis to hide things... hide ownership ... there was a big issue in the press in the UK about companies not paying substantial tax... construct of trying to identify the parent company is not necessarilly helpful.

Amy: also not necesarilly useful to the end user - if the end user isn't familair with the parent company becaue they only know a particular brand...

Hadley: also: i wonder - if we were approach with cookies and cookies didn't exist would we push back?

Dan: yes knowing what we know now.

Sanghwan: yes many things...

Amy: will draft a response to the UA policy stuff ... I will run through k's other responses as well.

Amy: I've asked more questions and there hasn't been a response.

Dan: any action on spec or issues?

Peter: doesn't look like it

Dan: will ping

Dan: From the perspective of the TAG review issue, Amy left some comments, and I've been rereading our original review, and trying to understand where we've got to. Maybe you could give us an update on where you are, especially wrt the governance part of it, and any other updates?

Kaustubha: It's a hard problem from the policy and application aspects. Use cases for a single org creating disjoint sets - I can't say anybody has come to use with use cases asking for that. It's the answer I've given to folks who say if there's a size limit on a set, I have 300 domains which seems too large to me for a fps. I say I get there are 300 domains but do all of them have a common user flow through them? They might own a fastfood business and also an insurance business. THe user probably doesn't think of them as being thes ame thing, so there's no reason for them to be in the same fps. You don't have to think of every single one of yoru domains in the same set.

Dan: is that wording about user journesy centered in the... how do you define.. how do you ensure that the sets are being used for user journeys? I guess that is a core issue that we're wrestling with. User journeys as opposed to backchannel data journeys

Kaustubha: the original intent was to support these common user journeys, whether its consent management or login, use cases in the explainer. if you look at the policy document, we talk about common user journeys being one of the things we considered as a policy requirement and eliminated it. I've brought this up in privacy cg, if folks could think of a way to enforce it we'd be happy to reconsider. The challenge when we were analysing this in google was unless you had someone auditing all of your server code for the same journey it's harder to do that. It's a recommendation to the site owner rather than a requirement. Only form a first party set where you need to create this common user journey across these domains.

Amy: wrapping my head around org having disjoint sets but still sharing data that's come through both of those sets internally.

Kaustubha: when we talk generally about 3p cookies or any interventions, we assume sites are using clinetside state to share data across those domains, they don't have to use clientside, they could do backend joins on the server. I'd say that's out of scope for fps. We're specifically talkinga bout what clientside mechanisms or state you could have to share across those domains and how we can organise that and restrict that.

Harneet: about making it hard for us to technically implement the user journey aspect. We're using disconnect on Edge and we have the same cncept of an org having multiple different site and the ability to audit what sites belong to which org and identifying org boundaries.. not having an easy technical way of establishing user journey across different sites.

Kaustubha: disconnect is also the list firefox uses. The UI surface and normative language - I've been talking to colleagues in chrome as well, the sentiment I've heard was that because we want to allow uas to have the means to innovate on UI, having normative text around you must show this in a UI surface - an eg. is in chrome efor instance the origin info bubble or page info bubble is what pops up when you click on the lock for https, but perhaps there's a browser vendor that odesn't have that. the UI is important for FPS because that's the primary means the user agent can convey to the user that sites are related, in a world where other clientside mechanisms don't exist like 3p cookies. Where you can have the expectation that no two sites can share data without your permission, in that world, .. what I'm thinking is use SHOULD language to say user agents should inform users about how sites in the same fps have access to cross site data, instead of saying MUST use page info bubble to communicate the entire list of domains and MUST have a link to the privacy policy. Also wanted to ask how your thinking about normative language about UI generally in specs. And also the point of testing, in web platform tests there are no automated UI tests, but wanted to see if that's what you meant by testing.

Amy: I mean in terms of testing comnformance to the spec - so if you have SHOULD then how do you test?

Kaustubha: I think it's gonna have to be a manual test... Get current position ... all it say. Need to do some homework. A test that describes the goals rather than where the UI is placed...

Amy: Yeah from my perspective it's not about what the UI looks like (also because of non-visual UIs). Important to get it into the spec.

Kaustubha: The third issue [about corporate structures]... Amy you refered to UA policy document .. we have 4 diff bullet points - when there is an independent enforcement entity they will do work to enforce thos. When it comes to the actual enforcement we will need to talk to folks like Disconnect.me - to operationalize enforcement. We were trying to navigate that balance... listed 4 different options - how to bubble up group identity to users. Parent company just one of them. Co-branding slighlty different. We use parent company loosely... intent to

Dan: feedback rooted in discussion of the ways that different countries think about corporate structures that may or may not relate to data ownership. I have a concern about how it works across borders. How does this work in a country where there are frosty relationships with say the enforcement agency is a US nonprofit - what if now I as an Iranian media company want to use fps? There are laws in the US that forbid US orgs fromw working with Iranian orgs. This came up a couple of years ago because there were people of IRanian background and Slack was banning their accounts because they seemed to have been connecting to Slack from Iranian IP addresses when they were Iranian expats possibly in the UK who happened t have been visiting their families. That incident resonated with me. How does it work in these international scenarios?

Hadley: if we play that out, countries under embargo or under a trade dispute, would they set up their own enforcement entities? And if so, how does that split the web? How do we deal with mismatch between global geography of web and political geography?

Dan: right now the country based authority for the name registry owns that registry and there's a certain enshrinement of that approach. We continue in theory to have one web and ..

K: I don't know how it works in the pki world, the CAs are different from the registry entries.. how is it handled in web pki? The other thing.. if you're not part of a fps it doesn't mean that your site is going to be inaccessible. It's not as dire as saying your tls cert is revoked. It potentially means you have to build in things like some sort of login api or something.. whatever constraints browsers are going to place on third party interactions, Do you see that as too high a bar for sites? Sometimes there can be business implications, ads measurements across domains. If you can't measure you can't pay the publisher the money cos a user saw the ad on their site. That's the other thing brewing. I haven't figured out how to articulate it yet.

Dan: I do feel .. what we build.. we have this One Web principle, and we're also trying to make sure what we build is applicable to small web providers as well as large web providers. FPS should work for a chain of barbershops in manchester as much as it works for facebook and all the facebook properties. It should work across international borders. Anything we build should be applicable to small web as well as large web.

K: stuff to think about - will find out about PKI. I did want to dig on the question on the random spot checks. If someomne abuses that - then originally - when we proposed the policy a site would submit a list of domains and someone would check - including checking ownership. Some of the TAG feedback was that it doesn't seem scalable. In the dieconnect case it's not the entire web - they first have a blocklist and then an allowlist on top of it - and so we talked to some lawyers and .. common privacy policy common identity... were discussed. We could perceive tech checks but ownership is the hard one. Legal counsel says: if a company misrepresents the ownership structure that's in the pervue of the regulatory body they operate under - there are implications. We should make the definition crisper - and an org asserts that this is correct then the legal implications are a deterrent. We have built in abuse reporting as well - revoking - block list for misuers...

Dan: is that documented in the explainer?

K: in the UA policy document

Hadley: hihgly likely to be country specific and location specific. Presumably you have lawyers in a lot of different countries - be great to ask all of them for universally applicable wording

Rossen: interested to figure out controllorship and ownership respnsibilities and how that applies to .. curious how much will transfer into UA and how you're thinking through this. If I'm a German citizen in Germany my GDPR policy applies that all of my data goes to Germany even if I take my computer and I'm in Brazil on vacation. Now by me taking physical device out of geo boundaries I'm still having gdpr enforcement and my data goes back to the data controller and owner in this case. Controller and owner is the service in this case. When the browser enters this space I'm still trying to wrap my head around where do we stand as a UA.

K: a balance here is to make the policy as lightweight as possible. THe policy is to prevent abuse. As a brwoser we don't need to get too much into regulatory aspects - that'sr esponsibility of the site owner. If the regulatory agency requires them to get consent we should do that, not just ..

Dan: Can I encourage you write something?

Rossen: I get .. but what does that mean for a next step where the enteprise acquires a different company with different constituents, has a different privacy policy, etc...? I don't see what's stopping anyone from having a hostile acquisition mode where people acquire sets.

Amy: I think K would say that's addressed by regulatory. I also raised what about cooperatives... equally owned by members.. could have one set ...

Dan: Aren't we talking still about hard limits to the number of sites in a set?

Amy: there's an open issue on that...

Dan: sets for a specific reason, to support a user journey... a company could have multiple sets.. a set to facilitate a user journey, just because the buy another company doesn't mean it automatically gets added... they could have a different set

Rossen: it's a good point but...

Amy: they could but they don't have to... The numbers they were looking at for that max set size is 300, 1000.. not small..

Rossen: let's say Meta didn't have Instagram... all of a sudden they get Instagram ... has user generated content which is not part of their other network.. now you join these user graphs - creating from a user's point of view an undesirable experience...

Dan: because they could put them into the set together, following that logic, they wouldn't need user consent in order to establish a linkage between that users facebook account and instagram accounts because they would be under the same set so they'd be privy to the same cookies. Doesn't that bring up the idea of permission prompts?

Rossen: You can extend your graph without consent. Say this happened today... the domains are there, networks are there, users etc, but you don't have cookie sharing. They're stll third party from the pov of domains and the way they currently stand. That automatic cookie sharing that would be allowed by adding them to the same set and allowing cookies and state to flow between the two isn't there.

Dan: what happens now without fps is facebook acquires instagram and then they decide they want to merge user data and they ask the users of instagram to authorise facebook. There's a user permission step that the users have to agree to a t&c or to authorise so data can flow back and forth. In the fps world maybe the equivalent of that is the browser says "the set you were in now has a new party" - inform the user and make sure they understand they're okay with it. Or at the ifrst use of anything that includes a FPS the browser needs to tell the user who the set includes

Amy: there's language in there about surfacing it in the UI... Your point about a new party appearing in the set ... what if the answer is no. User is already invested in the services. It's not meaningul consent...

Hadley: also where regulators might get into the game -- if they approve the merger. When facebook bought instagram the dp regulator approved the purchase on the grounds that the data would never be mixed and then it was mixed... Another factor.

Yves: can a first party set be part of a business relationship -- result of a partnership? or only same set of compamnies?

Amy: the idea is the same company.

Yves: to be able to do some good statistics you might require you to be part of a first party set.

Dan: I think that's ruled out but the issue is it's not clear how they would police it.

Amy: In terms of how they police it - you can't check every site... their response would be spot checks. I think it's not good enough. So we have a loop. But: first party sets is use caseless by itself -- and leaning on this for same party cookies - and chips - maybe we should push back and say "come back with a specific use case"... If we were just gonna review same party cookies - and same party cookies redefined what a party is in order to have same party cookies then we might be able to think more productively about it.

Dan: trying to think what actionable things they can do to make something that will pass muster. We've gone round about different things. Early on technical only enforcement came to mind. There's no need for an enforcement authority or curation of allowlists or blocklists or anything like that if everything that constitutes a fps is done in some way that is technical only. However that would rule out that fps are only the same entity or ownership because that's impossible to determine from a technical only perspective. We could determine these sites all agree to be in a fps together. We could determine that no site is in some other fps. We could determine that fps are not very big, there's an upper limit. There might be other technical mitigations on top of that. All the domains need to be registered under the same registrar or something... or all need... some discussions about this already. Seems to have been rejected. And even in the case of tech only enforcement you still nee the browser to play the role of trying to stop abuse as a tracking mechanism

Yves: being able to define what's in the set gives an unfair advantage over people who would be required to pay to be in a set..

Amy: if we try to help them out - we should go back to what is it for - if it's for sharing cookies in a world where there is no third party cookies - how does that help the user? and if you enumerate the user needs are they indeed a match for what first party sets does? Can we do something better? Or do we not want 3rd party cookies in any form - cookies

Yves: SSO?

Amy: yes it's one of the use cases...

Dan: for SSO we need Federated Credentials Management. People already do SSO.. before fedCM comes along you don't need that because..

Peter: losing all 3rd party cookies might break ... something. There are other people working on fixing that.

Dan: I don't buy the argument that the web will break without 3rd party cookies.

Peter: but some people's business models will break.

amy: what if it's off by default and users had to explicitly enable one 1st party set at t a time... or would it just mean users are compelled to install an extsnsion which turns on a bunch of fpss.

Hadley:

Rossen: would [a non-technical user] be able to make sense of it?

Yves: they will turn it on because there will be instruction on the web telling people to turn it on...

Dan: or they'll use a mechanism of trying to trick people to prove you're not a robot by turning on fps... people are used to that now

Peter: i think it should require user consent and if the permission system is broken we should fix that.

Amy: I can't see a way of getting meaningful consent from users for all of this

Hi @krgovind we discussed today at our [virtual f2f](https://github.com/w3ctag/meetings/tree/gh-pages/2021/12-Madripoor)...  We're concerned we may be going around in circles on this.  One idea we had to break the cycle is to refocus our attention on a specific use cases linked to FPS - e.g. SameParty cookies or possibly CHIPS. This would enable us to go back to the problems we're trying to solve and maybe find better ways to try to solve them.  Would that make sense to you?  We could then take a look at the specific user needs addressed by those designs and evaluate FPS on the basis of those needs.  Yes: we had previously said that we would hold off on reviewing Same Party Cookies until we reviewed FPS - but by talking about Same Party Cookies in isolation we may be able to make some progress here. 

Amy: what do we want to say about tightly coupling it to eg. same party cookies instead of having fps as a standalone thing?

Dan: different from the layering advice we usually give, but I agree. Take some of the concepts from FPS and package them up with same party cookie and solve the problems that same party cookie solves without creating this general thing

Tess: Pete Snyder asks does this belong in privacy CG...? Active for a year... relatively frequently actively working on it in privacy CG... some members of the CG shared feeling that they feel feedback is not resulting in substantive changes... As far as how far along it is ... will it graduate from the CG? Due to the lack of multi-implementer inetrest it's unlikely to move to a working group soon.

Dan: What is the level of implementer interest? Is MS engaged? What other Chromium implementers?

Tess: some interest from MSFT... public signal-wise... for webkit have been mixed so far... beyond that mozilla have been consistent in lack of enthusiasm.

Dan: have the international governance questions we asked been answered...

They are engaging with us. But I haven't seen anything that addresses the core issues that we raised. No movement.

Hober: Given what's there, it's hard to see how we end up with something ohter than resolution:unsatisfied.

Dan: Yeah. I don't want to blindside them with that, and I think they're acting in good faith. But it doesn't change the situation on the ground.

Hober: there is a perception among a lot of people that this is something Google will do anyway. Full steam ahead. I agree that the editors are acting in good faith and doing their best to move this along, but I think they need to at minimum do more to help the public image problem. It doesn't matter if they are substantively changing things based on feedback if the perception is that they are ignoring everyone and proceeding at speed. It would help to put more time/energy into making it clear to observers that they're willing to make some fundamental changes.

Dan: Issues: lack of implementer support and that many of the issues we've brought up haven't been dealt with.

Hadley: can we list those, so we have a clear closing comment for us as well?

Torgo: these: https://github.com/w3ctag/design-reviews/blob/main/reviews/first_party_sets_feedback.md

Origin and the security model of the web:

We have a philosphical or maybe technical difference on this? They don't feel this changes the definition of 'origin', but in practice it does change the security boundaries built aorund origin.

Tess: existing security boundary is origin and privacy boundary is site. it loosenes the site boundary. On its own it doesn't, but what do you do with it? First party sets define the sets, but don't say how you use it. But other specs, like same party cookie — that's hwere the weakining is happening.

so they're correct that they aren't...

torgo: except that, re vagueness of scope. This seemed to indicate taht the scope of first party sets would be enlarged to things like cookies that are currently bound by origin. Everyone talking about this spec were saying 'security model based on DNS is old and we need something new for the web', which is also talking about weakening the origin boundary. So I feel this is valid.

Hober: I think we agree. the question is: what is this for? What will you use this for? We shouldn't add fundamental new primitives to the platform without knowing why we're going to use them. Ideally, we'd have a relatively complete model of where we're going to use them. If there is only one use case, we wouldn't add something ot the web. You'd want three r four use cases, and they'd have to be very concrete.

So if there isn't consensus around those use cases, it doesn't make sense to add those primitives.

This review is putting the cart before the horse. If we can't agree the purposes of first party sets are worth pursuing, then...

Dan: On the last call, we suggested focusing in on same party cookies. But we got pushback on that, since we'd said we awanted to do layering.

But I agree ith you, that we need to look at each of htese thigs in situ, because they all have different security and priacy issues.

Hober: it's impossible to review something in the abstract. We need know what they want to do with it.

Dan: maybe we shoudl revise this document

Hadley: I think that would be helpful, for us in future and for the community.

Dan: Include the first doc, then links to calls and issues and disucssions, and after all of this, we still feel that these issues have not been resolved.

Tess: I'll take a look and start to think about the new doc.

Dan: dropped from the Privacy CG...

Dan: my proposal is to close our review. We issued a document which said we're unsatisfied. We then had a number of rounds with the proposers. We monitored ths work as it progressed in PrivacyCG. We fed back a number of times. It doesn't seem like our issues were addressed. And the fact of it leaving Privacy CG due to lack of consensus is a bad sign for implementation. So I think we should close and say something like "please re-open after this has incubated"...

Hadley: more mature or more stakeholders involved?

Dan: I think both...

Hadley: we should spell this out.

Dan: I also feel like we should say : we look forward to additional privacy-related specs that are decoupled from FPS...

Hadley: i suggest we spell it more clearly... These concerns extend to any spec or feature reliance on first party sets, though we look forward to additional privacy-related specs that are decoupled from FPS.

Hi all. We have revisited this again in our W3C TAG meetings this week.

The TAG has agreed to close this review. We began our review buy writing this [statement](https://github.com/w3ctag/design-reviews/blob/main/reviews/first_party_sets_feedback.md), and we have since dedicated extensive time to providing feedback and engaging with the spec authors to improve this design, and do not feel that our suggestions are resulting in evolution of the feature.

We remain concerned about a number of issues, including the privacy implications of this design, and the problems that could be created with any of the proposed governance models for first party sets. Equally, we haven't been able to come up with a governance model that would avoid the same problems. 

These concerns extend to any spec or feature with a dependency on first party sets, though we look forward to seeing additional privacy-related specs that are decoupled from FPS.

We understand that this work is moving to WICG, and will be happy to review future documents that address the necessary use cases after further incubation and demonstrated support from other stakeholders in the W3C community.

[nb: text now includes edits from Amy from the plenary.]

Dan: Ok let's discuss and move forward at the plenary call.

Hadley: agreed - want to get Tess's feedback.

Dan: No updates since last time we looked at this.

Dan: not sure if there are recent updates to the spec

Hadley: looking at the I2S thread in Chromium... they stopped at the end of June - their metrics analysis identified an issue in "core web vitals" - pausing the roll-out. Problem for them but .. hard to tell.

Amy: so should we give feedback on FPS specifically - looking OK as a standardized registry - but with warnings of what you use it for?

Hadley: fps rsa4 dependency?

Amy: for rsa4 they have gates... and fps can be used as one of those

Hadley: they do also say you could gate on user prompts... leaving the door open for other possibilities...

Amy: We asked these questions... about rsa4 - i'm wondering if there's something we can do to move fps on from our pov...

Hadley: we can ask why it's stalled and what they're learning.

Hi, we are looking at this at our TAG f2f. We're noting a pause in the I2S -- can you tell us more context about this and how any consequences might impact the design of FPS, especially any of the aspects we've discussed in this review?

Amy: also noting their issue 167 - feedback from people working with early implementations... so they've shipped something.

we go back to and re-review our original feedback on first party sets

Dan: we focussed a lot on origin, feel like this is one of the key things we got criticised for - they said it doesn't change the origin model. We said it does change the basic security model, especially if you start building other things on top of it.

Martin: the document does stand - if you go and replace origin with site or tld+1... the original position stands...

Martin: what's changed in the intervening time isthat google accepted storage access api as the safety valve for a lot of problems here. They've integrated storage access more deeply with related website sets. That changes things substantially in two ways - first, storage access api exists as an option on google's platform and websites can exercise that option. They've accepted this is part of the way web is going to work now. Second, they've changed the way in which related websites work. They've changed the criteria. None of that really matters - what matters is they've used related websites sets as a shortcut for approving storage access. That's a design change. If someone doesn't get to choose, they don't get to choose - that's the core of the disagreement - taking away peoples ablity to choose

Tess: storage access is asking a question to the user

Martin: this is taking that option away from them

Tess: right

Dan: in the meantime hasn't it become more like a registry?

Amy: we can't just talk about it in isolation...

Martin: there are lists out there such as the PSL.. PSL takes away capabilities primarily. Whereas this is about granting web sites capabilities... All of the original feedback still stands.

Dan: are any other browsers interested in this?

Martin: I believe MS

Dan: they have said that other browsers do this - all have heuristics which effectively do this, and all this is doing is creating a transparency around it so isn't that better?

Martin: I think we [Mozilla] managed to eliminate basically all of those - our move to full partitioning meant we elimited most of the lists we were relying on. I think it's wrong. Those lists were transitionary. They're constantly removing things from it, we're not attempting to build something new into the web platform.

Amy: we discussed this early on I think... it feels like standardising a workaround rather than fixing the core problem that led to the need for the workaround.

Martin: the auto grant capability is implementation defined - which is to say we don't think this is subject to standardisation, or part of the cross-browser agreement. I think we might need to explicitly reject that.

Tess: they don't have consensus with everyone else shipping the storage access api that an implementation that does this is acceptable

Martin: taking that off the table is problematic

We acknowledge that our use of the term origin in this feedback may have lead to confusion, and that we should have used the term site in this context. However, the fundamental points raised in that original review stand.

The primary change here is a reliance on the Storage Access API. However, the decision to automatically grant requests has the same net effect as in the original proposal. We do not think that labeling an auto-grant decision as "implementation-defined" is acceptable, as that defines how the web is experienced by websites and users.

The argument has been made that other browsers ship heuristics that do much the same thing. Our argument has been and continues to be that these heuristics are essentially a workaround and that we should not be building new technologies into the platform that cement this way of working. Furthermore, we observe that many browsers are working to eliminate the need for these heuristics.

We are therefore re-closing this review.

we agree to re-close as unsatisfied with the above comment