-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move FPS to different CG/WG #88
Comments
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 Choice 1: Push out a browser configuration to turn third-party cookies back on. Choice 2: Put an FPS in place for just the 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. |
(this is following up on my comment made in the TAG design review previously)
w3ctag/design-reviews#342 (comment)
I want to suggest that the FPS proposal be moved to a different venue than PrivacyCG. The proposal (and the conversation around it) seems pretty far afield from most of whats discussed in FPS (how to reduce information flows, limit tracking, etc.).
I believe I understand the reasoning for FPS to be in PrivacyCG to be the following:
Setting side whether the above framing is shared by most browsers (my impression is that it is not), I do not think the above means PrivacyCG is the right place for this conversation.
Either:
a) FPS a generic way of sites describing their relationships with each other that doesn’t imply any particular privacy policy choices in a browser (and so isn’t a good fit for PrivacyCG, its a generic platform feature thats at least a couple hops away from standardizing privacy features in the browser), or
b) FPS is a system for sites to indicate that there should be weakened privacy boundaries between themselves (and so definitely doesn’t belong in PrivacyCG). This seems particularly privacy harming given that most browser vendors in this discussion have said explicitly they do not support using FPS for this purpose
Anyway, TL;DR; whether or not folks support FPS, i think PrivacyCG is not the best place for that discussion. I expect PrivacyCG would benefit by being able to focus on projects that are more immediately (and cross-browser) privacy improvement. And it seems possible that the FPS proponents would benefit from not butting heads with FPS opponents so frequently in this venue
The text was updated successfully, but these errors were encountered: