865352 - Replace grey globe with grey warning triangle when the page contains mixed passive content

Status: VERIFIED FIXED

(Firefox :: Security, defect)

Description

[Larissa Co [:lco]]

We currently show a globe when the page contains mixed passive content and a yellow warning triangle when the page shows mixed active content. People have pointed out (for example, bug 838359) that the globe is misleading because the page still contains insecure content. 

We don't want to show the yellow warning triangle because mixed passive content isn't as critical as mixed active content, and we don't currently provide the user with any mechanism to block it. 

So as a compromise, Tanvi and I discussed displaying a grey warning triangle when there's mixed passive content on the page.

Note that I'm not 100% happy with having a negative indicator (the warning triangle) right next to a positive indicator ("https"). I would rather, at some point in time, also implement a crossed out https (as discussed in bug 834830)

Comment 1

[Larissa Co [:lco]]

@shorlander, can you please give Tanvi a grey warning triangle icon that she can use? She only has a yellow warning triangle right now.

Comment 2

[Stephen Horlander [:shorlander]]

Attachment: Grey Warning Triangle - Windows - 01

Comment 3

[Stephen Horlander [:shorlander]]

Attachment: Grey Warning Triangle - OSX - 01

Comment 4

[Stephen Horlander [:shorlander]]

Attachment: Grey Warning Triangle @2x - OSX - 01

Comment 5

[Tanvi Vyas[:tanvi]]

What do we use for Linux?

Comment 6

[Stephen Horlander [:shorlander]]

