Neither Firefox's Mixed Content Blocker nor HTTPS Everywhere will be ready for the other when Firefox 23 ships. On the Mozilla side, we need a fix for MCB firing too early in the request pipeline, and on the HTTPS Everywhere side we need to correctly label and disable those rulesets that cause problematic MCB situations.
For power users this isn't a problem, because they can live with broken CSS or manually allow mixed content. But for most of our users this is catastrophic.
So we will ship a patch which temporarily disables the MCB about:config setting if your Mozilla version is 23, but which pops a NotificationBox offering more information and letting you turn it back on if you'd like to.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
...
Show closed items
Linked items
0
Link issues together to show that they're related.
Learn more.
For power users this isn't a problem, because they can live with broken CSS or manually allow mixed content. But for most of our users this is catastrophic.
So we will ship a patch which temporarily disables the MCB about:config setting if your Mozilla version is 23, but which pops a NotificationBox offering more information and letting you turn it back on if you'd like to.
to
Neither Firefox's Mixed Content Blocker nor HTTPS Everywhere will be ready for the other when Firefox 23 ships. On the Mozilla side, we need a fix for MCB firing too early in the request pipeline, and on the HTTPS Everywhere side we need to correctly lable and disable those rulesets.
For power users this isn't a problem, because they can live with broken CSS or manually allow mixed content. But for most of our users this is catastrophic.
So we will ship a patch which temporarily disables the MCB about:config setting if your Mozilla version is 23, but which pops a NotificationBox offering more information and letting you turn it back on if you'd like to.
Trac: Description: Neither Firefox's Mixed Content Blocker nor HTTPS Everywhere will be ready for the other when Firefox 23 ships. On the Mozilla side, we need a fix for MCB firing too early in the request pipeline, and on the HTTPS Everywhere side we need to correctly lable and disable those rulesets.
For power users this isn't a problem, because they can live with broken CSS or manually allow mixed content. But for most of our users this is catastrophic.
So we will ship a patch which temporarily disables the MCB about:config setting if your Mozilla version is 23, but which pops a NotificationBox offering more information and letting you turn it back on if you'd like to.
to
Neither Firefox's Mixed Content Blocker nor HTTPS Everywhere will be ready for the other when Firefox 23 ships. On the Mozilla side, we need a fix for MCB firing too early in the request pipeline, and on the HTTPS Everywhere side we need to correctly label and disable those rulesets.
For power users this isn't a problem, because they can live with broken CSS or manually allow mixed content. But for most of our users this is catastrophic.
So we will ship a patch which temporarily disables the MCB about:config setting if your Mozilla version is 23, but which pops a NotificationBox offering more information and letting you turn it back on if you'd like to.
Trac: Description: Neither Firefox's Mixed Content Blocker nor HTTPS Everywhere will be ready for the other when Firefox 23 ships. On the Mozilla side, we need a fix for MCB firing too early in the request pipeline, and on the HTTPS Everywhere side we need to correctly label and disable those rulesets.
For power users this isn't a problem, because they can live with broken CSS or manually allow mixed content. But for most of our users this is catastrophic.
So we will ship a patch which temporarily disables the MCB about:config setting if your Mozilla version is 23, but which pops a NotificationBox offering more information and letting you turn it back on if you'd like to.
to
Neither Firefox's Mixed Content Blocker nor HTTPS Everywhere will be ready for the other when Firefox 23 ships. On the Mozilla side, we need a fix for MCB firing too early in the request pipeline, and on the HTTPS Everywhere side we need to correctly label and disable those rulesets that cause problematic MCB situations.
For power users this isn't a problem, because they can live with broken CSS or manually allow mixed content. But for most of our users this is catastrophic.
So we will ship a patch which temporarily disables the MCB about:config setting if your Mozilla version is 23, but which pops a NotificationBox offering more information and letting you turn it back on if you'd like to.
After reading some of the stuff Tanvi from Mozilla has been saying, I'm starting to think that temporarily disabling the mixed content blocker is a bad idea, even as a quick fix.
As she said an email:
I don't think disabling the blocker temporarily for Firefox 23 users is a good idea. There are a few reasons for this:
Some domains include a mix of both HTTP and HTTPS pages. For the HTTPS pages (ex: login, purchase flow, etc) they may set a secure cookie. Their HTTP pages may have a valid cert for the HTTPS version, but they don't intended for their users to visit the HTTPS version. Hence, they may include HTTP content on these pages. When the users do visit the HTTPS version of the page, their secure cookies are protected by Mixed Content Blocker. If we turn the Mixed Content Blocker off globally, then HTTP script can steal the secure cookies.
Note that this is only an issue for Mixed Active Content. If the content is Mixed Display, the request is an HTTP request and does not include the secure cookies. The content itself (ex: an image) doesn't have access to the DOM and hence can't steal the secure cookie.
If a Firefox user decides to uninstall HTTPS Everywhere (for whatever reason), the setting for the Mixed Content Blocker will remain off. Uninstalling the add-on won't set the setting back to its default.
So I think we need another quick mitigation instead. I wonder if we can fix legacy/trac#8774 (moved) and legacy/trac#8776 (moved) in the next 2 weeks before we push an update, so we have 1 week left over before FF23 becomes stable so that HTTPS Everywhere users have time to upgrade our add-on before they upgrade Firefox?
I think this would be a more acceptable quick fix, though it will be far from perfect.
We still have to deal with the Mozilla MCB firing at the wrong time bug (https://bugzilla.mozilla.org/show_bug.cgi?id=878890) and the fact that many HTTPS Everywhere rules that aren't marked platform="mixedcontent" still cause mixed content problems. We should automate finding and marking these.
The reality of the situation is that their implementation can't protect against large categories of script and content leaks either, in particular sites where the https script sources redirect to http (such scripts cannot be blocked by the nsIContentPolicy-based Mixed Content Blocker).
I think we should aim for the stopgap solution that does the least damage to sites without completely disabling the huge swaths of our ruleset database (especially rules that only cause problems with the broken nsIContentPolicy implementation), because either of those will also cause users to lose protection, via less ruleset coverage, or via uninstalling HTTPS-Everywhere
Given that our only choices seem to be "disable a ton more rules than we should", "seriously degrade the user experience of HTTPS-Everywhere users", and "disable mixed content until it can be done right", I think the least invasive choice is the third one.
Trac: Summary: Postpone Firefox mixed content blocking from FF 23 -> 24 (with user notice & control) to Find which rules trigger the FF23 mixed content blocker and mark them platform="mixedcontent"
We've decided to aim to identify which rulesets are triggering MCB in FF23+. What I am planning to do is to pull all the target URLS from our ruleset library and use Tanvi's Mochitest to find out which ones are triggering MCB. Then, I will need to mark all the rulesets that trigger MCB with platform = "mixed_content"
Tanvi has given me some assistance and directions on how to run the Mochitest. I am in the process of cloning firefox and building it.
Micah is working on legacy/trac#8774 (moved) and legacy/trac#8776 (moved). We will resort to "Plan A" (see last paragraph above) if things don't pan out, but are hoping that will not be the case.
Please make sure that this is fully automatable and easily reproducible. The set of rulesets broken by FF23 will be much larger than the set broken by a proper, secure implementation of MCB that doesn't use nsIContentPolicy.
This means that once we fix their mess for them, we need to go back and revisit all of these rules and turn the subset that was disabled incorrectly back on.
This is done, and the 3.3 update marked a ton of rules platform="mixedcontent". I'm keeping this ticket open for now though until we have the automated tests that we used (Firefox mochitests) in a git repository and easily reproducable. Lisa is currently working on that.
is there a place for users to report domains that are broken by the https-e/mixed-content combination in ff23+? In my case, sciencedirect.com (Sciverse.xml ruleset) fails to load css & js and is rendered much less usable (e.g., full article content does not load)
is there a place for users to report domains that are broken by the https-e/mixed-content combination in ff23+? In my case, sciencedirect.com (Sciverse.xml ruleset) fails to load css & js and is rendered much less usable (e.g., full article content does not load)
I think you should report them like any other HTTPS Everywhere bug. You can open a new ticket here, or send an email to the https-everywhere-rules listserve. I just opened a new ticket for sciencedirect.com: legacy/trac#9784 (moved)