 First party sets allow related domain names owned and operated by the same entity to declare themselves as belonging to the same first party. First party sets is part of the privacy sandbox, which is a series of proposals to satisfy cross-site use cases without third party cookies or other tracking mechanisms. So why do we need first party sets? Web pages include content from multiple origins, not just their own service. For example, a website might use embedded video and many sites include code from different origins, such as analytics or javascript libraries. Historically, a third party might also want to correlate the activity of a user across sites by using mechanisms such as third party cookies. Of course, browsers are moving towards privacy models that restrict access to tracking user identity across sites. However, many organisations, of course, have related sites with different domain names, such as, you know, for example, examplecdn.com and examplemarketing.com, or domainsfordifferentcountries.com.com.au and .co.uk and so on. It should be possible to allow related domain names that have an appropriate relationship, perhaps common ownership, and shared user journeys between domains to declare themselves as belonging to the same first party. And this can make life easier for users by enabling state to be maintained and accessed across domains in order to retain site functionalities, such as single sign-on and consent management. What we need is a way for browsers to treat domains, like the ones I just mentioned, as first party in situations where first party and third party are otherwise treated differently. Of course, any solution also needs to prevent abuse of the system. For example, it must not be possible to declare organisations that include unrelated sites with different owners, just in order to gain first party privileges. So, how do first party sets actually work? Well, a website can declare that it is a member or owner of a set of web domains by serving a manifest file that defines its relationship to the other domains. Now, browsers know to look for configuration files in the well-known directory at the top level of a site, and that's where a first party sets manifest JSON file can go. For example, imagine that example.com, example.com.au and example.co.uk all want to be part of the same first party set owned by example.com. Each of the sites would then serve the following files in their well-known directory. Example.com declares itself as the owner by serving a JSON file at the URL slash well-known slash first party set. Example.com.au declares itself as being owned by example.com, and so does example.co.uk. An important part of the first party set's proposal is to ensure that policy across browsers prevents abuse or misuse. For example, first party sets must not be able to exchange user information across unrelated sites or group sites that are not actually owned by the same entity. One possible way for a site to register a first party set could be for the site to submit their proposed group of domains to a public tracker such as a dedicated GitHub repository along with information needed to satisfy browser policy. The acceptance process for a new first party set is under discussion with the W3C, but verification is likely to be handled by an independent entity, not a browser company. Now, once the first party set assertion has been verified as per policy, browsers may then fetch lists of sets via an update process. The complementary proposal to first party sets is the same party cookie attribute. Specifying the same party attribute on a cookie instructs the browser to include the cookie so that the context is part of the same first party set as the top level context. For example, for the first party set described above, example.com can set the following cookie. And this means that when a visitor on example.com.au or example.co.uk makes a request to example.com, the session cookie is included on that request. So that's first party sets. To find out more, take a look at this article on developer.chrome.com. And if you have comments or feedback on the API, you can create an issue on the API explainer on GitHub. And you can track implementations of all the Privacy Sandbox APIs on this status page. So thanks for watching, and be sure to catch the other videos in the Privacy Sandbox series. .