Full Title or Meme
The Trusted First Party is typically the human user of a User Agent such as a Browser. While it has been the practice up to 2021 to allow Cookies stored by one party in a session to be read by a Third Party, that has been explored but advertising and is scheduled to be shut down. The First-Party Set (FPS) is a proposal in W3C to retain some of the advantages of this practice while limiting user tracking.
- OpenID Connect was an enormously successful protocol because it allowed Front-Chanel communications of user sign-in information between a Identifier or Attribute Provider and a Relying Party.
- Some privacy focused browsers, like Safari, Fire Fox and Brave, have started blocking access by Third-Parties in 2021. Google is more dependent on advertising revenue and so continues to look for an alternate way that will not result in massive revenue losses like the $10 billon loss experienced by FaceBook.
Current OIDC Flow
(As best I understand it anyway) a previously set cookie with SameSite=None will be sent by the browser on such a top-level cross-site POST request. Some folks have suggested that that will change with 3rd party cookies going away and that even a SameSite=None cookie will no longer be sent in that situation. But in my mental model of this stuff, the situation will be unchanged by 3rd party cookies going away - it's a cross-site request but because it is a top-level navigation the cookies are 1st party. SameSite enforcement is in place so SameSite=None cookies will be sent. But it's not 3rd party so is not impacted by disappearance or partitioning of 3rd party cookies.
Anyway, that's what I'm hoping Sam can provide clarification on. Mostly for the benefit of my own understanding but also for the benefit of the group here as recent discussions have suggested that folks have divergent understanding and expectations of things.
That behaviour changing would be problematic, for example and as others have pointed out, because OIDC RPs receiving an ID token via the form post response mode need the 'nonce cookie' value (which ties the ID token to the browser the SSO flow was initiated on) at that point in validating the token. Maybe further confusing things is that at least in Chrome there was a temporary(?) exception made for the nonce cookie case with the rollout of the SameSite default change to Lax - the "Lax + POST mitigation" section at https://www.chromium.org/updates/same-site/faq and it looks like there's an attempt to capture that in the coming update to RFC 6265 https://github.com/httpwg/http-extensions/pull/1435/files
Part of this section was taken from Nick Doty <firstname.lastname@example.org> on Mon, Feb 28 with Don, Aram, Ralph, Robin, Scott
Still trying to understand the potential benefits to the user from First-Party Sets and potential relaxation of browser privacy protections among members of those sets.
To summarize some proposed benefits could be:
- combining data across origins to provide personalization (preferences for shopping sites, or remembering past purchases)
- providing transparency to the user or to researchers/regulators about which domains are operated by the same company
- letting a user sign-in on one origin and be logged-in on other origins operated by that login provider
I have been encouraged by the transparency possibility when it's been raised in the past (this was a feature during both P3P and DNT efforts). But on using data for personalization and single sign-on, I'm not clear on why a set with combined cookies is necessary, compared to explicit user opt-in, consolidating domains or proposals specific to authentication (OAuth redirect flows, federated identity, etc.).
There also doesn't seem to be agreement on whether a first-party set should include only domains operated by the same company. Either because one use case is combining data for external service providers, or because a company will want to split its operations (perhaps to commit tax fraud?) but still combine data.
And there doesn't seem to be agreement on whether the number of domains in a set should be strictly limited, or include hundreds or thousands of domains (with a much wider scope of potential abuse). Or whether the sets should be mutually exclusive.
I'd consider myself one of the skeptics at this point. But if you are interested in working on First-Party Sets, I think clarity on these points would make the discussion more productive:
- what is the direct user benefit (if any, and compared to alternatives)?
- what use cases are definitely in and out of scope?
- can enterprise use cases be satisfied while abuse of this feature is minimized?
I've tried to read the existing explainer and issues closely, and maybe it's just interest in expanding the scope beyond the current proposal that's leading to some of our general confusion. I see that https://github.com/privacycg/first-party-sets/issues/62 is one attempt to try to gain consensus on the purposes/use cases, and https://github.com/privacycg/first-party-sets/issues/53 on the user benefits, although many many of the open issues are touching on it.
Thanks all for the conversation and I hope it someday leads to more clarity for us. Cheers, Nick
On Fri, Jan 14, 2022 at 3:40 PM Don Marti <email@example.com> wrote: On Fri, Jan 14, 2022 at 11:28 AM Nick Doty <firstname.lastname@example.org> wrote: On Thu, Jan 13, 2022 at 2:31 PM Don Marti <email@example.com> wrote:
On Thu, Jan 13, 2022 at 9:53 AM Zucker-Scharff, Aram <Aram.Zucker-Scharff@washpost.com> wrote:
But I don’t really see how any of this lands us on FPS anyway. There is no better way to have a clear shared indicator of shared context then operating on the same domain as far as I can see, and I’m not really clear on how FPS would give us the ability to enforce any clearer way than ‘operates on the same domain’ or would otherwise meet the minimum clarity required to make the affiliation visible to all users. Arguably, even that isn’t enough to make clear to users what is going on with their data, as it still leaves them with the mysteries of how these companies operate internally, but it still is significantly clearer than any other options I have heard or could conceive. It at least makes it unmistakable who the operator they have to object to is.
I’m open to hearing some clear articulation of why every business needs to run on multiple TLDs and that t/f requires FPS… but I haven’t even heard that yet.
I appreciate the work that has gone into trust.txt but I’m just not sure why we would want to shave a square peg to fit a round hole when we could have a round peg made for purpose. I know that in theory this means More Standards which can be undesirable, but in this case--especially with the idea that we’re going to have to build some theoretical user-manned regulatory body that will be reviewing FPSs, a presumably extensive and never-ending queue--it seems like a new standard for how to proclaim FPSs that is a best-possible fit is worth the time and effort.
It is possible for FPS to be a net win for users.
I'm interested to understand how this would be a benefit for users, so thanks for giving this example to work through.
For example, let's say that dobbsford.example and dobbstoyota.example are two car dealership sites, and users of both are aware of the common brand identity of the two sites. The Bob Dobbs who tells them "Bob Dobbs won't make you pay a lot for a Ford!" and the Bob Dobbs who tells them "Bob Dobbs won't make you pay a lot for a Toyota!" are the same recognizable advertising personality.
What was the user benefit here? As the user, did I want both dealerships to know what cars I was looking at on the other site without logging in?
As the user, I'm shopping for a car, and I want to get a notification when a car matching my preferences is available for a test drive. (I already filtered the inventory list on the dobbsford.example site down to the Ford Focus, and want to see what's similar on the Toyota lot without slogging through a bunch of unrelated vehicles)
Could be any kind of activity that stays within the same service and context ("getting a great deal on a car from Bob Dobbs") but spans multiple domains.
(I don't know if the two sites in this example actually have the same "ownership". The two dealerships are LLCs with overlapping member lists, and have issued convertible debt instruments to different parties. Bob Dobbs is one step ahead of the IRS, and at least one step ahead of any IEE that tried to figure out the same info.)
If there's no FPS in the picture, you have just as much leverage as you have with your existing spam. If you do believe that your address was misused by an FPS member, you forward the spam to the IEE, and they run a test.
Maybe an IEE would not be necessary if all users had access to regulators with the time and resources to investigate all violations.
Users are already dealing with a single service or context that spans multiple "companies" on paper. (Look at web ToS documents that say, if you're in these countries you have a contract with example.com USA, if you're in these other countries you have a contract with example.com Ltd. in Ireland, in these other countries, etc... Real-world company structures are interesting and probably not feasible for an IEE to analyze.)
Don Marti <firstname.lastname@example.org> on Tue, Mar 1, 8:30 AM
Just to expand a little on that fourth point:
The issue is the user's mental resources -- how much cognitive energy and reputation processing they are being asked to invest in the set, and what they get for it. Making the "user-visible branding" the same across the entire set is how we keep that investment low, but the user still needs to get "paid for their time" somehow. The IEE's review of the FPS policy, and credible assertion that the member domains comply, is the service that is being offered to pay for the user's investment in the FPS.