Containers is now available as a Firefox Extension, accessible to all Firefox users. Download Firefox Multi-Account Containers here.

Back in June 2016, we started experimenting with “Containers” as a way to explore Contextual Identities on the web. Firefox Containers are a way for users to isolate their online identities and tasks from one another. In addition to the privacy benefits of containers, containers allow users to be logged into multiple accounts at once without requiring them to use multiple browsers or constantly sign in and out.

After our initial Nightly implementation, we went through various rounds of user research, design iterations, experiments, and finally a Test Pilot launch to help determine what our users wanted and how containers could meet those needs. We received positive feedback, numerous feature requests, and bug reports. As the Test Pilot phase comes to an end, we have converted containers into a Firefox Extension called Firefox Multi-Account Containers, accessible to all Firefox users! The extension comes with the latest UI and containers experience, including a number of features that weren’t available last year.

What’s new?

Underline: After numerous complaints and bugs with the previous overline tab experience, container tabs are now underlined with the appropriate container color.

Menu: There is a new Container Menu button that is accessible in the toolbar with many container options. You can open a tab in a given container by clicking on the name of the container you want to open. You can create, delete, and edit containers. You can change the color or icon associated with a container or change the container name.

Assignment: You can now assign a website to a container, so that a specific website will always open in a specific container. This helps protect from accidents, stopping you from accidentally visiting a shopping site in your banking container, for example.

Hide and Show: Assume you use your browser for both Work and Personal tasks. When you come home at the end of the day, you don’t want to be thinking about “Work” anymore, but your browser is full of Work tabs. You can “Hide” your Work tabs and proceed with your Personal tasks. Then the next day, when you are back at work, you can “Hide” your Personal tabs and “Show” your Work tabs.

Note that these hidden tabs are actually currently closed. They aren’t open in the background, eating up CPU power and bandwidth. However, that also means that if you are halfway through filling out a form, your form data will be lost when you re-show the tab. We hope to fix this in the future so that your form data isn’t lost.

Sort: The Container Menu has a “Sort Tabs” option and a “Move tabs to a new window” option. Sort Tabs will put all your tabs of the same container type next to each other in a given browser window. So if you have “Work” and “Personal” tabs interleaved within each other, you can easily sort them to help organize your tasks (as seen below). “Move tabs to a new window” will take all the container tabs in your current window and move them to a fresh window.

I wish Containers could do more!

During the last year, we received tons of feature requests for containers. We found that many feature requests conflicted with each other. For example, if you are in a Work Container, and open a new tab, should the new tab be in the Default Container or the Work Container? Or, if you click a link in a Banking Container, should the link open in the Default Container or the Banking Container? We realized that different users want to use containers in different ways with numerous different use cases. Instead of creating a complicated, feature rich, and potentially confusing product, we created Web Extension APIs. With these APIs, developers can create new Container addons that work for exactly the use case they have in mind. You can learn more about these here.

There are a number of different container related extensions that have already emerged, including Containers On The Go, Conex, Context-plus, and Cookie AutoDelete.

Quick Tips for Container Tab Management

We have received a lot of requests from users seeking easier ways to open tabs or links within a specific container. Many of these already exist, but are unfortunately a bit hard to discover. Here are some quick tips that might help an avid containers user:

I am in Container X and want an easy way to open another tab in Container X.

With the plus button (or ctrl+T), you will get a tab in the Default Container. To get a new tab in Container X, hold down the control key and press the Plus Button with your mouse at the same time. This will open another Container X tab right next to your previous Container X tab. (Note that Mac users will need to use the command key instead of control.)

Alternatively, if you have a mouse with a middle click button on it, middle clicking the plus button will give you a new tab in Container X.

You can also hold down the control key and press the Refresh button with your mouse at the same time. This will open another tab in Container X with the same website loaded. So you will have two side by side Container tabs visiting the same site.

I want to open a container without using my mouse.

Clicking the control button and the period button (ctrl+.) will open up the Container Menu. You can tab through the different container names until you get the one you want to open. Once you have it selected, press Enter and you will get the container you desire.

I am in Container X and want to open a link in Container Y.

Right click the link to expose the Context Menu. Select “Open Link in New Container Tab” and choose which container you would like to use.

I want the plus button to show me a list of options instead of just opening a Default Container.

Go to the plus button with your mouse, click the button and hold down your mouse key for a second or two. “Long pressing” on the plus button exposes a list of containers you could select for your new tab.

I want example-bank.com to always open in the Banking Container and nowhere else.

Use the assignment feature described above. Open a Banking Container tab. Go to example-bank.com. Click the Container Menu and select “Always open in Banking”. The next time you go to example-bank.com in a container other than Banking, the browser will ask you if you would like to use the Banking Container instead. This helps protect you from making mistakes and visiting the wrong website in the wrong context.

I created a container for my online Christmas shopping, but Christmas is over and I don’t need the container anymore.

You can easily delete a container by clicking the Container Menu, selecting Edit Containers, and then clicking the trash can image next to the container you would like to delete. This will close any tabs that are open in that container, and also delete any saved cookies, cache, localstorage, and indexeddb from that container. Note that it will not delete websites you visited in that container from your history. History is currently global and shared across containers.

The Containers Feature in Firefox Nightly enables users to login to multiple accounts on the same site simultaneously and gives users the ability to segregate site data for improved privacy and security.

We all portray different characteristics of ourselves in different situations. The way I speak with my son is much different than the way I communicate with my coworkers. The things I tell my friends are different than what I tell my parents. I’m much more guarded when withdrawing money from the bank than I am when shopping at the grocery store. I have the ability to use multiple identities in multiple contexts. But when I use the web, I can’t do that very well. There is no easy way to segregate my identities such that my browsing behavior while shopping for toddler clothes doesn’t cross over to my browsing behavior while working. The Containers feature I’m about to describe attempts to solve this problem: empowering Firefox to help segregate my online identities in the same way I can segregate my real life identities.

With Containers, users can open tabs in multiple different contexts – Personal, Work, Banking, and Shopping.  Each context has a fully segregated cookie jar, meaning that the cookies, indexeddb, localStorage, and cache that sites have access to in the Work Container are completely different than they are in the Personal Container. That means that the user can login to their work twitter account on twitter.com in their Work Container and also login to their personal twitter on twitter.com in their Personal Container. The user can use both accounts in side-by-side tabs simultaneously. The user won’t need to use multiple browsers, an account switcher[1], or constantly log in and out to switch between accounts on the same domain.

Note that the inability to efficiently use “Contextual Identities” on the web has been discussed for many years[2]. The hard part about this problem is figuring out the right User Experience and answering questions like:

• How will users know what context they are operating in?
• What if the user makes a mistake and uses the wrong context; can the user recover?
• Can the browser assist by automatically assigning websites to Containers so that users don’t have to manage their identities by themselves?
• What heuristics would the browser use for such assignments?

We don’t have the answers to all of these questions yet, but hope to start uncovering some of them with user research and feedback. The Containers implementation in Nightly Firefox is a basic implementation that allows the user to manage identities with a minimal user interface.

We hope to gather feedback on this basic experience to see how we can iterate on the design to make it more convenient, elegant, and usable for our users. Try it out and share your feedback by filling out this quick form or writing to containers@mozilla.com.

FAQ

How do I use Containers?

You can start using Containers in Nightly Firefox 50 by opening a New Container Tab. Go the File Menu and select the “New Container Tab” option. (Note that on Windows you need to hit the alt key to access the File Menu.) Choose between Personal, Work, Shopping, and Banking.

Notice that the tab is decorated to help you remember which context you are browsing in. The right side of the url bar specifies the name of the Container you are in along with an icon. The very top of the tab has a slight border that uses the same color as the icon and Container name. The border lets you know what container a tab is open in, even when it is not the active tab.

You can open multiple tabs in a specific container at the same time. You can also open multiple tabs in different containers at the same time:

Your regular browsing context (your “default container”) will not have any tab decoration and will be in a normal tab. See the next section to learn more about the “default container”

Containers are also accessible via the hamburger menu. Customize your hamburger menu by adding in the File Cabinet icon. From there you can select a container tab to open. We are working on adding more access points for container tabs; particularly on long-press of the plus button.

How does this change affect normal tabs and the site data already stored in my browser?

The containers feature doesn’t change the normal browsing experience you get when using New Tab or New Window. The normal tab will continue to access the site data the browser has already stored in the past. The normal tab’s user interface will not change. When browsing in the normal context, any site data read or written will be put in what we call the “default container”.

If you use the containers feature, the different container tabs will not have access to site data in the default container. And when using a normal tab, the tab won’t have access to site data that was stored for a different container tab. You can use normal tabs along side other containers:

What browser data is segregated by containers?

In principle, any data that a site has read or write access to should be segregated.

Assume a user logins into example.com in their Personal Container, and then loads example.com in their Work Container. Since these loads are in different containers, there should be no way for the example.com server to tie these two loads together. Hence, each container has its own separate cookies, indexedDB, localStorage, and cache.

Assume the user then opens a Shopping Container and opens the History menu option to look for a recently visited site. example.com will still appear in the user’s history, even though they did not visit example.com in the Shopping Container. This is because the site doesn’t have access to the user’s locally stored History. We only segregate data that a site has access to, not data that the user has access to. The Containers feature was designed for a single user who has the need to portray themselves to the web in different ways depending on the context in which they are operating.

By separating the data that a site has access to, rather than the data that a user has access to, Containers is able to offer a better experience than some of the alternatives users may be currently using to manage their identities.

Is this feature going to be in Firefox Release?

This is an experimental feature in Nightly only. We would like to collect feedback and iterate on the design before the containers concept goes beyond Nightly. Moreover, we would like to get this in the hands of Nightly users so they can help validate the OriginAttribute architecture we have implemented for this feature and other features. We have also planned a Test Pilot study for the Fall.

To be clear, this means that when Nightly 50 moves to Aurora/DevEdition 50, containers will not be enabled.

How do users manage different identities on the web today?

