Mixed active content is content that has access to all or parts of the Document Object Model of the HTTPS page. This type of mixed content can alter the behavior of the HTTPS page and potentially steal sensitive data from the user. Hence, in addition to the risks described for mixed display content above, mixed active content is vulnerable to a few other attack vectors.

Is security.mixed_content.block_active_content and security.mixed_content.block_display_content disabled in everyones browser as well? I don't want to enable it and risk making my traffic more identifiable.


Why isn't this enabled by default?

1 Answer 1


Yes for my browser, those two configuration is disabled. I am sure that the rest also have the same settings too unless they tweaked it.

Why isn't this enable by default?

I find Tor lead developer, Mike Perry's comment in this ticket provides the most complete explanation of why it is disabled from his point of view:

For Tor's use case, the current mixed content blocking in Firefox offers no significant benefit as-is. The "active vs passive content" blocking distinction does not reflect the realities of the capabilities of cookie theft adversaries, and the use of nsIContentPolicy makes the security properties subject to the irregular behaviors and incomplete coverage of that API.

If Tor Browser were to head in the partial content blocking direction, it would be to disable all Javascript from non-https schemes regardless of the sourcing scheme, and provide our own doorhanger UI to enable scripts for that first party url bar domain if the user desired. (NoScript is somewhat capable of doing this for us already, but the UX is abysmal and not in any way related to the first party url.)

Under this model, we would want to leave these HTTPS-Everywhere mixed content rules enabled, and we would simply entirely disable the native insecure partial mixed content blocking in Tor Browser. I imagine vanilla Firefox users who use both HTTPS-Everywhere and NoScript would be in favor of an option to keep these rules enabled for this "no javascript over http" usage pattern, as well.

In fact, since HTTPS-Everywhere already implements an http-on-modify-request observer, we could pretty much disable whatever Firefox does and re-implement it easier, cleaner, and more securely from our own observer. Then we could provide the user with multiple options: Full, strict mixed content blocking; https-only Javascript loading; and Firefox-style insecure partial blocking and rule neutering.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .