First-Party Isolation (FPI) is an optional privacy feature built-in to Firefox that enforces stricter security policies to block tracking between websites. Essentially, every website you visit will store data separately and isolated from every other website you visit. So what could go wrong?

First-Party Isolation offers the same privacy protection within one browser as you would get if you open one website in Safari (or another web browser) and then open another website in Firefox. Network connections, caches of different types, cookies, and other persistent data stores would work as normal but there’s no known way for one website to save data in a way that could be read by any other website.

This is a more complete protection against cross-origin tracking between different websites by traditional means like the option for disabling third-party cookies and storage found in most web browsers. FPI was originally designed for use in the privacy-oriented Tor Browser, which is based on Firefox.

Mozilla has been quiet about this feature. It was first introduced in Firefox 55 after years of development work, but wasn’t mentioned in the official release notes or marketing. I’m not sure whether that’s because Mozilla considers it unsafe, unpractical, or don’t want to commit to maintaining the feature in future releases.

First-Party Isolation is a fundamental change in how the web browser operates and it breaks many assumptions made by web developers. If you want to enable the feature and gain better privacy than you also have to pay the price of breaking those assumptions.

Here is a list of the types of problems you can expect to run into with FPI enabled:

Third-party login failures Mozilla ran a study where they looked at how many issues people would run into if they enabled one of eight different privacy-enhancing settings in Firefox. The study found that people in the group with First-Party Isolation enabled reported the most number of issues out of any of the test groups. The same study found that people ran into trouble with Facebook and Google domains, and had trouble login in to websites. Both Facebook and Google provide authentication and login services for other websites that don’t always work as expected when you enable FPI. Depending on the implementation, you click on a login button on a website that opens a window with either Facebook or Google. This new window is opened in a new security context and is isolated from the originating website. Users can poke a hole in the isolation barrier by changing the privacy.firstparty.isolate.restrict_opener_access option to false , which allows for some communication between the login provider and the original website. However, changing this option only makes the login break later in the process. Users can sometimes work around these issues to some degree. E.g. a comment form from Disqus or Facebook is loaded inside a frame on the original page. By right-clicking on the frame and choosing This Frame: Open Frame In a New Tab , you’ll end up on a new frame with just the comment form with the origin as either a Disqus or Facebook domain. By loading the frame from the original origin, you’ll have access to the cookies for that origin and can login and comment as per normal. Some services, like the Mozilla-backed Scroll news subscription service, rely on third-party tracking cookies on partner websites. The service uses this as a mechanism to automatically log you in on partner websites. This type of service is incompatible with First-Party Isolation. To fully resolve this issue, the login service providers have to change their products to work with stricter origin controls. Unless Mozilla was to enable FPI by default, I doubt any company will invest any time or money in fixing these issues.

No migration path You lose all your cookies, caches, and data stores when you first enable First-Party Isolation in Firefox. Firefox doesn’t record the origin of data before enabling the setting, so existing user data has to go when switching to a stricter origin-policy. Firefox can’t record this data before isolating websites from each other as it otherwise wouldn’t know which changes were made by which website if multiple websites had access to read and write to the same data stores. Its kind of an unavoidable problem, as I see it. The initial loss of logins, website settings, and an avalanche of reappearing cookie consent toolbars could help explain for the higher number of issue reports in Mozilla’s study. Mozilla doesn’t mention this issue specifically in any publication.

More CAPTCHAs As I noted only recently, Google reCAPTCHA has a 99,3 % global marketshare in CAPTCHA services. No CAPTCHA reCAPTCHA uses Google’s knowledge and insights about you from tracking you around the web to determine whether you’re a computer or a human; instead of asking you to pass a cognitive test. Google seems to have reduced confidence in their ability to identify you as a human with reduced tracking and an unusual number of unique users (every website is assigned different tracking/user ID/user instead of sharing the same ID) from your IP address. In my own experience, I’ve had to spend more time and energy trying to manually solve the harder reCAPTCHA options rather than bypassing it all together with Google’s No CAPTCHA reCAPTCHA after enabling First-Party Isolation in Firefox.

Less shared caching means more data usage Caching is good. It means you don’t have to download the same font or JavaScript library multiple times if it’s already stored in your browser’s cache. Firefox will still cache content with First-Party Isolation enabled, however it will do so far less efficiently. Normally, your browser will download one copy of a specific font or JavaScript library once from a content-delivery network (CDN) which can be shared between multiple websites. FPI disrupts this causing the browser to download a new copy per website instead of relying on one shared copy. Firefox doesn’t set aside more disk storage space for its cache when enabling FPI. The browser thus has to store multiple copies of the same files in the same amount of disk space; which causes reduced efficiency for prioritizing what to keep in the cache and what to delete. You can somewhat reduce the impact of this for some types of common JavaScript libraries by installing the Decentraleyes extension. This extension acts as a local CDN provider that can bypass the First-Party Isolation by serving the content from the extension rather than a remote CDN. Depending on your location and internet connection, enabling First-Party Isolation in Firefox may significantly increase costs and slow down page loading times.

Can’t log-in to many extensions The extension API for OAuth2 logins, browser.identify.launchWebAuthFlow , fails to inform extensions about whether logins failed or succeeded. Extensions will wait for login attempts forever; believing the user just haven’t completed it yet. You can work-around the problem temporarily by disabling First-Party Isolation, restarting the browser, logging into the extension, and then re-enabling First-Party Isolation. Depending on the configuration of the service you login to,m you may nee to repeat the process every few months, weeks, days, or even hours. Update ( 2018-07-12 ): Added information about login issues with extension API. Other extensions assume that they can access cookies cross-domains in a way that’s prohibited by First-Party Isolation.

Can’t log-in to Pocket Pocket is Mozilla’s reading list and article recommendation service that you’ll find built-right into Firefox. Unfortunately, you can’t login to Pocket when First-Party isolation is enabled. You can work-around the problem by temporarily disabling First-Party Isolation, restarting the browser, logging in to Pocket, and then re-enabling First-Party Isolation. The process must be repeated every six months or so. Update ( 2018-07-11 ): Added information about Pocket login issues.