Last Comment Bug 755429 - Mixed content icon draws too much attention
: Mixed content icon draws too much attention
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: Theme (show other bugs)
: 15 Branch
: All All
: -- normal with 1 vote (vote)
: Firefox 15
Assigned To: Jared Wein [:jaws] (please needinfo? me)
:
Mentors:
Depends on:
Blocks: 747090
  Show dependency treegraph
 
Reported: 2012-05-15 11:49 PDT by Paul O'Shannessy [:zpao] (not reading much bugmail, email directly)
Modified: 2012-05-30 14:10 PDT (History)
13 users (show)
jaws: in‑testsuite-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed


Attachments
Chrome.png (18.07 KB, image/png)
2012-05-17 09:14 PDT, Virtual_ManPL [:Virtual] - (ni? me)
no flags Details
Grey /!\ icon (46.16 KB, image/png)
2012-05-17 15:04 PDT, Justin Dolske [:Dolske]
no flags Details
Plain SSL vs Mixed SSL in FF12 (38.58 KB, image/png)
2012-05-17 15:07 PDT, Justin Dolske [:Dolske]
no flags Details
Comparison of Firefox & Chrome & Opera.png (198.93 KB, image/png)
2012-05-18 00:15 PDT, Virtual_ManPL [:Virtual] - (ni? me)
no flags Details
Patch for bug (4.73 KB, patch)
2012-05-29 13:17 PDT, Jared Wein [:jaws] (please needinfo? me)
dolske: review+
Details | Diff | Splinter Review
Patch for bug v2 (2.79 KB, patch)
2012-05-29 13:54 PDT, Jared Wein [:jaws] (please needinfo? me)
dolske: review+
akeybl: approval‑mozilla‑aurora+
Details | Diff | Splinter Review

Description Paul O'Shannessy [:zpao] (not reading much bugmail, email directly) 2012-05-15 11:49:47 PDT
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] - (ni? me) 2012-05-17 09:14:11 PDT
Created attachment 624770 [details]
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] 2012-05-17 15:01:46 PDT
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] 2012-05-17 15:04:48 PDT
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.
Comment 4 Justin Dolske [:Dolske] 2012-05-17 15:07:23 PDT
Created attachment 624915 [details]
Plain SSL vs Mixed SSL in FF12

(And just for reference, this is what Firefox 12 shows today)
Comment 5 Virtual_ManPL [:Virtual] - (ni? me) 2012-05-18 00:15:02 PDT
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:
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] 2012-05-22 13:08:07 PDT
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) 2012-05-29 13:17:16 PDT
Created attachment 628083 [details] [diff] [review]
Patch for bug

This patch changes the warning triangles to grayscale.
Comment 8 Justin Dolske [:Dolske] 2012-05-29 13:21:25 PDT
Comment on attachment 628083 [details] [diff] [review]
Patch for bug

I love reviewing base64.
Comment 9 Jared Wein [:jaws] (please needinfo? me) 2012-05-29 13:54:20 PDT
Created attachment 628099 [details] [diff] [review]
Patch for bug v2

Another base64 review, this time with updated icons from Stephen :)
Comment 10 Justin Dolske [:Dolske] 2012-05-29 13:58:43 PDT
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) 2012-05-29 14:02:16 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/b18797e3ee6c
Comment 12 Jared Wein [:jaws] (please needinfo? me) 2012-05-29 14:09:13 PDT
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] 2012-05-30 07:43:42 PDT
https://hg.mozilla.org/mozilla-central/rev/b18797e3ee6c
Comment 14 Alex Keybl [:akeybl] 2012-05-30 13:41:47 PDT
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) 2012-05-30 14:10:58 PDT
https://hg.mozilla.org/releases/mozilla-aurora/rev/5f3131039216

Note You need to log in before you can comment on or make changes to this bug.