Mixed content icon draws too much attention

RESOLVED FIXED in Firefox 14



5 years ago
5 years ago


(Reporter: zpao, Assigned: jaws)


15 Branch
Firefox 15
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox14 fixed)



(4 attachments, 2 obsolete attachments)

The mixed content caution sign is literally appropriate, but visually draws a lot of attention to itself.

My initial reaction to it was "omg what did I do wrong?". It's a standout color in our rather muted theme (at least on OS X) and I was drawn to it. Maybe that's what we want, but it was surpising. Part of that may be historical context where that symbol has been used on Windows (and elsewhere) to indicate potential dataloss or "something went wrong".

I know others disagree, so... discuss.
Created attachment 624770 [details]

I completely agree.

We should include small caution sigh onto our lock image like Chrome or use standard globe icon used for non encrypted connections like Opera.
Dropped into a discussion with some security folks about this.

AIUI the main concern is that the difference between the grey lock and grey globe (on Firefox 14) is too indistinct, and so it's difficult to notice if you get bumped into mixed-content mode. (Compare to release [Fx12], where it's the difference between a big blue identity block vs just a grey square w/ favicon).

So they'd like to uplift _something_ to address that. But as this bug notes, the yellow /!\ icon feels too alarming.

The long term solution may be something like blocking the non-SSL content w/ notification bar to load it anyway, or to differentiate between non-SSL that's mostly-harmless (like images) vs. non-SSL content that might be dangerous (like script). But that sounds like it's a ways out, and so isn't an option for FF14 or FF15.

Backing out the identity block changes was discussed (goal being to not change security messaging over multiple releases), but I'm not sure if that really is a big concern. It's a bit of a wash, because it's a security win to remove the favicon from the identity block. So let's avoid going there.

It sounds like a reasonable compromise would be to change the icon so it's less attention-grabbing, but still keep it distinguishable from the lock icon. A conflicting set of design goals to be sure! :)
Created attachment 624914 [details]
Grey /!\ icon

This was one thought -- same icon shape, just not OMGYELLOW. (quick photoshop hack)

An improvement over the status quo -- perhaps we can just try it on Nightly while we discuss? I'm not 100% sure if it's the right final icon, since it seems to me that an alert is the wrong metaphor here, and the user really has no control over the situation.
Created attachment 624915 [details]
Plain SSL vs Mixed SSL in FF12

(And just for reference, this is what Firefox 12 shows today)
Created attachment 625020 [details]
Comparison of Firefox & Chrome & Opera.png

I like Chrome approach how it displays encrypted info.
It's very logical and informative.

Used sites:
Attachment #624770 - Attachment is obsolete: true
One thing to keep in consideration is: what threat are we actually trying to communicate to the user?

If the threat is that we can't be sure that the identity of this page is what it says it is, due to mixed content, then I think indeed we should be putting a very visible alert next to the domain name. I don't believe that's the case, though. (Anyone?)

I believe that the threat is that the connection between the user and the site isn't 100% encrypted, and thus information sent back and forth may be intercepted. By my understanding, that's only of concern if the user begins entering information, at which point we could call attention to it only at the point where the user begins typing, or perhaps could simply (as we used to do at one point) not show the page as being secure (ie: don't show the https:// or lock icon at all) and then provide more information if someone clicks on the globe.

My meta point here is: don't just think of conveying the state, think about what that state implies for the user and what they're trying to do, and how best to convey information that will be useful in those cases. My instinct is that mixed-content SSL should just be presented like non-SSL, and webmasters should be encouraged to fix mixed-content problems. A nice backup, though, might be to only care about that in cases where the non-SSL content is truly threatening (scripts, form elements, embeds?)
Created attachment 628083 [details] [diff] [review]
Patch for bug

This patch changes the warning triangles to grayscale.
Assignee: nobody → jaws
Attachment #628083 - Flags: ui-review?(shorlander)
Attachment #628083 - Flags: review?(dolske)
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → 15 Branch
Comment on attachment 628083 [details] [diff] [review]
Patch for bug

I love reviewing base64.
Attachment #628083 - Flags: review?(dolske) → review+
Created attachment 628099 [details] [diff] [review]
Patch for bug v2

Another base64 review, this time with updated icons from Stephen :)
Attachment #628083 - Attachment is obsolete: true
Attachment #628083 - Flags: ui-review?(shorlander)
Attachment #628099 - Flags: review?(dolske)
Comment on attachment 628099 [details] [diff] [review]
Patch for bug v2

Also, shorlander's review is enough for image swaps.
Attachment #628099 - Flags: review?(dolske) → review+
Flags: in-testsuite-
Target Milestone: --- → Firefox 15
Comment on attachment 628099 [details] [diff] [review]
Patch for bug v2

[Approval Request Comment]
Bug caused by (feature/regressing bug #): none, new feature
User impact if declined: inconsistent security UI between Fx14 & Fx15
Testing completed (on m-c, etc.): just pushed to inbound, but only an image swap
Risk to taking this patch (and alternatives if risky): no risk anticipated
String or UUID changes made by this patch: none

I am requesting approval for this patch as well as the patch for bug 747090.
Attachment #628099 - Flags: approval-mozilla-aurora?
Last Resolved: 5 years ago
Resolution: --- → FIXED
Comment on attachment 628099 [details] [diff] [review]
Patch for bug v2

[Triage Comment]
Approved for Aurora given this is a low risk change to get feature parity between FF14 and FF15.
Attachment #628099 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
status-firefox14: --- → fixed
You need to log in before you can comment on or make changes to this bug.