What do users do if they have two twitter accounts and want to login to them at the same time? Currently, users may login to one twitter account using their main browser, and another using a secondary browser. This is not ideal, since then the user is running two browsers in order to accomplish their tasks.

Alternatively, users may open a Private Browsing Window to login to the second twitter account. The problem with this is that all data associated with Private Browsing Windows is deleted when they are closed. The next time the user wants to use their secondary twitter account, they have to login again. Moreover, if the account requires two factor authentication, the user will always be asked for the second factor token, since the browser shouldn’t remember that they had logged in before when using Private Browsing.

Users may also use a second browser if they are worried about tracking. They may use a secondary browser for Shopping, so that the trackers that are set while Shopping can’t be associated with the tasks on their primary browser.

Can I disable containers on Nightly?

Yes, by following these steps:

1. Open a new window or tab in Firefox.
2. Type about:config and press enter.
3. You will get to a page that asks you to promise to be careful. Promise you will be.
4. Set the privacy.userContext.enabled preference to false.

Can I enable containers on a version of Firefox that is not Nightly?

Although the privacy.userContext.enabled preference described above may be present in other versions of Firefox, the feature may be incomplete, outdated, or buggy. We currently only recommend enabling the feature in Nightly, where you’ll have access to the newest and most complete version.

How is Firefox able to Compartmentalize Containers?

An origin is defined as a combination of a scheme, host, and port. Browsers make numerous security decisions based on the origin of a resource using the same-origin-policy. Various features require additional keys to be added to the origin combination. Examples include the Tor Browser’s work on First Party Isolation, Private Browsing Mode, the SubOrigin Proposal, and Containers.

Hence, Gecko has added additional attributes to the origin called OriginAttributes. When trying to determine if two origins are same-origin, Gecko will not only check if they have matching schemes, hosts, and ports, but now also check if all their OriginAttributes match.

Containers adds an OriginAttribute called userContextId. Each container has a unique userContextId. Stored site data (i.e. cookies) is now stored with a scheme, host, port, and userContextId. If a user has https://example.com cookies with the userContextId for the Shopping Container, those cookies will not be accessible by https://example.com in the Banking Container.

Note that one of the motivations in enabling this feature in Nightly is to help ensure that we iron out any bugs that may exist in our OriginAttribute implementation before features that depend on it are rolled out to users.

How does Containers improve user privacy and security?

The Containers feature offers users some control over the techniques websites can use to track them. Tracking cookies set while shopping in the Shopping Container won’t be accessible to sites in the Personal Container. So although a tracker can easily track a user within their Shopping Container, they would have to use device fingerprinting techniques to link that tracking information with tracking information from the user’s Personal Container.

Containers also offers the user a way to compartmentalize sensitive information. For example, users could be careful to only use their Banking Container to log into banking sites, protecting themselves from potential XSS and CSRF attacks on these sites. Assume a user visits attacker.com in an non-banking-container. The malicious site may try to use a vulnerability in a banking site to obtain the user’s financial data, but wouldn’t be able to since the user’s bank’s authentication cookies are shielded off in a separate container that the malicious site can’t touch.

Is there any chance that a tracker will be able to track me across containers?

There are some caveats to data separation with Containers.

The first is that all requests by your browser still have the same IP address, user agent, OS, etc. Hence, fingerprinting is still a concern. Containers are meant to help you separate your identities and reduce naive tracking by things like cookies. But more sophisticated trackers can still use your fingerprint to identify your device. The Containers feature is not meant to replace the Tor Browser, which tries to minimize your fingerprint as much as possible, sometimes at the expense of site functionality. With Containers, we attempt to improve privacy while still minimizing breakage.

There are also some bugs still open related to OriginAttribute separation. Namely, the following areas are not fully separated in Containers yet. Update: All of these bugs have been fixed.

• [Fixed October 2016] Some favicon requests use the default container cookies even when you are in a different container – Bug 1277803
• [Fixed July 2016] The about:newtab page makes network requests to recently visited sites using the default container’s cookies even when you are in a different container – Bug 1279568
• [Fixed August 2016] Awesome Bar search requests use the default container cookies even when you are in a different container – Bug 1244340
• [Fixed July 2016] The Forget About Site button doesn’t forget about site data from Container tabs – Bug 1238183
• [Fixed August 2016] The image cache is shared across all containers – Bug 1270680

We are working on fixing these last remaining bugs and hope to do so during this Nightly 50 cycle.

How can I provide feedback?

I encourage you to try out the feature and provide your feedback via:

• 2 minute survey
• Email containers@mozilla.com
• File a bug

Thank you

Thanks to everyone who has worked to make this feature a reality! Special call outs to the containers team:

Andrea Marchesini
Kamil Jozwiak
David Huseby
Bram Pitoyo
Yoshi Huang
Tim Huang
Jonathan Hao
Jonathan Kingston
Steven Englehardt
Ethan Tseng
Paul Theriault

Footnotes

[1] Some websites provide account switchers in their products. For websites that don’t support switching, users may install addons to help them switch between accounts.
[2] http://www.ieee-security.org/TC/W2SP/2013/papers/s1p2.pdf, https://blog.mozilla.org/ladamski/2010/07/contextual-identity/
[3] Containers Slide Deck

Update: This feature is now also enabled in Firefox Release, starting with Firefox 51.  See this post for more details.

Firefox Developer Edition 46 warns developers when login credentials are requested over HTTP.

Username and password pairs control access to users’ personal data. Websites should handle this information with care and only request passwords over secure (authenticated and encrypted) connections, like HTTPS. Unfortunately, we too frequently see non-secure connections, like HTTP, used to handle user passwords. To inform developers about this privacy and security vulnerability, Firefox Developer Edition warns developers of the issue by changing the security iconography of non-secure pages to a lock with a red strikethrough.

How does Firefox determine if a password field is secure or not?

Firefox determines if a password field is secure by examining the page it is embedded in. The embedding page is checked against the algorithm in the W3C’s Secure Contexts Specification to see if it is secure or non-secure. Anything on a non-secure page can be manipulated by a Man-In-The-Middle (MITM) attacker. The MITM can use a number of mechanisms to extract the password entered onto the non-secure page. Here are some examples:

• Change the form action so the password submits to an attacker controlled server instead of the intended destination. Then seamlessly redirect to the intended destination, while sending along the stolen password.
• Use javascript to grab the contents of the password field before submission and send it to the attacker’s server.
• Use javascript to log the user’s keystrokes and send them to the attacker’s server.

Note that all of the attacks mentioned above can occur without the user realizing that their account has been compromised.

Firefox has been alerting developers of this issue via the Developer Tools Web Console since Firefox 26.

Why isn’t submitting over HTTPS enough? Why does the page have to be HTTPS?

We get this question a lot, so I thought I would call it out specifically. Although transmitting over HTTPS instead of HTTP does prevent a network eavesdropper from seeing a user’s password, it does not prevent an active MITM attacker from extracting the password from the non-secure HTTP page. As described above, active attackers can MITM an HTTP connection between the server and the user’s computer to change the contents of the webpage. The attacker can take the HTML content that the site attempted to deliver to the user and add javascript to the HTML page that will steal the user’s username and password. The attacker then sends the updated HTML to the user. When the user enters their username and password, it will get sent to both the attacker and the site.

What if the credentials for my site really aren’t that sensitive?

Sometimes sites require username and passwords, but don’t actually store data that is very sensitive. For example, a news site may save which news articles a user wants to go back and read, but not save any other data about a user. Most users don’t consider this highly sensitive information. Web developers of the news site may be less motivated to secure their site and their user credentials. Unfortunately, password reuse is a big problem. Users use the same password across multiple sites (news sites, social networks, email providers, banks). Hence, even if access to the username and password to your site doesn’t seem like a huge risk to you, it is a great risk to users who have used the same username and password to login to their bank accounts. Attackers are getting smarter; they steal username/password pairs from one site, and then try reusing them on more lucrative sites.

How can I remove this warning from my site?

Put your login forms on HTTPS pages.

Of course, the most straightforward way to do this is to move your whole website to HTTPS. If you aren’t able to do this today, create a separate HTTPS page that is just used for logins. Whenever a user wants to login to your site, they will visit the HTTPS login page. If your login form submits to an HTTPS endpoint, parts of your domain may already be set up to use HTTPS.

In order to host content over HTTPS, you need a TLS Certificate from a Certificate Authority. Let’s Encrypt is a Certificate Authority that can issue you free certificates. You can reference these pages for some guidance on configuring your servers.

What can I do if I don’t control the webpage?

We know that users of Firefox Developer Edition don’t only use Developer Edition to work on their own websites. They also use it to browse the net. Developers who see this warning on a page they don’t control can still take a couple of actions. You can try to add “https://” to the beginning of the url in the address bar and see if you are able to login over a secure connection to help protect your data. You can also try and reach out to the website administrator and alert them of the privacy and security vulnerability on their site.

Do you have examples of real life attacks that occurred because of stolen passwords?

There are ample examples of password reuse leading to large scale compromise. There are fewer well-known examples of passwords being stolen by performing MITM attacks on login forms, but the basic techniques of javascript injection have been used at scale by Internet Service Providers and governments.

Why does my browser sometimes show this warning when I don’t see a password field on the page?

Sometimes password fields are in a hidden <div> on a page, that does not show up without user interaction. We have a bug open to detect when a password field is visible on the page.

Will this feature become available to Firefox Beta and Release Users?

Right now, the focus for this feature is on developers, since they’re the ones that ultimately need to fix the sites that are exposing users’ passwords. In general, though, since we are working on deprecating non-secure HTTP in the long run, you should expect to see more and more explicit indications of when things are not secure. For example, in all current versions of Firefox, the Developer Tools Network Monitor shows the lock with a red strikethrough for all non-secure HTTP connections.

How do I enable this warning in other versions of Firefox?

Users of Firefox version 44+ (on any branch) can enable or disable this feature by following these steps:

1. Open a new window or tab in Firefox.
2. Type about:config and press enter.
3. You will get to a page that asks you to promise to be careful. Promise you will be.
4. The value of the security.insecure_password.ui.enabled preference determines whether or not Firefox warns you about non-secure login pages. You can enable the feature and be warned about non-secure login pages by setting this value to true. You can disable the feature by setting the value to false.

Thank you!

A special thanks to Paolo Amadini and Aislinn Grigas for their implementation and user experience work on this feature!

Cross posting this. It was written a couple months ago and posted to Mozilla’s Security Blog
This article was coauthored by Aislinn Grigas, Senior Interaction Designer, Firefox Desktop

November 3, 2015

Over the past few months, Mozilla has been improving the user experience of our privacy and security features in Firefox. One specific initiative has focused on the feedback shown in our address bar around a site’s security. The major changes are highlighted below along with the rationale behind each change.

Change to DV Certificate treatment in the address bar

Color and iconography is commonly used today to communicate to users when a site is secure. The most widely used patterns are coloring a lock icon and parts of the address bar green. This treatment has a straightforward rationale given green = good in most cultures. Firefox has historically used two different color treatments for the lock icon – a gray lock for Domain-validated (DV) certificates and a green lock for Extended Validation (EV) certificates. The average user is likely not going to understand this color distinction between EV and DV certificates. The overarching message we want users to take from both certificate states is that their connection to the site is secure. We’re therefore updating the color of the lock when a DV certificate is used to match that of an EV certificate.

Although the same green icon will be used, the UI for a site using EV certificates will continue to differ from a site using a DV certificate. Specifically, EV certificates are used when Certificate Authorities (CA) verify the owner of a domain. Hence, we will continue to include the organization name verified by the CA in the address bar.

Changes to Mixed Content Blocker UI on HTTPS sites

A second change we’re introducing addresses what happens when a page served over a secure connection contains Mixed Content. Firefox’s Mixed Content Blocker proactively blocks Mixed Active Content by default. Users historically saw a shield icon when Mixed Active Content was blocked and were given the option to disable the protection.

Since the Mixed Content state is closely tied to site security, the information should be communicated in one place instead of having two separate icons. Moreover, we have seen that the number of times users override mixed content protection is slim, and hence the need for dedicated mixed content iconography is diminishing. Firefox is also using the shield icon for another feature in Private Browsing Mode and we want to avoid making the iconography ambiguous.

The updated design that ships with Firefox 42 combines the lock icon with a warning sign which represents Mixed Content. When Firefox blocks Mixed Active Content, we retain the green lock since the HTTP content is blocked and hence the site remains secure.

For users who want to learn more about a site’s security state, we have added an informational panel to further explain differences in page security. This panel appears anytime a user clicks on the lock icon in the address bar.

Previously users could click on the shield icon in the rare case they needed to override mixed content protection. With this new UI, users can still do this by clicking the arrow icon to expose more information about the site security, along with a disable protection button.

Loading Mixed Passive Content on HTTPS sites

There is a second category of Mixed Content called Mixed Passive Content. Firefox does not block Mixed Passive Content by default. However, when it is loaded on an HTTPS page, we let the user know with iconography and text. In previous versions of Firefox, we used a gray warning sign to reflect this case.

We have updated this iconography in Firefox 42 to a gray lock with a yellow warning sign. We degrade the lock from green to gray to emphasize that the site is no longer completely secure. In addition, we use a vibrant color for the warning icon to amplify that there is something wrong with the security state of the page.

We also use this iconography when the certificate or TLS connection used by the website relies on deprecated cryptographic algorithms.

The above changes will be rolled out in Firefox 42. Overall, the design improvements make it simpler for our users to understand whether or not their interactions with a site are secure.

Firefox Mobile

We have made similar changes to the site security indicators in Firefox for Android, which you can learn more about here.

For the last few months, I’ve been working on the Mixed Content Blocker for Firefox.  I’ve been landing patches since Firefox 18 in hope of reaching this day. Mixed Active Content is now blocked by default in Firefox 23!

What is Mixed Content?

When a user visits a page served over HTTP, their connection is open for eavesdropping and man-in-the-middle (MITM) attacks. When a user visits a page served over HTTPS, their connection with the web server is authenticated and encrypted with SSL and hence safeguarded from eavesdroppers and MITM attacks.

However, if an HTTPS page includes HTTP content, the HTTP portion can be read or modified by attackers, even though the main page is served over HTTPS.  When an HTTPS page has HTTP content, we call that content “mixed”. The webpage that the user is visiting is only partially encrypted, since some of the content is retrieved unencrypted over HTTP.  The Mixed Content Blocker blocks certain HTTP requests on HTTPS pages.

What do I mean by “certain HTTP requests”?  Why wouldn’t the Mixed Content Blocker just block all HTTP requests?  To answer this question, I will first explain how the browser security community divides mixed content into two categories; Mixed Active Content and Mixed Passive Content.

Mixed Content Classifications

Mixed Passive Content (a.k.a. Mixed Display Content).

Mixed Passive Content is HTTP Content on an HTTPS website that cannot alter the Document Object Model (DOM) of the webpage.  More simply stated, the HTTP content has a limited effect on the HTTPS website.  For example, an attacker could replace an image served over HTTP with an inappropriate image or a misleading message to the user. However, the attacker would not have the ability to affect the rest of the webpage, only the section of the page where the image is loaded.

An attacker could infer information about the user’s browsing activities by watching which images are served to the user.  Since certain images may only appear on a specific webpage, a request for an image could tell the attacker what webpage the user is visiting. Moreover, the attacker can observe the HTTP headers sent with the image, including the user agent string and any cookies associated with the domain the image is served from.  If the image is served from the same domain as the main webpage, then the protection HTTPS provides to the user’s account becomes useless, since an attacker can read the user’s cookies from image request headers[1].

Examples of Passive Content are images, audio, and video loads.  Requests made by objects have also fallen into this category for now; the reasons for this are discussed further in the Appendix.

Mixed Active Content (a.k.a. Mixed Script Content)

Mixed Active Content is content that has access to and can affect all or parts of the Document Object Model (DOM) of an HTTPS page. This type of mixed content can alter the behavior of an HTTPS page and potentially steal sensitive data from the user. Hence, in addition to the risks already described for Mixed Passive Content above, Mixed Active Content is also exposesd to a number of additional attack vectors.

A MITM attacker can intercept requests for HTTP active content. The attacker can then re-write the response to include malicious JavaScript code. Malicious script can steal the user’s credentials, acquire sensitive data about the user, or attempt to install malware on the user’s system (by leveraging vulnerable plugins the user has installed, for example).

Examples of Active Content are JavaScript, CSS, objects, xhr requests, iframes, and fonts.

What will the Mixed Content Blocker block?

The Mixed Content Blocker will block Mixed Active Content requests in Firefox 23.  This reduces the threat to the user, but does not eliminate it completely because Mixed Passive Content is still permitted.  Users can decide to block Mixed Passive Content as well by following a couple simple steps[2].

Why are we reducing the threat instead of eliminating the threat?  Unfortunately, the web is not ready for Firefox to block Mixed Passive Content.  Mixed Passive Content is still common on the web.  For example, many HTTPS webpages include HTTP images.  Too many pages would break if we blocked Mixed Passive Content (ex: https://youtube.com).  Hence, Firefox would alert users too often and contribute to security warning fatigue.

Moreover, blocking Mixed Passive Content could cause considerable user experience issues for users with low bandwidth connections.  To avoid generating a browser security warning, websites will begin removing Mixed Passive Content from their HTTPS sites by replacing HTTP images and videos with their HTTPS equivalent versions.  When low bandwidth users visit the HTTPS site, all image loads and video streams would be encrypted and there would be considerable lag in the page’s load time and the time it takes for videos to buffer.  With Mixed Active Content, bandwidth considerations are not as big of an issue since Mixed Active Content loads (ex: scripts, stylesheets) are usually a few KB, compared to Mixed Passive Content loads which often contain multiple MBs of data.

The risk involved with Mixed Content (active or passive) also depends on the type of website the user is visiting and how sensitive the data exposed to that site may be. The webpage may have public data visible to the world, or it may have private data that is only visible when authenticated. If an HTTP webpage is public and doesn’t have any sensitive data, the use of Mixed Content on that site still provides the attacker with the opportunity to redirect requests to other HTTP URLs and steal HTTP cookies from those sites.

I don’t have Firefox 23 yet.  Can I enable the Mixed Content Blocker?

Work on the Mixed Content Blocker first landed in Firefox 18 and has been incrementally improving since.

The Mixed Content Blocker UI does not exist in Firefox 18, 19, and 20.  You can turn the feature on BUT if you encounter a page that breaks because a mixed content resource is blocked, the only way to fix the page and load the insecure content is to turn the feature off.  This makes the feature difficult to use in FF 18, 19 and 20.

Firefox 21 and 22 (currently Firefox Beta and Aurora, respectively) shipped with the Mixed Content Blocking UI.  You can turn on the feature and try it out[3]!  (Note that there is a case that is incorrectly blocked in Firefox 21 that was fixed in Firefox 22 with Bug 841850).

Mixed Content Blocker UI

Designing UI for security is always tricky.  How do you inform the user about a potential security threat without annoying them and interrupting their task?

Larissa Co (@lyco1) from Mozilla’s User Experience team aimed to solve this problem.  She created a Security UX Framework with a set of core principles that drove the UX design for the Mixed Content Blocker.  If you’re interested in learning more about this process, I encourage you to check out the Mixed Content Design Specification and Larissa’s presentation on Designing Meaningful and Usable Security Experiences.

So what does the UI look like?  If a user visits an HTTPS page with Mixed Active Content, they will see the following in the location bar:

Clicking on the shield, they will see options to Learn More, Keep Blocking, or Disable Protection on This Page:

If a user decides to “Keep Blocking”, the notification in the location bar will disappear:

On the other hand, if a user decides to “Disable Protection on This Page”, all mixed content will load on the HTTPS page and the Lock icon will be replaced with a Yellow Warning Triangle:

If a user visits an HTTPS page with Mixed Passive Content, Firefox will not block the passive content by default (see What will the Mixed Content Blocker block?).  But, since Mixed Passive Content does exist on the page, it is not fully encrypted and the user will not see the lock icon in the location bar:

Mixed Content Frames

Note that frames are classified as Mixed Active Content.  This has been a source of debate and browser vendors haven’t quite settled on whether mixed content frames should be considered active or passive.  Firefox and Internet Explorer consider frames Mixed Active Content, while Chrome considers frames Mixed Passive Content.

When trying to determine whether a load is passive or active, I ask myself “can the content affect the DOM of the page?”.  With frames, this gets a little tricky.  Technically, an HTTP frame cannot affect the DOM of its HTTPS page and hence could fall into the Mixed Passive Content category.

When we dig further, however, we find reasons to push frames into the Mixed Active Content category.  A frame has the ability to navigate the top level page and redirect a user to a malicious site.  Frames can also trick users into disclosing sensitive information to attackers.  For example, assume a user is on an HTTPS page that embeds an HTTP frame.  An attacker can MITM the frame and replace its content with a form.  The form may ask the user to login or create an account. Most users are oblivious to the concept of framing pages and have no idea that it is the HTTP frame that contains the form and not the HTTPS website. Assuming they are on the HTTPS encrypted page, the user enters their personal information.  This information is then sent to the attacker without the user’s knowledge.

Remaining Edge Case

Many edge cases were found while developing the Mixed Content Blocker.  Some of these edge cases have been resolved, some are pending development, and some are open questions that require further discussion.

We did not want to wait until all possible issues were resolved before turning Mixed Active Content blocking on by default for our users.  But at the same time, if we turned the feature on with too many false positives, we would be unnecessarily alerting users and contributing to security warning fatigue.  (False positives are cases where the Mixed Content Blocker mistakenly blocks content that should have been permitted.)  Hence, I worked to eliminate all false positive issues that I was aware of before turning on the Mixed Content Blocker.

On the other hand, there are still a number of false negatives that remain open. This means that there are certain cases where the Mixed Content Blocker does not block content that should have been blocked.  We still decided to turn the feature on because we believe we should protect our users as soon as possible, even if our solution is not 100% perfect yet.  The false negatives are valid issues and affect the safety of our users.  Engineering solutions for these edge cases is important (and is next on my list), but should not prevent us from protecting users from mixed content we can identify and can block for users today.

For developers trying to secure their websites by removing mixed content, these false negative edge cases could prove problematic and cause extra work.  The last thing a developer wants to do is attempt to remove mixed content on their site for Firefox 23, and then have to do this again in Firefox 24 because of an edge case that was fixed and that the developer wasn’t aware of the first time around.  In an attempt to help with this problem, I have an added an Appendix to this blog post that will describe all the open edge cases and open questions with reference links where developers can learn more about the progress in resolving these known issues.

Thank You

Thanks to all the Mozillians that have helped me with this feature.  Special shouts out to…

Olli Pettay (smaug)

Brandon Sterne (@bsterne)

Larissa Co (@lyco1)

Ian Melven (@imelven)

Sid Stamm

Brian Smith

Justin Dolske (@dolske)

Gavin Sharp (@gavinsharp)

Matthew Noorenberghe

 

Couldn’t have done it without you 🙂

Footnotes

[1] Unless the authentication cookies are flagged with the secure bit, preventing the browser from sending the authentication cookies for non-HTTPS requests.

[2] To block Mixed Passive Content, open a window or tab in Firefox and enter about:config.  You will get to a page that asks you to promise to be careful.  Promise you will be, and then change the value of security.mixed_content.block_display_content to true by double clicking it.

[3]  In Firefox 23+, Mixed Active Content is blocked by default.  If you are using a Firefox version between 18 and 22, you can block Mixed Active Content by opening a window or tab in Firefox and enter about:config.  You will get to a page that asks you to promise to be careful.  Promise you will be, and then change the value of security.mixed_content.block_active_content to true by double clicking it.

Appendix – Edge Cases Described in Detail

Note that this section is highly technical and has a lot of gory details, so feel free to skip over it unless you are interested, want a sneak peak at forthcoming Mixed Content Blocker changes that may affect your site, and/or are a browser security junkie like me 🙂

1. Redirects
   If an HTTPS content load responds with a 302 to an HTTP destination, the Mixed Content Blocker in Firefox will not detect or block the mixed content.  This is because of the way that Gecko’s Content Policies work (or don’t work) with redirects.  The work to fix this edge case can be found in Bug 418354 and Bug 456957.
2. Session Restore & document.write
   Assume an HTTPS page loads an HTTP script that invokes a document.write that replaces the current page’s content.  If the browser is shut down and later the session is restored, the user will see the content from the document.write that replaced the original webpage.  This would be okay, except that instead of showing the yellow warning triangle, Firefox 23 shows a lock.  This is inaccurate, because the page’s new content was created by an HTTP script and hence cannot be considered fully encrypted.  The work to fix this issue can be found in Bug 815345.
3. Object Subrequests
   Assume that an HTTPS page loads an HTTPS object in a plugin.  That object may then request further resources through the plugin.  The requests made by the plugin are considered the object’s subrequests.  Since the requests are made by a plugin and not by the browser, it is very difficult for the browser to determine whether the HTTP subrequests should be considered Mixed Active or Mixed Passive.  Without help from plugin vendors, browsers cannot accurately determine this classification.  To prevent false positives and security warning fatigue, Firefox (and Chrome) have classified HTTP object subrequests as Mixed Passive Content.  This means that we do have false negatives, where the content is actually active and should be blocked, but isn’t.

   The solution to these false negatives is still under discussion.  Take a look at Bug 836352 and chime in if you have some suggestions!

4. Relying on HSTS to prevent Mixed Content
   Websites can specify an HSTS header that tells browsers to only connect to them over a secure connection.  Assume https://example.com sets this header (and for simplicity sake, assume example.com is not on the HSTS preload list).  A developer, relying on HSTS, includes HTTP content from example.com on https://foo.com.

   Firefox will convert the http://example.com link to an https://example.com link before making the network request.  Hence, technically, the user’s security is never affected.

   Currently, the Mixed Content Blocker will detect the http://example.com link before it is converted to HTTPS by HSTS and classify the content as mixed content.  I believe this is fine.  Relying on HSTS to protect websites from mixed content loads is bad practice, for the following reasons.

   • If this is the first time the user has loaded content from example.com, the content will be loaded over HTTP since the browser has not yet received and HSTS header from example.com
   • For browsers that do not have HSTS implemented (ex: Internet Explorer), https://foo.com will have mixed content, since the request for content from http://example.com is never converted to an HTTPS request.

   Perhaps you disagree?  Express your thoughts in Bug 838395

5. Mixed Content in Framed Pages
   Assume https://unimportant-site.com includes an iframe to https://bank.com.  https://bank.com contains Mixed Active Content that Firefox blocks.  The user has a choice to “Disable Protection on This Page” and load the Mixed Active  Content on https://bank.com.  As we mentioned earlier, most users don’t know what frames are.  The user see’s that they are on https://unimportant-site.com and can decide to load the mixed content on https://unimportant-site.com by clicking “Disable Protection on This Page”.  To the user, “This Page” is https://unimportant-site.com, but in actuality, the result is that protection is disabled on https://bank.com.

   Bug 826599 discusses whether users should even have an option to disable protection on HTTPS frames.  The bug is to remove the UI to Disable Protection if the mixed content is coming from an HTTPS frame with a different domain than the top level domain.  What do you think about this?

In addition to the items listed above, there are also many other issues remaining to improve the Mixed Content Blocker.  You can see here for a list of items and corresponding bug numbers.

This summer I worked on a Google Summer of Code Project called User Specified Content Security Policy with Kailas Patil (CS PhD student at the National University of Singapore). We created a Firefox add-on called UserCSP that allows users and developers to apply custom Content Security Policies to websites.

A Content Security Policy is a declarative policy that restricts what content can load on a page.  Its primary purpose is to mitigate Cross-Site Scripting vulnerabilities.  The core issue exploited by Cross-Site Scripting (XSS) attacks is the lack of knowledge in web browsers to distinguish between content that’s intended to be part of web application, and content that’s been maliciously injected into web application.

To address this problem, CSP defines the Content-Security-Policy HTTP header that allows web application developers to create a whitelist of sources of trusted content, and instruct the client browsers to only execute or render resources from those sources.  However, it is often difficult for developers to write a comprehensive Content Security Policy for their website.  They may worry about breaking their page by blocking unanticipated but necessary content.  They may not be able to easily change the CSP header for their site, which makes it challenging for them to experiment with policies until they find one that best protects their page without breaking site functionality.

UserCSP changes this!  A developer can now view the current policy applied to their site and create their own custom policy.  They can choose to apply their custom policy on the site, or even combine their policy with the website’s existing policy.  When combining policies, they have an option to choose from the strictest subset of the two, or the most lax subset.  They can locally test their site with the custom policy applied and tweak the policy until they have one that works.

The coolest feature of UserCSP is the Infer-CSP tab.  This feature can help a developer derive a usable and secure policy for their site.  By looking at the content the website loads, the add-on determines the strictest set of CSP rules it can apply to the site without breaking the current page.  The inferred policy is provided in the proper syntax for the CSP Header, so all a developer needs to do is start serving this policy for their site via the CSP header.

 

Security conscious users can also benefit from UserCSP.  They can protect themselves by disabling content such as objects on personal finance sites or frames and third party javascript for their web-email.  Here is an example, where you can see that a flash object used for an ad is blocked after the user applies a custom policy:

 

 

We are looking to improve UserCSP, and are open to comments, suggestions, and reviews.  I feel like we have only scratched the surface with this tool.  We hope that after trying out the add-on, the security community will come up with ideas to further enhance it.  The code is open source and can be found on Github.  Check out the add-on and let us know what you think!

UserCSP Add-on: https://addons.mozilla.org/en-US/firefox/addon/newusercspdesign/
UserCSP Code (Open Source): https://github.com/patilkr/userCSP
UserCSP Documentation: https://wiki.mozilla.org/SummerOfCode/2012/UserCSP/Wiki