There is one important use case for First-Party Sets that does arguably make it relevant to Privacy CG. Unfortunately most of us can't see it. (See meetings/03-24-minutes.md)

Company A acquired Company B in the 1990s. All of the outward-facing web sites have been moved to the company-a.example domain -- but internally, they have hard-to-migrate web applications still running on a mix of company-a.example and company-b.example hosts. (Maybe they lost the source code, maybe Company B licensed the software from some vendor that doesn't exist any more and the license key is by hostname, maybe they can't read their former consultant's code, maybe some other reason that only makes sense from inside their particular corporate IT environment.) Turning off third-party cookies entirely would break this legacy setup, so they have two choices.

Choice 1: Push out a browser configuration to turn third-party cookies back on.

Choice 2: Put an FPS in place for just the company-a.example and company-b.example domains.

The second choice could be better for their users from a privacy point of view.

It might turn out that FPSs should be something that enterprise browser configuration managers can push out just for users who need it. A CG that covers intranets or central browser configuration management could be a better fit -- but among existing CGs this may still be the best place.

This doesn't seem to have much to do with privacy, and more to do with a niche enterprise legacy setup that is not really a good fit for Privacy CG.

Enterprise users need privacy too. Enabling FPS could enable IT teams to protect their users in the general case (public web sites that have already adapted to working without third-party cookies) without breaking specific problem sites (intranet sites that depend on third-party cookies, and that browser developers can't test on).

I don't know if FPS is the best way to handle this problem, but it did come up in a meeting (link in previous comment) and it's on topic for this CG to address it somehow. It might turn out that a limited, user configured version of FPS (that could be modified by the administrator of organizationally managed browsers) would be sufficient.

I think FPS should stay in the PrivacyCG because the demarkation between first-party and third-party is mainly due to privacy concerns, and what end-users understand about those relationships. Since we've identified that as a potential problem, I think we should be the home of potential solutions or mitigations.

More particularly, though, if folks think there is a better CG/WG for this, then I think that group should be identified first - and consulted to find out if they'd agree. Otherwise, it seems to me like this is just a way to put proposals that people don't like and/or don't want to discuss into a no-man's land.

Sorry for chiming in late here but in my mind Privacy CG does provide the right avenue. It has the right diverse audience and includes proposals that are aimed at preserving existing experiences that otherwise will be broken because of privacy motivated browser changes like deprecation of 3P cookies, bounce tracking prevention etc. Proposals like storage access, isLoggedIn etc. are all part of Privacy CG and provide developers an ability to retain existing experiences in light of the privacy motivated changes. Without these conversation and proposals, we potentially risk websites and organizations asking their users to simply disable privacy protections in order to maintain existing experiences that are used and liked by users.

I agree with @kdeqc about proposal transfers in general. If another CG wants to claim a proposal, and we want to talk about whether or not to let them have it, that's a different conversation from whether or not we want to take the initiative in kicking out a proposal that doesn't have a new place to go.