The end of third-party cookies and its impact on Miro apps and integrations

In this blog post, we discuss the phasing out of third-party cookies, the impact (if any) these changes will have on Miro app developers, and possible solutions to address these issues.

Why are third-party cookies going away?

Privacy on the web is a major concern these days. Every day users share their data on websites that they trust but if that data were to fall into the wrong hands, it could be used to profile them, target them with unwanted ads, or even steal their identity. People should be able to browse the internet effectively while controlling their privacy via their own personal preferences.

Up until now, advertising companies have relied on third-party cookies to track user behavior across sites in order to serve them with relevant ads, and content providers have relied on them to embed their content on other websites. Unfortunately, malicious actors can exploit these third-party cookies to track user behavior on the web, and then use this information to violate their privacy. We need to do better to protect user privacy and keep users safe while they are online.

Due to data protection laws like GDPR in Europe and CCPA in the US, many websites now require users to explicitly consent to third-party, non-functional cookies that track their behavior while browsing their sites. This is not enough, however, since malicious trackers can still freely use third-party cookies to track users across the web.

Browser developers have realized the need to put better restrictions in place to protect users’ privacy. They are encouraging publishers and developers to find privacy-preserving alternatives to intrusive tracking for their key business needs, including serving relevant content and ads. As such, in an effort to improve privacy and security, browsers are moving towards a policy of blocking third-party cookies by default. This not only includes cookies, but also in some cases web storage APIs such as local storage and IndexedDB.

Firefox and Safari have already implemented this policy, and Chrome is following suit beginning early 2024, when they will start blocking third-party cookies for 1% of traffic. By the end of next year, third-party cookies will be phased out completely.

How does this affect Miro?

The imminent deprecation of third-party cookies in all major browsers is rooted in the need for better privacy control and security in order to prevent tracking and protect the personal data of users. There are, however, legitimate reasons to allow third-party cookies in some instances. One common use case is to enable web content from one site to be embedded inside another site on a different domain. Third-party cookies allow the embedded site to access its cookies from different top-level domains to provide the same personalized experience to the user, like allowing the user to be logged in and view embedded content from their account across different domains, or being able to continue a chat conversation with a customer support representative after being redirected to a new domain. When third-party cookies are blocked, the embedded site will no longer be able to access these cookies. This will have a serious impact on many content providers.

Miro also relies heavily on cookies to function properly. In a normal browser scenario when a user logs in and visits a Miro board at https://miro.com, first-party cookies are used to identify the user and enable some features to work correctly. Miro boards that are embedded on other domains rely on third-party cookies and any external content that is embedded inside of Miro boards may also be affected by this change. This includes Miro Developer Platform applications that are hosted outside of miro.com and which rely on cookies or web storage to function correctly.

For the use case where Miro is embedded on an external site via Live Embed, we at Miro are working on a solution for this in-house, so users shouldn’t need to worry. The end user may be prompted to grant access to cookies (depending on the browser), but no changes should be required on the external developer’s side for this and all Live Embeds will be updated automatically.

For the use case where third-party content is embedded inside Miro boards (such as with externally hosted Miro Developer apps), changes may be required by the app developer if cookies are used in the app.

How is it being addressed?

The Privacy Sandbox initiative led by Google aims to create web standards for companies to access user information without compromising privacy. It is mainly aimed at online advertisers and focuses on exposing characteristics or preferences of the user without actually divulging any of their personal information through APIs. Outside of advertising, Google also recognizes that there are other legitimate use cases for sharing data across different websites that are traditionally achieved using third-party cookies, and that these will also be severely impacted by this change. Therefore, a number of proposals have been put forward to address these use cases which will enable the sharing of data across domains.

Storage partitioning

When third-party cookies are blocked, other web storage mechanisms like local storage and IndexedDB are also blocked. To address this limitation, browsers are introducing the concept of partitioned storage in third-party contexts such that data stored by storage APIs in one iframe will only be accessible to contexts with the same origin and top-level site combination. This partitioning will not just apply to storage, but also to communications APIs like broadcast channel and service workers.

The impact of this change on Miro app developers is that any web storage accessed by the app from within the Miro board will be partitioned so it can’t be accessed by the third-party site running in other contexts (i.e. by the third-party site itself running in the browser or the third-party site embedded in another top-level domain).

Related website sets

Third-party cookies are often used to share resources or state across domains when one organization has many related sites across different domains. With related website sets (formerly known as first-party sets), a company can declare a list of domains to be considered as first-party to allow them to share information. A common use case for related website sets is when a company has websites under different brands or language-specific websites hosted under different country specific top-level domains as illustrated in the diagram below.

A potential application of related website sets for Miro might be to allow access to cookies set for miro.com from apps hosted on miro-apps.com or webwhiteboard.com (also owned by Miro). By implementing related website sets, it would allow us to share cookies between the three domains as if they were the same top-level domain. Related website sets are not a viable solution for solving the cookie access problem posed for Miro app developers since apps can be hosted on any domain, but we felt they are worth mentioning since developers with related websites may find them useful in other scenarios.

Storage Access API

The Storage Access API provides a way to gain access to unpartitioned cookies from a third-party context that would normally only be available in a first-party context. The API provides a way for content embedded inside iframes to check whether they have access to unpartitioned cookies and to request access if necessary. It does this on a frame-by-frame basis for each top-level site and embedded site combination.

The API checks if the embedded site has access to unpartitioned cookies using the hasStorageAccess() method provided by the browser and, if not, can request access using the requestStorageAccess() method. Depending on the browser, the user will be prompted to grant access to the requesting embedded site in different ways:

• Safari prompts for all embedded content that has not previously received storage access.
• Firefox tries to determine if it can grant access automatically and only prompts if needed.
• Chrome and Edge only currently resolve storage access requests that come from domains within the same related website set. Chrome recently announced support for a prompt similar to Firefox and Safari, however this is still in development.

An example of the access prompt a user would see in Safari is shown below:

Access is granted or denied and the promise-based nature of requestStorageAccess() allows the user to handle both success and failure cases. As mentioned earlier, unpartitioned storage access must be requested per frame. However, once access is granted, a key is stored for the request based on the <top-level site, embedded site> combination so subsequent requests for storage access from other frames on the same top-level site would resolve automatically without the user having to provide consent again for at least 30 days.

There are a number of security measures that also must be adhered to in order for the requestStorageAccess() call to succeed:

1. The invocation of the call must be associated with a user gesture such as a tap or click, unless storage access has already been granted for another associated frame on the top-level site.
2. The document and top-level domain must not have a null origin.
3. For some browsers, the user must have interacted with the embedded content in a first-party context recently (within the last 30 days for Safari).
4. The document’s window is in a secure context.
5. Sandboxed iframes need to have a special allow-storage-access-by-user-activation token along with allow-scripts and allow-same-origin.
6. Storage access can be blocked by a storage-access permissions policy set on the server.
7. Chrome and Edge both currently only resolve access requests that come from domains within the same related website set.

Although the feature is widely supported on most major browsers, Chrome and Edge are still only considered to have partial support due to the restriction that domains requesting access must belong to a related website set. The security restrictions outlined above, especially the need for a user gesture to initiate the call and for the user to explicitly give consent via a prompt in both Firefox and Safari, are intrusive and will have a negative impact on user experience.

It means developers can’t programmatically request storage access to gain access to their unpartitioned cookies without some sort of user interaction and explicit opt-in from within the frame. In saying that, if Miro app developers need to support users on Firefox and/or Safari, then we believe the Storage Access API is the best option available at this time.

CHIPS

CHIPS is an acronym for Cookies Having Independent Partitioned State. In the traditional sense, cookies are unpartitioned, meaning that if a cookie is set for miro.com then it is accessible anywhere miro.com is loaded, whether that is as a top-level domain in a browser or a third-party domain in an iframe of another site. With the blocking of third-party cookies, unpartitioned cookies will not be accessible in a third-party context.

CHIPS proposes to address this by giving each embedded usage of a website access to its own cookie jar as a partitioned state that is double-keyed on the top-level domain and the domain of the embedded site. This is similar to how partitioned storage works. The main difference is that for CHIPS, the developer must explicitly opt-in to having the cookies partitioned, whereas with partitioned storage, all web storage is partitioned by default. The explicit opt-in is required to prevent unexpected bugs in cases where a server is expecting an unpartitioned cookie.

To partition cookies, the developer must specify the new “Partitioned” attribute on the cookie when it is created. A sample of how this is done using the Set-Cookie header is shown below.

Set-Cookie: __Host-name=value; Secure; Path=/; SameSite=None; Partitioned;

When a cookie is created with this partitioned flag set, the browser will then proceed to store it in its own cookie jar such that it can only be accessed from the context (top-level domain, embedded site pair) in which it is created.

In this example, the instance of site a.com embedded in top-level site b.com will have its own cookie jar to store its cookies in and the instance of site a.com embedded in top-level site c.com will have a separate cookie jar to store its cookies in. However, neither instance can read from the other’s cookie jar. Similarly, when a.com is the top-level site it also will not be able to access either of the partitioned cookie jars for b.com+a.com or c.com+a.com, as they are completely isolated from each other.

Note that CHIPS is currently only supported by Chrome, Edge and Opera, so if you need to support other browsers then implementing CHIPS alone will not be enough.

One problem with the CHIPS approach is that because each partitioned cookie state has its own cookie jar, cookies still can’t be shared across embeds on different websites. For Miro app developers, this means that any data accessed in cookies by the app code while used in Miro will only be available to the miro.com+app-host-domain.com cookie jar. This means the app code running in other domains or in the top-level app-host-domain.com will not be able to access those same cookies.

What do we recommend?

Unfortunately, there is no one-size-fits-all solution available right now since browsers have different levels of support for each of the options outlined above. The solution really depends on which browser(s) you want (or need) to support.

We believe the ideal solution would be to use the Storage Access API if it were fully supported in all browsers, as it allows the embedded site to access the unpartitioned cookie storage as if it were running in a first-party context. This means cookies are not segregated by top-level domain and can be shared across multiple embeds used in different contexts, including the top-level browser context. Unfortunately, the Storage Access API comes with some UX friction as the user must perform a transient activation (user gesture) to invoke the request for storage access that can in turn prompt the user for access, requiring them to explicitly opt-in by clicking “allow.” The existing Storage Access API implementation in Chrome and Edge is also restricted to only work with related website sets, but there is a prompt version in development for Chrome.

CHIPS is a good solution for Chrome and Edge, but it does mean the cookies are segregated by each top-level domain and embedded domain pair, so they can’t be shared across sites. This means if your embedded domain has an authentication component, then the user will need to log in separately for each top-level domain, embedded domain combination. Or if your embedded site needs to share cookie data across multiple top-level domains where it is embedded, this will not be possible.

At this time, we recommend a combination of both approaches to tailor for the varying levels of support in different browsers. This is the approach we have also chosen to take for Live Embed. The Storage Access API can be implemented to allow unpartitioned cookie access in Firefox and Safari and CHIPS can be used to support partitioned cookies in Chrome, Edge, and Opera. We will be keeping a close eye on developments in this area, in particular with Chrome’s implementation of the Storage Access API and update our recommendations as browsers evolve.