Heads up regarding changes to Firefox that break pages on *.mozilla.org

[Brian Smith]

Hello all,

As I mentioned in IRC on Friday Night, Firefox Nightly will soon have the Mixed Content Blocker feature enabled. This means that any scripts, iframes, fonts, XHR requests, etc. that are sent as "http://" requests on an "https://" page will be blocked, with some important exceptions noted below.

Here are some pages that we've found that break with the new behavior:

* https://blog.mozilla.org/blog/2013/01/29/mozilla-firefox-flicks-global-video-competition-returns/
The Vimeo embed breaks; see the Vimeo link below for how to fix it.

* https://air.mozilla.org/region-based-storage-management-parasailing-without-a-garbage-chute/
The vid.ly embed is broken and requires assistance from vid.ly to fix. (The Air guys are on it already.)

You can test this behavior right now by setting security.mixed_content.block_active_content=true in about:config in Nightly. Soon, that pref will be set to true by default. Mixed content loads are highlighted in red on the Net section of the web console in Firefox Nightly, and are also highlighted in IE's and Chrome's dev tools.

The exceptions are:

* <img src='http://...'>
* <video> and <audio>
* Requests made for images, video, and audio by plugins.

Images, videos, and audio will work fine. HOWEVER, in many cases, video embedding APIs like YouTube, Vimeo, vid.ly, etc. work by having the page embed a <script src="http://"> element that dynamically inserts the necessary video/plugin elements. With the new changes to Firefox's behavior, these embeddings WILL NOT WORK without modifying them to have <script src="https://">. See the end of this email for some documentation about popular video embedding APIs' support for HTTPS embedding.

In addition, because of a bug in our implementation of this feature, we will sometimes treat a load as mixed content even when HSTS fixes it. Some people have advocated that we WONTFIX this. See https://bugzilla.mozilla.org/show_bug.cgi?id=838395 and please share your thoughts from the webdev perspective in the bug. My opinion is that we should fix the bug so that content that is properly secured by HSTS isn't blocked because the user isn't harmed. That said, I also think it is good for *.mozilla.org to avoid relying on HSTS to fix these things, especially since IE doesn't implement HSTS.

You can see exactly how Firefox classifies mixed content by looking at the heavily-commented source:

https://mxr.mozilla.org/mozilla-central/source/content/base/src/nsMixedContentBlocker.cpp#168

Note that plugin content is currently loaded more laxly than I described above; however, going forward you should not expect plugins to be able to load things other than images, audio, and video. In particular, I intend to find some way to block other kinds of mixed-content plugin loads (in particular .swf/.jar/.class).

