755429 - Mixed content icon draws too much attention

Status: RESOLVED FIXED

(Firefox :: Theme, defect)

Description

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

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.

Comment 1

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: Chrome.png

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.

Comment 2

[Justin Dolske [:Dolske]]

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! :)

Comment 3

[Justin Dolske [:Dolske]]

Attachment: 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.

Comment 4

[Justin Dolske [:Dolske]]

Attachment: Plain SSL vs Mixed SSL in FF12

(And just for reference, this is what Firefox 12 shows today)

Comment 5

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

Attachment: Comparison of Firefox & Chrome & Opera.png

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

Used sites:
https://forum.utorrent.com/viewtopic.php?id=115600
https://people.mozilla.com/~bsterne/tests/62178/test.html

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

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?)

Comment 7

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

Attachment: Patch for bug

This patch changes the warning triangles to grayscale.

Comment 8

[Justin Dolske [:Dolske]]

Comment on attachment 628083 [details] [diff] [review]
Patch for bug

I love reviewing base64.

Comment 9

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

Attachment: Patch for bug v2

Another base64 review, this time with updated icons from Stephen :)

Comment 10

[Justin Dolske [:Dolske]]

Comment on attachment 628099 [details] [diff] [review]
Patch for bug v2

Also, shorlander's review is enough for image swaps.

Comment 11

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/b18797e3ee6c

Comment 12

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

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.

Comment 13

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/b18797e3ee6c

Comment 14

[Alex Keybl [:akeybl]]

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.

Comment 15

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

https://hg.mozilla.org/releases/mozilla-aurora/rev/5f3131039216