Containers Come to Test Pilot

Containers Experiment UI

The Containers feature in Firefox Nightly gives users the ability to place barriers on the flow of data across sites by isolating cookies, indexedDB, localStorage, and caches within discrete browsing contexts. If you’re interested in the history and technology behind Containers, please read this blog post outlining the rationale for the Nightly implementation.

While the feature has garnered positive notice among our Nightly audience, there remain outstanding questions about the user experience that suggest the need for further exploration.

After running the Containers UI through successive rounds of user research and UX iteration, we are happy to announce that we’ve launched a Containers experiment in Firefox Test Pilot in order to widen the audience exposed to the feature, iterate on the UI, and reason about the future of the feature.

Containers UI on Test Pilot

The road to Test Pilot

Tanvi’s above-mentioned post introducing Containers explores the complexity of contextual identity on the web. She points out that people may wish to represent themselves differently in different browsing contexts: for example, while browsing social media versus doing research about a medical condition.

Today, browsers don’t do a great job of respecting contextual boundaries. We know from user research that Firefox users make do with a variety of ad hoc tools such as private browsing, multiple profiles, or multiple browsers to manage and protect their online contexts. The Containers experiment provides a tool that’s specifically designed to address context on the web.

The difficulty with Containers is that the UI and UX proposed by the feature are more-or-less unique among browsers. This presents some challenge for shipping to a general audience. Will users get it? Will the UI be sensible and will the security and privacy story behind the Containers feature match users’ mental models?

We’ve conducted user research on Nightly Containers using a think aloud protocol and our provisional answer to these questions have been a resounding kinda. We found, for example, that many users are more concerned with local threats (a snooping roommate or boss, for example) than your average security engineer. We also found that some research participants who totally missed the privacy features saw a lot of upside in containers as a strictly organizational tool. With these perspectives in mind, we decided that Test Pilot would be a great platform to expose Containers to a broader audience while continuing to learn more about user perceptions of the feature.

Firefox Test Pilot is a platform that lets us test potential new Firefox features while getting quantitative and qualitative feedback from participants. If you’re interested in the overall process and goals of Test Pilot, you can read more about it here. With the Containers experiment, we hope to answer the following:

  • Is the security model intelligible to Test Pilot users? How do they understand the feature?
  • Is the feature useful? If so, how much do people use it, and are there specific use cases that are particularly appealing?
  • Which container types do people use? Do people create custom containers?
  • Do containers keep people from opening a different browser to perform specific tasks?

How does the Test Pilot experiment differ from Containers in Nightly?

As with all experiments in Test Pilot, we’ve built an onboarding flow to give the uninitiated an introduction to the experiment. In addition to normal Test Pilot onboarding that’s standard across all experiments, we’ve added a few extra extra steps to the Containers experiment itself to introduce the unfamiliar UI.

Test Pilot onboarding for Containers

In response to user feedback about task management, Test Pilot Containers also introduces some organizational and visibility improvements over the Nightly version. Container management is moved to a toolbar button from which users can sort, hide, rename, create, and delete Containers. To aid in discoverability, users can now create new Container tabs by hovering over the new tab button.

Behind the scenes, the Containers experiment sends Telemetry data back to Test Pilot, so that we can learn more about users’ experiences with Containers. As with all Test Pilot experiments, users will be able to submit qualitative feedback in the form of ratings and survey responses about their experiences.

Most of the above covers the product rationale for Containers, but since this is Hacks, we should talk implementation as well. Like all Test Pilot experiments, Containers is shipped as an add-on signed and served from Test Pilot.

Containers require a special Firefox preference, so we started with an Embedded WebExtension to use the SDK preferences service and the WebExtension pageAction in tandem. During the development process, we learned that the contextualIdentities API that affords the underlying technology would not land in Firefox release in time for our experiment to ship.

To resolve this gap, we explored bundling the lower-level service as a WebExtension Experiment. However, WebExtension Experiments are only currently allowed in Nightly and Aurora. Since Test Pilot targets users across all channels, we needed a different solution. Thus, the experiment you see today in Test Pilot wound up as a mix of platform, SDK, and WebExtension code.

What is the security model provided by Containers?

The security enhancements of Containers in Nightly and Test Pilot is common across both versions, and are based on a modification to the browser’s Same Origin Policy (SOP).

The Same Origin Policy ensures that documents and data from distinct origins are isolated from each other. It is a critical browser security mechanism that prevents content from one site from being read or altered by another, potentially malicious site.

Containers work by adding an extra bit – a userContextId integer – to the normal (scheme, host, port) tuple that defines an origin. So, an origin is now defined as (userContextId, scheme, host, port). For example, when a user visits Gmail in a Work container tab, the browser performs the SOP check against (2, https,, 443). When the same user visits Gmail in a Personal container tab, the browser performs the SOP check against (1, https,, 443).

Containers separate cookies, localStorage, indexedDB, and cache data from each other and from the Default container in Firefox. So, when a user visits their email site in a Work container tab, the browser sets its cookies only in the Work container. If they then visit their email site in a Personal container, the origin that has their cookies doesn’t match and the user is therefore “signed out”.