There is also a security.mixed_content.block_display_content preference. This will enable an even stricter blocking that will block ALL loads, including images, videos, and audio. We are NOT intending to default that pref to true (ever). However, we may try to do things similar to what SSL Everywhere does (e.g. automatically rewriting URLs from http://X to https://X and then falling back to http://X if the https://X load fails).

See http://apiblog.youtube.com/2011/02/https-support-for-youtube-embeds.html
and http://support.google.com/youtube/bin/answer.py?hl=en&answer=171780
and http://vimeo.com/help/faq/embedding#https
and http://support.brightcove.com/en/video-cloud/docs/publishing-brightcove-player-https-page
and http://www.dailymotion.com/doc/api/sdk-javascript.html#ssl

Cheers,
Brian

[Brian Smith]

Brian Smith wrote:
> Here are some pages that we've found that break with the new
> behavior:
>
> *
> https://blog.mozilla.org/blog/2013/01/29/mozilla-firefox-flicks-global-video-competition-returns/
> The Vimeo embed breaks; see the Vimeo link below for how to fix it.
>
> *
> https://air.mozilla.org/region-based-storage-management-parasailing-without-a-garbage-chute/
> The vid.ly embed is broken and requires assistance from vid.ly to
> fix. (The Air guys are on it already.)

Oh, I forgot to mention something: These pages are already broken in IE for the same reason they will soon be broken in Firefox. In general, our mixed content blocking implements the more strict rules that IE also enforces and I'll be lobbying the Chrome guys to implement as many of them as possible too.

Cheers,
Brian

[Matthew Claypotch]

I commented in the linked bug, but my big question is this. Are we communicating to the user (via web console, ideally) *why* blocked requests are blocked? If not, we should.

> _______________________________________________
> dev-webdev mailing list
> dev-w...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-webdev
>

[Brian Smith]

Matthew Claypotch wrote:
> I commented in the linked bug, but my big question is this. Are we
> communicating to the user (via web console, ideally) *why* blocked
> requests are blocked? If not, we should.

It would be useful to get your teams' opinion on the UI without being biased from my explanations of how the UI works, because the UX is the core issue here. Please try Nightly and set the security.mixed_content.block_active_content=true and let us know what you think about the UX. The pages I linked to in my original message in this thread are good test cases.

Cheers,
Brian

[Matthew Claypotch]

Okay, checked those pages out, my thoughts below.

Given that I was primed about the changes, I did notice the strange shield logo in the location bar.
When the feature is off, mixed content logs in the web console in a highly noticeable way (which is awesome!). That it doesn't log or appear *at all* when the feature is on really isn't acceptable. I don't know what requests aren't secure, which services to troubleshoot, and that leads to frustration. Linking to a support article in the doorhanger with the ambiguous text "Learn More" isn't helpful whatsoever. I would think as a developer that would tell me which URLs were blocked. My general feeling is one of serious dissatisfaction about how quietly this feature causes things to fail. I wouldn't be comfortable enabling this feature by default without *any* dev feedback.

~potch

----- Original Message -----
> From: "Brian Smith" <bsm...@mozilla.com>
> To: "Matthew Claypotch" <po...@mozilla.com>
> Cc: "Tanvi Vyas" <ta...@mozilla.com>, dev-w...@lists.mozilla.org
> Sent: Monday, February 11, 2013 12:50:00 PM
> Subject: Re: [webdev] Heads up regarding changes to Firefox that break pages on *.mozilla.org
>

[Joshua Smith]

Hello,

I think that the Mixed Content Blocker is a good idea, but some users may not like this. There have been a lot of "Firefox Made Me Sad Because" feedbacks because we changed something like this, and users don't understand why. It is just my opinion, but maybe we should add the blocker as a preference to the Security panel and let users decide whether to enable it. In any case, disabling it should be easier then setting security.mixed_content.block_active_content to false.


--
Joshua Smith
UX/Interaction Volunteer
Mozilla
micov...@verizon.net

On Feb 11, 2013, at 3:21 PM, Brian Smith <bsm...@mozilla.com> wrote:

> Hello all,
>
> As I mentioned in IRC on Friday Night, Firefox Nightly will soon have the Mixed Content Blocker feature enabled. This means that any scripts, iframes, fonts, XHR requests, etc. that are sent as "http://" requests on an "https://" page will be blocked, with some important exceptions noted below.
>

> Here are some pages that we've found that break with the new behavior:
>
> * https://blog.mozilla.org/blog/2013/01/29/mozilla-firefox-flicks-global-video-competition-returns/
> The Vimeo embed breaks; see the Vimeo link below for how to fix it.
>
> * https://air.mozilla.org/region-based-storage-management-parasailing-without-a-garbage-chute/
> The vid.ly embed is broken and requires assistance from vid.ly to fix. (The Air guys are on it already.)
>

> You can test this behavior right now by setting security.mixed_content.block_active_content=true in about:config in Nightly. Soon, that pref will be set to true by default. Mixed content loads are highlighted in red on the Net section of the web console in Firefox Nightly, and are also highlighted in IE's and Chrome's dev tools.
>
> The exceptions are:
>
> * <img src='http://...'>
> * <video> and <audio>
> * Requests made for images, video, and audio by plugins.
>
> Images, videos, and audio will work fine. HOWEVER, in many cases, video embedding APIs like YouTube, Vimeo, vid.ly, etc. work by having the page embed a <script src="http://"> element that dynamically inserts the necessary video/plugin elements. With the new changes to Firefox's behavior, these embeddings WILL NOT WORK without modifying them to have <script src="https://">. See the end of this email for some documentation about popular video embedding APIs' support for HTTPS embedding.
>
> In addition, because of a bug in our implementation of this feature, we will sometimes treat a load as mixed content even when HSTS fixes it. Some people have advocated that we WONTFIX this. See https://bugzilla.mozilla.org/show_bug.cgi?id=838395 and please share your thoughts from the webdev perspective in the bug. My opinion is that we should fix the bug so that content that is properly secured by HSTS isn't blocked because the user isn't harmed. That said, I also think it is good for *.mozilla.org to avoid relying on HSTS to fix these things, especially since IE doesn't implement HSTS.
>
> You can see exactly how Firefox classifies mixed content by looking at the heavily-commented source:
>
> https://mxr.mozilla.org/mozilla-central/source/content/base/src/nsMixedContentBlocker.cpp#168
>
> Note that plugin content is currently loaded more laxly than I described above; however, going forward you should not expect plugins to be able to load things other than images, audio, and video. In particular, I intend to find some way to block other kinds of mixed-content plugin loads (in particular .swf/.jar/.class).
>
> There is also a security.mixed_content.block_display_content preference. This will enable an even stricter blocking that will block ALL loads, including images, videos, and audio. We are NOT intending to default that pref to true (ever). However, we may try to do things similar to what SSL Everywhere does (e.g. automatically rewriting URLs from http://X to https://X and then falling back to http://X if the https://X load fails).
>
> See http://apiblog.youtube.com/2011/02/https-support-for-youtube-embeds.html
> and http://support.google.com/youtube/bin/answer.py?hl=en&answer=171780
> and http://vimeo.com/help/faq/embedding#https
> and http://support.brightcove.com/en/video-cloud/docs/publishing-brightcove-player-https-page
> and http://www.dailymotion.com/doc/api/sdk-javascript.html#ssl
>

[Mike Cooper]

I enabled the setting and tried out the page with the blocked video. I
didn't see anything odd in the web console, and the Vimeo iframe didn't
load. If I hadn't expected this to happen, I would be very confused, both
as a user and as a developer. I see now that a shield appeared in the URL
bar, but maybe it would be better to have the door hanger pop up
automatically the first time it happens? I didn't notice the shield at
first until I went back to look for it.

I think the reason nothing showed in the web console is because it was an
iframe. Maybe in scenarios like this, it would be good to print an error,
as opposed to just making the request red. This way things that don't show
up as requests in the web console (or if I have the Net filter turned off)
are still visible.

Another thing that would be nice is to have an overlay on the blocked
element, so there isn't just a blank spot on the page, similar to the
click-to-play for Flash. This would help me realize something has happened
instead of just some missing content.

On Mon, Feb 11, 2013 at 12:50 PM, Brian Smith <bsm...@mozilla.com> wrote:

> Matthew Claypotch wrote:
> > I commented in the linked bug, but my big question is this. Are we
> > communicating to the user (via web console, ideally) *why* blocked
> > requests are blocked? If not, we should.
>
> It would be useful to get your teams' opinion on the UI without being
> biased from my explanations of how the UI works, because the UX is the core
> issue here. Please try Nightly and set the
> security.mixed_content.block_active_content=true and let us know what you
> think about the UX. The pages I linked to in my original message in this
> thread are good test cases.
>

[Brian Smith]

Matthew Claypotch wrote:
> Given that I was primed about the changes, I did notice the strange
> shield logo in the location bar.

Thanks. I am worried people will not notice it unless they are looking for it though.

> When the feature is off, mixed content logs in the web console in a
> highly noticeable way (which is awesome!). That it doesn't log or
> appear *at all* when the feature is on really isn't acceptable. I
> don't know what requests aren't secure, which services to
> troubleshoot, and that leads to frustration.

https://bugzilla.mozilla.org/show_bug.cgi?id=837351

> Linking to a support
> article in the doorhanger with the ambiguous text "Learn More" isn't
> helpful whatsoever. I would think as a developer that would tell me
> which URLs were blocked.

The full design of the feature did have a button/link that showed exactly which loads caused the mixed content warning/blocking. However, I think the current opinion of the people working on the feature is that the logging into the web console should help developers "enough" for v1 of the feature, especially once bug 837351 is fixed.

> My general feeling is one of serious
> dissatisfaction about how quietly this feature causes things to
> fail. I wouldn't be comfortable enabling this feature by default
> without *any* dev feedback.

Well, we're trying to get that feedback now in this thread, and then soon more broadly.

Cheers,
Brian

[Matthew Claypotch]

> > My general feeling is one of serious
> > dissatisfaction about how quietly this feature causes things to
> > fail. I wouldn't be comfortable enabling this feature by default
> > without *any* dev feedback.
>
> Well, we're trying to get that feedback now in this thread, and then
> soon more broadly.

Oh, I meant without any feedback given in the developer tools. I know you guys are getting dev feedback right now, and it's much appreciated!

>
> Cheers,
> Brian
>

[Brian Smith]

Joshua Smith wrote:
> I think that the Mixed Content Blocker is a good idea, but some users
> may not like this. There have been a lot of "Firefox Made Me Sad
> Because" feedbacks because we changed something like this, and users
> don't understand why.

One thing to keep in mind is that we're generally blocking things in the same way that IE9+ are, and we're only blocking a few more things than Chrome is (mixed XHR, mixed iframes, and mixed fonts). IE9 was released 2011-03-14 and Chrome 14 was started doing so around June, 2011. (See links below.)

My current hypothesis is that that IE and Chrome have already taken the vast majority of the hits that this change will cause. (I think our Mozilla websites are quite exceptional because we seemingly don't prioritize IE as highly as the rest of the internet does, except for the pages you need to navigate to download Firefox.) However, this is something that I think we can only really measure by turning it on in pre-release builds to get the conversation started. Our goal is to have it stick for the Firefox 21 release but honestly I think there are quite a few more enhancements we need to make so I'm not going to be surprised or sad if it slips to Firefox 22.

> It is just my opinion, but maybe we should
> add the blocker as a preference to the Security panel and let users
> decide whether to enable it. In any case, disabling it should be
> easier then setting security.mixed_content.block_active_content to
> false.

I think is that Firefox needs to make the right tradeoffs by default so that such options are not necessary. (Adding checkboxes to the prefs UI tends to be a crutch used to avoid needing to implement features correctly, IMO.) There are many enhancements referenced by the mixed content blocker tracking bug [1] about ways to improve the security of this feature as well as minimizing negative user impact. The main question is which of the remaining enhancements are needed before we ship the feature in a release. The feedback we get from users and developers will largely determine that, I think.

Regardless, as far as *.mozilla.org is concerned, it is actually an important security issue for the site because allowing <script src='http://'> allows any attacker to completely undo all the protection provided by HTTPS in the first place; I promise that part isn't just to appease the eccentric tastes of us cryptonerds. And, it is important for Firefox that Firefox catches up and passes IE and Chrome here.

Cheers,
Brian

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=MixedContentBlocker

http://blogs.msdn.com/b/ie/archive/2011/06/23/internet-explorer-9-security-part-4-protecting-consumers-from-malicious-mixed-content.aspx
http://googleonlinesecurity.blogspot.com/2011/06/trying-to-end-mixed-scripting.html
http://blog.chromium.org/2012/08/ending-mixed-scripting-vulnerabilities.html
http://blogs.msdn.com/b/ieinternals/archive/2009/06/22/https-mixed-content-in-ie8.aspx

[Brian Smith]

[+lco]

Mike Cooper wrote:
> Subject: Re: [webdev] Heads up regarding changes to Firefox that break pages on *.mozilla.org
>

> I enabled the setting and tried out the page with the blocked video.
> I didn't see anything odd in the web console, and the Vimeo iframe
> didn't load. If I hadn't expected this to happen, I would be very
> confused, both as a user and as a developer. I see now that a shield
> appeared in the URL bar, but maybe it would be better to have the
> door hanger pop up automatically the first time it happens? I didn't
> notice the shield at first until I went back to look for it.

This is the same problem that we've been having with the Click-to-play UI. i guess the solutions should be similar too.

> I think the reason nothing showed in the web console is because it
> was an iframe. Maybe in scenarios like this, it would be good to
> print an error, as opposed to just making the request red. This way
> things that don't show up as requests in the web console (or if I
> have the Net filter turned off) are still visible.

There's already a bug about adding the logging to the web console when the content is blocked in addition to when it is allowed.

I am very curious about the idea that the Net category may not be the best place in the web console for it. I see the pros and cons to having it in the Net category. My personal opinion is that it would be good to have a new Security category that such things go into. I imagine a lot of developers would like to turn off the Net category but still see security issues. It would be good to get more feedback on how the web console works here.

> Another thing that would be nice is to have an overlay on the blocked
> element, so there isn't just a blank spot on the page, similar to
> the click-to-play for Flash. This would help me realize something
> has happened instead of just some missing content.

That sounds like a great idea but I think we need to look at the telemetry first to determine how to prioritize it. The problem is that most of the stuff we're blocking isn't visible on the page. I suspect 90% of what gets blocked is <script src="http://..."> and there's no good way to make a placeholder for that. If we find we're blocking a lot of <iframe src="http://"> then that is a place where we could potentially put a placeholder. But, maybe instead we should first spend more effort on the things like the auto-rewriting of <iframe src="http://"> to <iframe src="https://"> instead of just blocking it. If that could be made to work, we may find that works much better than the placeholders.

Cheers,
Brian

[Tanvi Vyas]

Thanks for your feedback! I have a proof of concept patch to indicate
which content has been blocked in the webconsole and error console -
https://bugzilla.mozilla.org/show_bug.cgi?id=837351. I need to update
the patch and once we've landed that, i think it will be much more
useful for developers to understand what is causing the
errors/failures. We also need to work on documentation
(https://bugzilla.mozilla.org/show_bug.cgi?id=839238) and let the
developer community know about the feature while it's in aurora, so they
have time to fix mixed active content issues before most users see them.

The design of the Mixed Content Blocker is being discussed in
https://bugzilla.mozilla.org/show_bug.cgi?id=827595. The original
design showed the pop-up notification the first three times a user
visited a mixed content; UX is working on a way to make the shield more
noticable without automatically showing the doorhanger. There have been
similar concerns about the plugin icon.

~Tanvi

On 2/11/13 1:08 PM, Mike Cooper wrote:
> I enabled the setting and tried out the page with the blocked video. I
> didn't see anything odd in the web console, and the Vimeo iframe
> didn't load. If I hadn't expected this to happen, I would be very
> confused, both as a user and as a developer. I see now that a shield
> appeared in the URL bar, but maybe it would be better to have the door
> hanger pop up automatically the first time it happens? I didn't notice
> the shield at first until I went back to look for it.
>

> I think the reason nothing showed in the web console is because it was
> an iframe. Maybe in scenarios like this, it would be good to print an
> error, as opposed to just making the request red. This way things that
> don't show up as requests in the web console (or if I have the Net
> filter turned off) are still visible.
>

> Another thing that would be nice is to have an overlay on the blocked
> element, so there isn't just a blank spot on the page, similar to the
> click-to-play for Flash. This would help me realize something has
> happened instead of just some missing content.
>
>

> On Mon, Feb 11, 2013 at 12:50 PM, Brian Smith <bsm...@mozilla.com
> <mailto:bsm...@mozilla.com>> wrote:
>
> Matthew Claypotch wrote:
> > I commented in the linked bug, but my big question is this. Are we
> > communicating to the user (via web console, ideally) *why* blocked
> > requests are blocked? If not, we should.
>
> It would be useful to get your teams' opinion on the UI without
> being biased from my explanations of how the UI works, because the
> UX is the core issue here. Please try Nightly and set the
> security.mixed_content.block_active_content=true and let us know
> what you think about the UX. The pages I linked to in my original
> message in this thread are good test cases.
>
> Cheers,
> Brian
> _______________________________________________
> dev-webdev mailing list

> dev-w...@lists.mozilla.org <mailto:dev-w...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-webdev
>
>

[Larissa Co]

> The design of the Mixed Content Blocker is being discussed in
> https://bugzilla.mozilla.org/show_bug.cgi?id=827595. The original
> design showed the pop-up notification the first three times a user
> visited a mixed content; UX is working on a way to make the shield
> more noticable without automatically showing the doorhanger. There
> have been similar concerns about the plugin icon.

I wouldn't count on this happening anytime soon, unfortunately :( But I
will bring it up again in the desktop meeting to see if we can get some
traction on it.

>> I enabled the setting and tried out the page with the blocked video.
>> I didn't see anything odd in the web console, and the Vimeo iframe
>> didn't load. If I hadn't expected this to happen, I would be very
>> confused, both as a user and as a developer. I see now that a shield
>> appeared in the URL bar, but maybe it would be better to have the
>> door hanger pop up automatically the first time it happens? I didn't
>> notice the shield at first until I went back to look for it.

We're only blocking Mixed Scripts right now, not mixed content, so I'm
assuming Vimeo is using something falls into that category, similar to
what we discovered in YouTube? Tanvi, maybe we can discuss if
whitelisting these two sites is a good idea, or if you already have some
workaround for it, since the majority of experiences users will have
with mixed script might result from big sites such as these.

>>
>> Another thing that would be nice is to have an overlay on the blocked
>> element, so there isn't just a blank spot on the page, similar to the
>> click-to-play for Flash. This would help me realize something has
>> happened instead of just some missing content.
>>

One reason why this isn't as viable for mixed scripts as it is for
Click-to-play is that we assume that most things that we block will not
have anything visible on the page. But with more testing, we might find
out that the majority of mixed script cases do have a visible component.
In which case, yes, we can consider this. I'm working on CtP anyway, so
we might be able to do something similar.