(In reply to Tanvi Vyas [:tanvi] from comment #5)
> What do we use for Linux?

The Windows one.

Comment 7

[[:Aleksej]]

It seems that the icon description in comment #0 does not reflect what Firefox 22.0…Nightly do.

Comment 8

[[:Aleksej]]

(at least with the triange; apparently the grey globe icon is not related to mixed content, but to HTTPS generally)

Comment 9

[Tanvi Vyas[:tanvi]]

(In reply to Aleksej [:Aleksej] from comment #7)
> It seems that the icon description in comment #0 does not reflect what
> Firefox 22.0…Nightly do.

The triangle will only show up if Mixed Content Blocker is enabled (security.mixed_content.block_active_content set to true in about:config).  So starting in FF 23 (when that is the default), you will see the yellow triangle.

Comment 10

[Tanvi Vyas[:tanvi]]

(In reply to Tanvi Vyas [:tanvi] from comment #9)
> So starting in FF 23 (when that is the default), you will see the yellow
> triangle.
WHEN there is Mixed Active Content loaded on the page.

Comment 11

[[:Aleksej]]

And what is the difference from the half-gray shield icon?

Comment 12

[Tanvi Vyas[:tanvi]]

(In reply to Aleksej [:Aleksej] from comment #11)
> And what is the difference from the half-gray shield icon?

I'm not sure what the exact question is, but the shield icon comes up when Mixed Active Content is blocked.  See the Mixed Content Blocker UI section here for some explanations on different scenarios and their corresponding UIs:
https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/

Comment 13

[[:Aleksej]]

(In reply to Tanvi Vyas [:tanvi] from comment #12)
Oh, I see: this bug is about when the user has unblocked the mixed active content for the page.

Comment 14

[Tanvi Vyas[:tanvi]]

Attachment: Add Mixed Display Icon - First Draft

First draft; needs testing before it's ready for review/feedback.

Comment 15

[Tanvi Vyas[:tanvi]]

Comment on attachment 786589 [details] [diff] [review]
Add Mixed Display Icon - First Draft

Tested on OSX and looks good.  r? to jaws.

Comment 16

[Jared Wein [:jaws] (please needinfo? me)]

I don't think we should do this.

(In reply to Larissa Co [:lco] from comment #0)
> We don't want to show the yellow warning triangle because mixed passive
> content isn't as critical as mixed active content, and we don't currently
> provide the user with any mechanism to block it. 

As this snippet of comment #0 points out, we don't currently provide the user with any mechanism to block the mixed passive content. So at this point we will be showing a warning triangle to the user but there is nothing that the user could have done to prevent this warning.

Also, because mixed passive content is not blocked, many sites contain mixed passive content and Firefox will be showing a warning triangle for a huge amount of sites. Many of these sites, like GMail when you load an image embedded in an email, will have nothing that they can do about it.

Comment 17

[Larissa Co [:lco]]

(In reply to Jared Wein [:jaws] from comment #16)

> 
> As this snippet of comment #0 points out, we don't currently provide the
> user with any mechanism to block the mixed passive content. So at this point
> we will be showing a warning triangle to the user but there is nothing that
> the user could have done to prevent this warning.

No, but at least it could indicate that they should be extra-careful. An attacker can still modify the image or view the user's cookies with passive mixed content. 
> 
> Also, because mixed passive content is not blocked, many sites contain mixed
> passive content and Firefox will be showing a warning triangle for a huge
> amount of sites. Many of these sites, like GMail when you load an image
> embedded in an email, will have nothing that they can do about it.

The problem is that this is a trade-off between not misleading people about the page's security and not making them worry unnecessarily. I think the lock (etc) icon is really more of an expert indicator; I don't it's something the majority of people notice. So if my assumption is correct, then I would rather be accurate and more informative even though it may be distracting. I also tried to minimize the impact of that distraction by using a grey icon.

Comment 18

[Daniel Veditz [:dveditz]]

(In reply to Jared Wein [:jaws] from comment #16)
> As this snippet of comment #0 points out, we don't currently provide the
> user with any mechanism to block the mixed passive content.

Sure we do, the security.mixed_content.block_display_content pref

> So at this point we will be showing a warning triangle to the user but
> there is nothing that the user could have done to prevent this warning.

Why don't we show the lock and pretend nothing is wrong? Because we do want to alert users. The globe icon sends two wrong signals: that the main page was unencrypted, and worse "nothing is wrong, everything is normal".

> Also, because mixed passive content is not blocked, many sites contain mixed
> passive content and Firefox will be showing a warning triangle for a huge
> amount of sites.

How is the globe any better? Either mixed-display content is no problem at all and we should show the normal lock (but we've never done that, and other browsers don't either) or we need a unique "broken" case. We used to use a lock icon with a red slash through it -- that could still work. An unobtrusive version of the same warning we use for the dangerous case seems to fit the theme better but I'm not wedded to it.

Firefox and other browsers have been showing a broken-lock icon of some sort for the mixed-display case since the lock icon was invented. The only exception was Firefox in the lost years where our indicator was a blob of mysterious color, and the broken case was indicated by missing color. That's what we're trying to fix.

Comment 19

[Dave Garrett]

(In reply to Larissa Co [:lco] from comment #17)
> I think the lock (etc) icon is really more of an expert indicator;
> I don't it's something the majority of people notice.

Many people have been trained by multiple companies and multiple browser vendors to look for the lock icon. They don't really know what it means, but they know they should probably have it. Firefox got rid of it a while back and had to add it back because people got confused.

Comment 20

[Jesse Ruderman]

I agree with Jaws.  The vast majority of mixed display content is harmless: images in email, feeds, or tweets.  These images have to clearly be "not part of the web app" (whether the transport is secure or not) because their source is untrusted.

Firefox should not raise an alarm about mixed display content.  At best it causes warning fatigue, and at worst it discourages sites with user-generated content from using https for the parts that matter.

We should restore the lock icon for this case and downgrade the warning to the same level as "site does not use OCSP" or "site does not use STS" (not part of primary UI).

Comment 21

[Jared Wein [:jaws] (please needinfo? me)]

(In reply to Daniel Veditz [:dveditz] from comment #18)
> (In reply to Jared Wein [:jaws] from comment #16)
> > As this snippet of comment #0 points out, we don't currently provide the
> > user with any mechanism to block the mixed passive content.
> 
> Sure we do, the security.mixed_content.block_display_content pref

Hidden prefs are not a viable explanation for poor UI.

> > So at this point we will be showing a warning triangle to the user but
> > there is nothing that the user could have done to prevent this warning.
> 
> Why don't we show the lock and pretend nothing is wrong? Because we do want
> to alert users. The globe icon sends two wrong signals: that the main page
> was unencrypted, and worse "nothing is wrong, everything is normal".
> 
> > Also, because mixed passive content is not blocked, many sites contain mixed
> > passive content and Firefox will be showing a warning triangle for a huge
> > amount of sites.
> 
> How is the globe any better? Either mixed-display content is no problem at
> all and we should show the normal lock (but we've never done that, and other
> browsers don't either) or we need a unique "broken" case. We used to use a
> lock icon with a red slash through it -- that could still work. An
> unobtrusive version of the same warning we use for the dangerous case seems
> to fit the theme better but I'm not wedded to it.
> 
> Firefox and other browsers have been showing a broken-lock icon of some sort
> for the mixed-display case since the lock icon was invented. The only
> exception was Firefox in the lost years where our indicator was a blob of
> mysterious color, and the broken case was indicated by missing color. That's
> what we're trying to fix.

Yes, I see the end goal, but I just want us to be careful with scaring users without enough justification.

Comment 22

[Larissa Co [:lco]]

(In reply to Dave Garrett from comment #19)
> (In reply to Larissa Co [:lco] from comment #17)
> > I think the lock (etc) icon is really more of an expert indicator;
> > I don't it's something the majority of people notice.
> 
> Many people have been trained by multiple companies and multiple browser
> vendors to look for the lock icon. They don't really know what it means, but
> they know they should probably have it. Firefox got rid of it a while back
> and had to add it back because people got confused.

I know we mention this all the time, but is there any research or citation about this? I'm not trying to be obnoxious (and it's likely that it's my own team who's done the research about this). It's just that I want to make sure that I can base my design decisions on knowing whether novices rely on this indicator or not. Also, would they look at it only in the "I'm entering my credit card number" case, or do they look at it every time they see "https"?

A (slightly old) research report on the subject: http://www.usablesecurity.org/emperor/

Comment 23

[Jesse Ruderman]

(In reply to Daniel Veditz [:dveditz] from comment #18)
> Firefox and other browsers have been showing a broken-lock icon of some sort
> for the mixed-display case since the lock icon was invented. The only
> exception was Firefox in the lost years where our indicator was a blob of
> mysterious color, and the broken case was indicated by missing color. That's
> what we're trying to fix.

"Every browser has done it since forever" is a poor reason to keep doing it.

The warning might have made sense back before there was a distinction between mixed active and mixed display content, and back when there weren't 10 other more common and worse ways to screw up SSL (see bug 711816).

Comment 24

[Tanvi Vyas[:tanvi]]

(In reply to Jesse Ruderman from comment #20)
> The vast majority of mixed display content is harmless:
> images in email, feeds, or tweets.  These images have to clearly be "not
> part of the web app" (whether the transport is secure or not) because their
> source is untrusted.
> 

Harmless is quite an understatement.  Sure, if a MITM changes an image from cute puppies to evil puppies, it's not that big of a deal.  But anyone can sniff the network and steal the user's authentication cookies.  Secure cookies are really just not that common yet and hence can't be used as a reason to ignore the security risks of mixed display content.

Comment 25

[Jesse Ruderman]

Sounds like you're referring to the "Only have secure sites open when you're on an untrusted network" strategy.  There are so many ways for this strategy to go wrong (including mixed display content!) that it's not really viable without an extension.

We shouldn't warn all users just so the extension has one less change to make.

Also, the sites in question tend to use STS, so their cookies are safe.  If anything, we should be warning about lack of STS, not mixed display content.

Comment 26

[Tanvi Vyas[:tanvi]]

(In reply to Jesse Ruderman from comment #25)
> Sounds like you're referring to the "Only have secure sites open when you're
> on an untrusted network" strategy.  There are so many ways for this strategy
> to go wrong (including mixed display content!) that it's not really viable
> without an extension.
> 
> We shouldn't warn all users just so the extension has one less change to
> make.
>
I was referring to the fact that authentication cookies could be read over HTTP by sniffers.  I'm not sure what extension you are referring to.  (Although it would be really cool to put Firefox in a different mode when you on an untrusted network, I don't know of a way to do that, and that is out of scope for this bug.)

My point is that mixed display content is not harmless and we definitely should not show the lock icon for a site that is not fully SSL.

Comment 27

[Dave Garrett]

(In reply to Jesse Ruderman from comment #23)
> "Every browser has done it since forever" is a poor reason to keep doing it.

Yes it is, but that doesn't make it any less true. I generally supported Firefox ditching the lock icon paradigm entirely, but the notable increase of support requests and complaints by confused users had Mozilla doing a 180 relatively quickly. At this point we are stuck with a mishmash of lock icon semantics derived from what various browser vendors came up with over the past decade or so. The best route forward is probably just to make sure the icon is always as meaningful to the average user as possible (whatever that means).

(In reply to Larissa Co [:lco] from comment #22)
> I know we mention this all the time, but is there any research or citation
> about this? I'm not trying to be obnoxious (and it's likely that it's my own
> team who's done the research about this).

Valid question but I don't have a citation to point to, sorry. I'm largely just referencing what happened with the last security indicator overhauls. I did see quite a bit more confused users personally, but my sense of the scope is mostly based on second hand info (that is not fresh in my mind). I'm sure there's something Mozilla quantified but I don't know where it is.

This is the sort of thing I'd really love to see a large scale user poll for.

The only point I think needs to be made in this debate is that whatever the site identity block is, it needs to not warn average users about something that they can't respond to in any useful manner and not warn about things that are "normal" even if we wish they weren't common.

Comment 28

[Jesse Ruderman]

> I was referring to the fact that authentication cookies could be read over
> HTTP by sniffers.

If auth cookies are not marked as secure, you have bigger problems than mixed content.  Redirects let active attackers snarf *all* your cookies when you load *any* non-HTTPS URL in *any* tab.  The exceptions are minor:

1) The attacker has only passive network sniffing capability, and can't convince you to click on links in email.  But they can convince you to *view* email, and they can send you a message that loads images from sites with insecure auth cookies.  They are also happy to use active attacks against the site once they have the auth cookie.

2) You are carefully visiting only HTTPS sites that have no mixed content.  You have no background tabs open to insecure pages that are polling for updates / ads / analytics.

In the second case, the current lock icon doesn't really help you decide what pages to load while on an untrusted network.  Gmail is shown as "fully secure" until you view a message with external images.  When you do load a message with external images, the warning is passive.  By the time you see it, you've already lost.

> I'm not sure what extension you are referring to.  (Although it would be really cool to 
> put Firefox in a different mode when you on an untrusted network, I don't know of a way 
> to do that, and that is out of scope for this bug.)

Writing such an extension is out of scope for this bug.  Describing such an extension is not out of scope for explaining why I think fixing this bug would be a net loss for security.

Comment 29

[Jesse Ruderman]

If Gmail added crossorigin="anonymous" to all external <img> tags, and Firefox decided not to warn about mixed content that uses crossorigin="anonymous", I might be ok with this warning.

Comment 30

[Tanvi Vyas[:tanvi]]

(In reply to Jesse Ruderman from comment #28)
> > I was referring to the fact that authentication cookies could be read over
> > HTTP by sniffers.
> 
> If auth cookies are not marked as secure, you have bigger problems than
> mixed content.  Redirects let active attackers snarf *all* your cookies when
> you load *any* non-HTTPS URL in *any* tab.  The exceptions are minor:
> 
This is an active attack rather than a firesheep style passive attack.

> 1) The attacker has only passive network sniffing capability, and can't
> convince you to click on links in email.  But they can convince you to
> *view* email, and they can send you a message that loads images from sites
> with insecure auth cookies.  They are also happy to use active attacks
> against the site once they have the auth cookie.
> 
This is a targeted attack (they have to send the people at the internent cafe that they want to attack an email).  Again, not as passive and easy as opening up Firesheep at the cafe.

> 2) You are carefully visiting only HTTPS sites that have no mixed content. 
> You have no background tabs open to insecure pages that are polling for
> updates / ads / analytics.
> 
> In the second case, the current lock icon doesn't really help you decide
> what pages to load while on an untrusted network.  Gmail is shown as "fully
> secure" until you view a message with external images.  When you do load a
> message with external images, the warning is passive.  By the time you see
> it, you've already lost.
Gmail does not automatically load mixed display content.  The user has to decided to load images on any given email.  It can make a permanent decision for a specific domain, and at that point, all images from that location will load and hence the users cookies for that domain will be sent.  Since gmail blocks these images by default (because it knows they are a security risk), I don't think it's a good example to call out.  It does let you decide.

We can't ask users to make a decision about mixed display content, but we shouldn't be lying to them about it either.  The same way we don't remove the "https" from the url bar (and make the user think they are on an http page), we shouldn't keep the lock icon (and make users think they are on a fully secure page).  The globe icon (what we currently show) doesn't make any sense for the situation.  Moreover, user's don't notice the lack of a security indicator (no lock) but may notice the warning triangle.  It's not glaring and in your face like the yellow triangle, but it's still there for users who want to see it.

Recently, there have been complaints that the shield icon is not noticeable (we are handling that in a separate bug since we want that to be semi-discoverable).  It is also grey and right next to the location bar.  So if a user is not looking for it, they don't see it.  If a user is not looking for the lock/site identity, they may not even notice this grey triangle.

Comment 31

[Jesse Ruderman]

(In reply to Tanvi Vyas [:tanvi] from comment #30)

> Gmail does not automatically load mixed display content.  The user has to
> decided to load images on any given email.  It can make a permanent decision
> for a specific domain, and at that point, all images from that location will
> load and hence the users cookies for that domain will be sent.  Since gmail
> blocks these images by default (because it knows they are a security risk),
> I don't think it's a good example to call out.  It does let you decide.

I believe Gmail's image exceptions are per-sender, not per-image-domain.  Many senders are spoofable.  Enough Gmail users have allowed images from Amazon, Twitter, and Facebook that this isn't really a barrier for attackers.

Comment 32

[Jesse Ruderman]

Darn, <img crossorigin="anonymous"> won't even display the image if the image host doesn't send a CORS header.  That throws a wrench in my idea.

http://www.whatwg.org/specs/web-apps/current-work/multipage/fetching-resources.html#cors-same-origin

What I want for Gmail is to disable sending credentials without "desiring full read access", leaving the image as "tainted" and unavailable for <canvas> shenanigans.

Proposed "nocookie" attribute: https://www.w3.org/Bugs/Public/show_bug.cgi?id=19028

Comment 33

[Hixie (not reading bugmail)]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=11235

Comment 34

[Tanvi Vyas[:tanvi]]

What do we need to get resolution on this bug?  We have UX making the recommendation for the change and a proposed patch ready for review.  We have Dan for this change, and Jesse and Jared against this change.  So where does that leave us?  Who makes the final decision?  Do we need to have a meeting about this?

Comment 35

[Larissa Co [:lco]]

(In reply to Tanvi Vyas [:tanvi] from comment #34)
> What do we need to get resolution on this bug?  We have UX making the
> recommendation for the change and a proposed patch ready for review.  We
> have Dan for this change, and Jesse and Jared against this change.  So where
> does that leave us?  Who makes the final decision?  Do we need to have a
> meeting about this?

I would like to (humbly) suggest that UX gets to make the final call on this bug since the ultimate consequence is on the user's experience. After going back and reading the points people have made, here's my analysis of the situation:

We are actually talking about two different kinds of users on this bug, the "expert" and the "novice" user. I think that a warning indicator is beneficial mostly to the expert user: someone who is actively attentive towards small security indicators and cares enough about their security to pay attention to them. This kind of user understands the subtlety behind "mixed active content" and "mixed passive content", and cares about the risk for the latter.

We also have another kind of user: the security novice. I believe that by default, this user doesn't particularly care about the risk associated with the passive mixed content indicator. I think part of the argument in this bug is whether he "should" care (i.e. the indicator is important enough to show even if he can't do anything about it) or whether he "won't" care about the security risk (i.e. the indicator will just confuse and annoy him).

I would like to come to a conclusion that addresses the needs of both types of users, and I think a grey warning icon does just this.

The security expert gets an indicator to give him an "accurate" picture of the situation. As for the novice user, I'm of the opinion that he "wont" care about the security risk. Yes, this means that I've now come to the conclusion that this indicator is "meaningless" for the novice (if we really think he "should" care, we should design a stronger warning). But even if it's "meaningless", I think that by making the icon subtle (grey), the novice won't even notice that it's there. It's not something he's looking for, and anyway nothing seems to be "broken" on the page. Even if he does notice the icon, or even clicks on it, I think it's likely that it won't bother him from moving forward with his task a all) 

I also think that seeing this particular icon frequently (which btw, no one has provided data about how often mixed passive content occurs) presents a low risk of "warning fatigue" because we use scarier warnings for more important cases. 

So given this analysis, I think there are two things that could sway my judgment about the grey warning icon:

1. Suggest an alternative means of indicating to expert users that the "https" promise of the page is broken (perhaps a more obscure icon than a warning triangle?)
2. Show me that the warning icon will be more distracting / confusing for security novices and that this is more valuable than the amount of protection the icon affords expert users

Comment 36

[Jared Wein [:jaws] (please needinfo? me)]

Comment on attachment 786589 [details] [diff] [review]
Add Mixed Display Icon - First Draft

Review of attachment 786589 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good to me!

Comment 37

[Tanvi Vyas[:tanvi]]

(In reply to Jared Wein [:jaws] from comment #36)
> Comment on attachment 786589 [details] [diff] [review]
> Add Mixed Display Icon - First Draft
> 
> Review of attachment 786589 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks good to me!

Thanks for the review Jared!  Pushed to inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/01d3658a980c

https://hg.mozilla.org/integration/mozilla-inbound/rev/01d3658a980c

Comment 38

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/01d3658a980c

Comment 39

[Mihai Morar, (:MihaiMorar)]

I can confirm that the grey globe that informe you if the website supplies or not identity information was replaced by the grey triangle.

Verified on latest nightly 26 BuildID: 20130828030202