Because cookies are not shared across containers, cookie-based attacks in one container are unsuccessful against cookies stored in another container. Similarly, cookie-based tracking only tracks a single container – it does not track the user’s entire browsing.

Many privacy and security mechanisms can be realized by including more keys in the origin check. Because of this, Gecko has added attributes to the origin called OriginAttributes. In addition to Containers, this allows us to implement features like Private Browsing Mode, First Party Isolation, and potentially the proposed Suborigins standard.

So what happens now?

Well, we wait and see. As users come into new Test Pilot experiments they inevitably uncover bugs and request features. Our immediate task will be to resolve bugs and prioritize new feature concepts.  We’ll continue to push releases to the Containers experiment while it’s in Test Pilot. In the meantime we’ll monitor both qualitative feedback from surveys and quantitative feedback from Telemetry to help us reason about the viability of the experiment and the prioritization of new features.

There is also ongoing work at the platform level, to further separate History, Bookmarks, and TLS Certificate Security Exceptions data between Containers. Each of these present their own UX, UI, and platform-level challenges.

In the long run, we will have to decide whether Containers makes it to release Firefox. Maybe the feature as we’ve built it for Test Pilot will prove to be a hit, or maybe we will need to go back to the drawing board. Maybe exposing the underlying APIs to WebExtensions kickstarts further add-on development around OriginAttributes. Shipping Containers in Test Pilot is the next step to help us make informed decisions about the future of Containers. If you’re interested in helping to shape that future please check out the experiment today!

About John Gruen

Current Test Pilot Product Manager. Former Test Pilot Designer.

More articles by John Gruen…

About Jonathan Kingston

Front End Security for Firefox, working on HTTPS adoption, containers and content security.

More articles by Jonathan Kingston…

About Luke Crouch

Privacy Engineer

More articles by Luke Crouch…

About Tanvi Vyas

Security/Privacy Engineer and Tech Lead at Mozilla - @TanviHacks

More articles by Tanvi Vyas…


  1. Sebastián

    Hey, nice Mozilla!

    you should take a look into the approach made by Sleipnir Browser in this matter. It’s really groundbreaking and they were the first to even come out with something like this.

    March 2nd, 2017 at 08:44

  2. JM

    Could opening a new tab use the same container context of the current tab ? i.e. if you’re in a work container context, new tab will create a new tab in the work container context ?

    What I’m thinking of is making it easy to create different windows for different container contexts; e.g. i can open up a finance window and finance related tasks in that window, and then a work window and do work things in that window in various tabs. This way I can avoid accidentally opening a finance site within a work session etc. whereas the current implementation makes it require me to pay more attention and navigating a menu which is quite a bit slower than creating a new tab.

    March 2nd, 2017 at 12:54

    1. Luke Crouch

      There’s an issue for this already:

      The UX is a bit tricky to get right here, so there are a couple related issues linked from there as well.

      March 6th, 2017 at 08:36

  3. ron22

    Bookmarks should have a container option, where you can specify in what container the bookmark opens. So if you have a bookmark for Twitter, and you want that to open in the Personal Container always, have a dropdown in the bookmark for Twitter with the following options:

    (1) Open in current container space,
    (2) Always open in Personal container,
    (3) etc…

    March 2nd, 2017 at 14:11

    1. Luke Crouch

      Thanks for the feedback – that’s a bug under the META tracking bug for Contextual Identity / Containers:

      We’d love to get your votes and/or comments there.

      March 6th, 2017 at 08:42

  4. Aaron Moodie

    The concept of containers is an interesting one, and I hope you guys keep pushing it forward.

    From a UI perspective, would it make more sense to group similar containers tabs together as a set? Something similar to how private browsing mode works now.

    Visually, this would make things clearer as you wouldn’t need to indicate the container type on every tab, but it might also help with the scenario where someone opens a link from a ‘work’ container in a new tab. Should this also be a ‘work’ container, or a default container, or do you need to choose a container every time you’re opening a link in a new tab?

    March 2nd, 2017 at 14:39

    1. Luke Crouch

      We are getting lots of feedback about expanding Containers into a more general-purpose Tab Management type feature. Check out this issue on GitHub:

      March 6th, 2017 at 08:43

  5. MT

    Containers work without TestPilot in Firefox Developer Edition, but some time ago the ability to open a container tab via a menu opened by holding down the plus button in tab bar stopped to work, so it’s impossible to manage containers anymore, only use those already existing via the context menu of links.

    How to reenable the container-management feature in Developer Edition? Thanks.

    March 3rd, 2017 at 06:51

    1. Luke Crouch

      Containers is controlled by an about:config preference. In Nightly and in the Test Pilot experiment, we set privacy.userContext.enabled to true.

      You should be able to set that in Firefox Developer Edition.

      March 6th, 2017 at 09:00

      1. MT

        Thanks, Luke. Unfortunately the `privacy.userContext.enabled` option seems not to do anything in Firefox Developer Edition: holding down the plus button in tab bar still doesn’t result in a context menu for choosing a container to open tab in.

        But I’ve discovered that it’s at least possible (regardless of the option value) to access the container-management settings page by opening the `about:preferences#containers` pseudo-URL directly though it is not exposed in Dev. Edition’s GUI unlike Nightly.

        March 6th, 2017 at 10:20

Comments are closed for this article.