Skip to main content

RIP Third-Party Cookies: A Developer's Perspective

· 4 min read
Daniel Worthington

As of January 4th 2024, Chrome started blocking 3rd party cookies for 1% of Chrome users. That is just the beginning of a slow rollout to 100% of users later this year. You may already be browsing the web without 3rd party cookies.

Blocking 3rd party cookies will have lots of effects on advertising and tracking, but it’s also going to impact a non-tracking use case: embedding apps inside iframes. Our dev tool MightyMeld loads React apps inside iframes so you can use our UI to visually edit React apps. That has been working well for us, except that for some apps, we’ve found that you can’t sign in. Usually, that happens because Chrome is blocking the app’s auth cookies, and with the additional blocking starting this month, that’s only going to get worse.

What are 3rd party cookies?

“3rd party cookies” are written and read by a site other than the one that appears in your browser’s address bar. For the embedded use case, that means any cookies that the site inside the iframe tried to read or write. For example in MightyMeld the address shown in the browser is https://studio.mightymeld.app, but the website trying to authenticate (and set a cookie) is http://localhost:3000.

What was the status of 3rd party cookies before 2024?

In 2020 browsers began making restrictions to 3rd party cookies. They changed the default SameSite setting for cookies to Lax and introduced a new setting, SameSite=None that allows 3rd party cookies to work. What this means is that in order for the page inside the iframe to behave as it would outside the iframe (for auth to work, etc.), cookies have to meet the following:

  • SameSite set to None
  • Secure set
  • Must be served over HTTPS or localhost

That’s the magic incantation you need for a cookie not to be blocked inside an iframe today. Unless, of course, the user is in the 1% that Chrome started blocking this month.

What to do about blocked cookies

The first thing to figure out is why the blocking is happening. For most users, the reason will be the 2020-era restrictions. You’ll want to make sure that the 99% of Chrome users who are browsing under those rules have working cookies first.

To address the new rules that Chrome has begun this month, you’ll need to use one of the following approaches.

Add an Exception to Chrome Settings

At MightyMeld, we’re planning to ask users who are in the blocked cohort to add an exception for MightyMeld. Chrome has a list called “Sites allowed to use third-party cookies” which is available for all Chrome users, even the 1% in the blocked cohort. That might work well for us because we’re a tool made for developers and because making an exception for us means any site loaded inside our iframes will work. For most developers whose apps are meant to be embedded on many different websites, this probably isn’t a viable option.

Partitioned Storage

Cookies Having an Independent Partitioned State (CHIPS), is a new feature of Chrome 114 that opts cookies into “partitioned storage.” Partitioned storage means that your cookies continue to work inside an iframe, but they are isolated from iframes that are loaded by a different parent site. For example, if yourapp.com is loaded inside site-a.com it will be stored in a different cookie “jar” (database) than when it is loaded inside site-a.com. You can store cookies across page loads, but not across different parent websites. That isn’t great for authentication, but it might be useful for other data storage use cases.

Storage Access API

This is a JavaScript API you can call when your site is loaded at the top level (not in an iframe) to request permission to read cookies when the site is embedded. This is a good option for embedded apps where the user is expected to interact with the content inside the iframe. Like other permissions requests, the API will fail unless triggered by a user clicking or tapping.

Chrome is also offering a way for apps that span multiple domains to establish a link between them, called Related Website Sets. This only is applicable if you own both the domains, and involves making a submission to Chrome and getting approval.

Gone, But Not Forgotten (yet)

Third-party cookies will be dearly missed by developers and advertisers alike, but coping strategies (at least for developers) are already in place.