A Look at Google's First Party Sets

This post first appeared on the Samsung Internet blog pages

Google wants to ban third-party cookies in the Chrome browser and replace them with a set of APIs and methods defined in their Privacy Sandbox. I won’t be going into detail on each of these methods in this post but I am going to explain First-party Sets and will probably add more explainers as the conversation pushes along.

First, though, why does Google want to get rid of third-party cookies?

Is There a Case for Removing Third-Party Cookies?

In short, yes. Third-party cookies have been the bane of the web for a long time now, they are used to build a profile on web users by tracking their online movements, often without user knowledge or consent, called ‘retargeting’ by the ad industry. It’s why you can search for a kettle on the web and all of a sudden see recommendations for the best kettles everywhere you go online. At best, these cookies are used for ads and at worst they can leak sensitive information and be used for surveillance.

It’s commonly agreed that third-party cookies need to be phased out or out-right banned. Some jurisdictions have already been putting laws in place to protect users and to give them the ability to consent to being tracked. Hence the rise of the cookie banner. Some browsers such as Samsung Internet also allow you to turn off third-party cookie tracking and include ad-blockers.

However, this puts the ad industry, and really anyone selling anything online, in a bind. How will they sell us the latest Thingy-ma-jig without force feeding it to us every time we run a search?!

Google’s Proposals

Google has proposed a list of tools which target specific issues third-party cookies were used for. Trust Token API are a way to prevent fraud and spam, the Topics API is a way to serve relevant ads to users, Gnatcatcher is a way to anonymise users all without tracking users, and there are a whole lot more.

First-party Sets has been one of the more controversial proposals. While everyone agrees that third-party cookies need to go, what replaces them is up for debate. Many have noted that Google leading the charge here is somewhat a conflict of interest, considering they’re one of the biggest ad platforms in the world. First-party sets in particular has set off alarm bells amongst privacy advocates.

First-party Sets

First-party Sets (FPS) is a proposal which aims to redefine how ownership works on the internet. Currently, ownership works on a domain level. I’m going to demonstrate this by using the company Example, Example owns both `example.com` and `example.co.uk`. The `example.com` domain owns all the APIs, databases, cookies, etc hosted at `example.com`, so `api-v1.example.com` is owned by `example.com` and so on. Which is to say, `example.co.uk` can’t access any of the properties on `example.com` without express consent/permission.

FPS says in order to make things easier for brands and mega-corps, we should remove the ownership link between domain and entity since it’s limiting, and allow sets which dictate a first-party relationship. So, Example would be able to include `example.com` and `example.co.uk` in a set defining it as a first-party relationship and thus more easily be able to share data and permissions between the two in certain situations.

first-party sets only control when embedded content that would otherwise be considered third-party can access its own state. […] This proposal is consistent with the same-origin policy. That is, Web Platform features must not use first-party sets to make one origin’s state directly accessible to another origin in the set. For example, if a.example and b.example are in the same first-party set, the same-origin policy would still prevent `https://a.example` from accessing `https://b.example`'s cookies or IndexedDB databases.

So, in the case of an iframe from `example.com` being embedded into `example.co.uk`, FPS would allow the `iframe.example.com` to access the `database.example.com` even though it’s embedded on `example.co.uk`.

This is just a brief explainer of the proposal, and I strongly advise reading the full thing.

Is This a Suitable Solution?

Not in its current form.

Building on and for the web requires adherence to Web Platform Design Principles, and FPS doesn’t meet priority of constituencies principle, which is:

User needs come before the needs of web page authors, which come before than the needs of user agent implementors, which come before than the needs of specification writers, which come before theoretical purity.

FPS prioritises the implementors and authors above users by putting the interest of brands above users. It also violates the vegas rule which is part of the (still draft) web privacy principles which says “what happens in a first-party stays in a first-party”. Read the full conversation on if FPS is good for users.

Mozilla have said they won’t be implementing FPS in Firefox or any of their browsers, Brave have disabled FPS in theirs, and Apple have said that they could adopt it but won’t be using it in the same way Google is proposing. This leaves things in a precarious position.

Conclusion

We need to rethink how we do online tracking, third-party cookies were a big mistake and have set a terrible precedent, however, whatever they’re replaced with needs to be safe and prioritise web-users. The W3C Technical Architecture Group is still in conversation with Google and continuously working to make the FPS proposal safer. https://github.com/w3ctag/design-reviews/issues/342

Thankfully, Google are engaging positively with the criticisms, so there is still hope of a proposal emerging which addresses these issues.

You can also chime in and ask questions on the FPS GitHub page or by joining the W3C Privacy Community Group where the proposal is being discussed. Creating a safer and secure web is a communal effort and will require input from a diverse range of users and creators.