No spooky cookies

Cookies are best fresh, so what are the latest recipes to ensure you can still
enjoy spooky season without any stale cookies?

We are on the path towards phasing out third-party cookies across the web
platform. That’s a major milestone in tackling cross-site tracking, but it’s
part of a pretty long journey. Let’s take a peek at how far we’ve come and what
treats are in store in the future…

On the surface, cookies provide a simple key-value store that’s sent between the
browser and the server. That can provide useful functionality on a site such as
saving a preference: theme=bats or storing the session ID for a signed in
user.

If that cookie is being used on the same site that set it, then we tend to call
that a first-party cookie. If it’s being used as part of a different site than
the one that set it, we call that a third-party cookie. For example, my
theme=bats cookie would be first-party if I’m visiting that same site that set
it, but if it’s included in an iframe or other cross-site resource as part of a
different site then it would be a third-party cookie.

The problem with third-party cookies is that they can enable cross-site
tracking. Instead of setting something like a theme, the shared service might
store a whole identifier in there. That same identifier is then sent when you
navigate across different sites that include shared services cookie—which
means that one service can observe and link your activity across those sites.

# First-party cookies by default

We’ve already made progress on our journey here! It used to be that just setting
a plain cookie: theme=pumpkins would be sent in all contexts: same-site or
cross-site! The majority of sites do only want their cookies to be sent in a
same-site context. This can be controlled via the SameSite attribute on the
cookie. For example:

Set-Cookie: theme=bats; SameSite=Lax

This tells the browser to only send the cookie if the resource matches the
top-level site. However, that meant the site had to specify when it wanted the
first-party cookie. That’s a bit backwards in security terms as really you
should be asking when you want more privileges – not just getting them by
default.

So now, SameSite=Lax is the default. If you just set theme=bats it will only
be sent in a same-site context.

If you want a cross-site or third-party cookie (perhaps you need the theme
displayed in an embedded widget) then you need to specify:

Set-Cookie: theme=bats; SameSite=None; Secure

This tells the browser you want the cookie sent in any cross-site context, but
we do want to restrict to just secure connections.

# Even tastier first-party cookies

While the default did get a bit better, there’s still room for you to improve
that recipe. Here’s a quick taste:

Set-Cookie:  __Host-theme=bats;
  Secure;
  Path=/;
  HttpOnly;
  Max-Age=7776000;
  SameSite=Lax;

That will get you a first-party cookie that stays restricted to just one domain,
secure connections, no access by JavaScript, automatically expires before it
goes stale, and (of course!) is only allowed in same-site contexts.

# Cookies taste better with CHIPS!

One of the magical aspects of the web is the ability to compose multiple sites
together. Let’s say I want to create a map widget that lets other sites show the
best pumpkin patch tours or trick-or-treating routes. My service uses a cookie
to let the users store their progress along the route. The problem is, that same
third-party cookie is going to get sent on the pumpkin patch site as on the
trick-or-treating site. I don’t want to track users between sites, but the
browser just uses one cookie jar—there’s no way for me to separate that usage!

That’s where the Cookies Having Independent Partitioned State, or CHIPS,
proposal comes in. Instead of one shared cookie jar, there’s a separate and
partitioned cookie jar per top-level site. Sites would opt-in to that by using
the Partitioned attribute on their cookie.

Set-Cookie: __Host-route=123;
  SameSite=None;
  Secure;
  Path=/;
  Partitioned;

Instead of having to share that cookie jar, everyone gets their own! Simpler,
safer, and more hygienic.

We’ve just sent the Intent to
Ship
for Cookies Having Independent Partitioned State
(CHIPS) in Chrome 109 which means they will be
available to test in Beta in December and then ready for Stable in January 2023.
So, if you’re looking for a new year’s resolution to improve your site’s cookie
recipe then take a look and see if you can start sprinkling CHIPS into those
cross-site cookies!

# Inviting cookies to the party with First-Party Sets

On the subject of developer feedback, lots of you also made it clear that there
are situations where you share services across sites you control and want to be
able to use cookies across them – but not let them be sent in true third-party
contexts. For example, perhaps you have pretty-pumpkins.com and
pretty-pumpkins.co.uk. You might have a cookie-based single-sign on system
that works across these sites. CHIPS wouldn’t work because I’d just have to
sign-in on both sites—the requirement is that I need the same cookie across
these related sites.

We’re working on the First-Party Sets proposal to try and make this possible.
We’ve been through one origin trial and plenty of community discussion which has
brought us to the latest version that aims to:

• Give organizations a way to define a group of sites that should be
  same-party to each other.
• Leverage the Storage Access API to request access to cross-site cookies
  inside that first-party set.

These cookies are all still baking away in the oven, but you can check in on the
First-Party Sets developer guide when
there’s more for you to test, or you can jump into the
WICG/first-party-sets proposal if
you would like to contribute to the discussion.

# Don’t let your cookies go stale!

Our goal is to start phasing out support for third-party cookies in Chrome from
midway through 2024. There’s time to prepare, but you should start planning now.

1. Audit your code for any cookies with SameSite=None. These are the cookies
   that will require updates.
2. If you don’t have any third-party cookies, make sure your same-site cookies
   are using the best First-party cookies
   recipes
3. If you use those cookies in a fully contained, embedded context then
   investigate and test the CHIPS proposal.
4. If you need those cookies across multiple sites that form one cohesive group,
   then investigate the First-Party Sets
   proposal.
5. If you’re not covered by either of these options, you will need to
   investigate the other Privacy Sandbox proposals where
   we’re developing purpose-built APIs for individual use cases that don’t rely
   on cross-site tracking.

This is just a short overview and we will continue sharing more news and
guidance as the work progresses. If you have questions, issues or would like to
share the results of your own work then we have plenty of routes for you to get
in touch.

So, remember: cookies can be delicious—but only a few at a time and definitely
don’t try to steal anyone else’s!