Last Comment Bug 742419 - Implement new identity block design (lighter weight with a generic icon)
: Implement new identity block design (lighter weight with a generic icon)
Status: RESOLVED FIXED
[secr:dveditz]
: addon-compat
Product: Firefox
Classification: Client Software
Component: Location Bar (show other bugs)
: Trunk
: All All
: -- enhancement with 4 votes (vote)
: Firefox 14
Assigned To: Jared Wein [:jaws] (please needinfo? me)
:
Mentors:
: 433412 (view as bug list)
Depends on: 744304 747083 747085 747087 747088 747090 747093 747608 747627 747630 747742 747977 748027 748686 748812 750106 751733
Blocks: 657442 australis-navbar 580509 667586 748385 752447
  Show dependency treegraph
 
Reported: 2012-04-04 10:00 PDT by Jared Wein [:jaws] (please needinfo? me)
Modified: 2013-09-04 12:04 PDT (History)
43 users (show)
dveditz: sec‑review+
jaws: in‑testsuite-
virgil.dicu: in‑litmus+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
verified


Attachments
New identity block design by shorlander (2.09 MB, image/png)
2012-04-04 10:03 PDT, Jared Wein [:jaws] (please needinfo? me)
no flags Details
New identity block design by shorlander (435.81 KB, image/jpeg)
2012-04-04 10:38 PDT, Stephen Horlander [:shorlander]
no flags Details
WIP of patch (Windows only) (17.65 KB, patch)
2012-04-06 22:14 PDT, Jared Wein [:jaws] (please needinfo? me)
no flags Details | Diff | Splinter Review
Patch for bug (browser/base, browser/app, Windows) (17.69 KB, patch)
2012-04-10 20:09 PDT, Jared Wein [:jaws] (please needinfo? me)
dao+bmo: review-
Details | Diff | Splinter Review
Patch for bug (Linux) (8.38 KB, patch)
2012-04-10 20:10 PDT, Jared Wein [:jaws] (please needinfo? me)
no flags Details | Diff | Splinter Review
Patch for bug (OS X) (8.88 KB, patch)
2012-04-10 20:11 PDT, Jared Wein [:jaws] (please needinfo? me)
no flags Details | Diff | Splinter Review
Patch for bug v2 (browser/base, browser/app, Windows) (17.88 KB, patch)
2012-04-11 17:02 PDT, Jared Wein [:jaws] (please needinfo? me)
dao+bmo: review-
Details | Diff | Splinter Review
Patch for bug v2 (Linux) (8.59 KB, patch)
2012-04-11 19:35 PDT, Jared Wein [:jaws] (please needinfo? me)
no flags Details | Diff | Splinter Review
Patch for bug v2 (OS X) (7.76 KB, patch)
2012-04-11 19:35 PDT, Jared Wein [:jaws] (please needinfo? me)
no flags Details | Diff | Splinter Review
Patch for bug v3 (browser/base, browser/app, Windows) (17.80 KB, patch)
2012-04-12 16:01 PDT, Jared Wein [:jaws] (please needinfo? me)
dao+bmo: review-
Details | Diff | Splinter Review
Patch for bug v4 (browser/base, browser/app, Windows) (17.69 KB, patch)
2012-04-17 14:16 PDT, Jared Wein [:jaws] (please needinfo? me)
dao+bmo: review+
Details | Diff | Splinter Review
Patch for bug v3 (Linux) (8.70 KB, patch)
2012-04-18 15:04 PDT, Jared Wein [:jaws] (please needinfo? me)
dao+bmo: review-
Details | Diff | Splinter Review
Patch for bug v3 (OS X) (8.04 KB, patch)
2012-04-18 15:05 PDT, Jared Wein [:jaws] (please needinfo? me)
fryn: review+
Details | Diff | Splinter Review
Patch for bug v4 (Linux) (8.63 KB, patch)
2012-04-18 17:01 PDT, Jared Wein [:jaws] (please needinfo? me)
ttaubert: review+
Details | Diff | Splinter Review
SSL indicators in the location bar in Firefox, Opera and Chrome (13.86 KB, image/png)
2012-07-20 07:33 PDT, jakub.g
no flags Details

Description Jared Wein [:jaws] (please needinfo? me) 2012-04-04 10:00:05 PDT
We have changed direction from bug 588270 and decided to keep a drag target in the location bar so as not to break user's muscle memory.

The attached design shows a generic icon (globe or generic page, TBD) for sites that are http and mixed-content https. The lock icon will be present for https (non-EV and EV) and the certificate's Organization will be shown for EV certificates, as is the current practice.

The hover state for the icons will have higher saturation than the non-hovered state.
Comment 1 Jared Wein [:jaws] (please needinfo? me) 2012-04-04 10:03:04 PDT
Created attachment 612239 [details]
New identity block design by shorlander
Comment 2 Guillaume C. [:ge3k0s] 2012-04-04 10:29:42 PDT
Chrome design is the solution ! What a surprise.

But in fact this design doesn't avoid redundancy.
Comment 3 David E. Ross 2012-04-04 10:33:27 PDT
Will this include eliminating the display of "favicons".  If so, why?  That is, how would end users benefit from such an elimination?  

NOTE WELL:  This bug report does NOT describe any software error that involves "some loss of functionality under specific circumstances", which is the definition of Normal Importance.  This is clearly a "equest for enhancement" and must be marked accordingly.
Comment 4 alex_mayorga 2012-04-04 10:36:46 PDT
Shouldn't https non-EV be a shade of blue to not break entirely with the current shading (http is gray, https non-EV is light blue, https EV is green)?
Comment 5 Jared Wein [:jaws] (please needinfo? me) 2012-04-04 10:38:45 PDT
(In reply to Guillaume C. [:GE3K0S] from comment #2)
> Chrome design is the solution ! What a surprise.
> 
> But in fact this design doesn't avoid redundancy.

Guillaume, the previous comment doesn't add value to the bug. Bugzilla is not a social forum, please respect that it is a tool used for people to do work.

Please see item 1. at the Bugzilla Etiquette page https://bugzilla.mozilla.org/page.cgi?id=etiquette.html if you have any questions.

(In reply to David E. Ross from comment #3)
> Will this include eliminating the display of "favicons".  If so, why?  That
> is, how would end users benefit from such an elimination?  

End-users benefit because sites that place a lock icon as their favicon can no longer trick users in to thinking there is a trusted connection between the client and server.
Comment 6 Stephen Horlander [:shorlander] 2012-04-04 10:38:48 PDT
Created attachment 612253 [details]
New identity block design by shorlander
Comment 7 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-04-04 10:43:37 PDT
Kai, you asked for the lock icon to come back right? Well, here it is.
Comment 8 Guillaume C. [:ge3k0s] 2012-04-04 11:11:19 PDT
Generic page doesn't make sense to me. Users could think it is some sort of document. The globe (as Chrome does) is better (that what I meant in the previous comment) and represents well the web.
Comment 9 Siddhartha Dugar [:sdrocking] 2012-04-04 12:44:40 PDT
Will this bug cover the new drag panel that was being developed in Bug 588270 or even that got WONTFIXed?
Comment 10 Jared Wein [:jaws] (please needinfo? me) 2012-04-04 13:03:00 PDT
(In reply to Siddhartha Dugar [:sdrocking] from comment #9)
> Will this bug cover the new drag panel that was being developed in Bug
> 588270 or even that got WONTFIXed?

That work is being handled in bug 742441.
Comment 11 Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]] 2012-04-04 14:26:03 PDT
lets try a discussion by mail first to see if this rises to the level of a needed review starting off with the following: dveditz, jesse, johnath, kai engert, sid, bsmith

dveditz will handle this
Comment 12 patrickjdempsey 2012-04-04 22:08:48 PDT
If the lock icon is coming back, any chance of also reviving the broken lock icon (maybe in red) to indicate sites with broken or partial encryption?  This IMO is an important security indicator that has simply been missing from Firefox since 4.0.
Comment 13 Jared Wein [:jaws] (please needinfo? me) 2012-04-06 22:14:50 PDT
Created attachment 613070 [details] [diff] [review]
WIP of patch (Windows only)

This implements most of the feature for Windows. Still left is the coloring of the scheme for SSL+EV and OS X, Linux theme changes.
Comment 14 Jared Wein [:jaws] (please needinfo? me) 2012-04-10 20:09:50 PDT
Created attachment 613857 [details] [diff] [review]
Patch for bug (browser/base, browser/app, Windows)

This implements the design but doesn't implement the coloring of https in the SSL+EV case.

I think we should push that work to a follow-up bug since it seems non-trivial to introduce a third color for the URL.
Comment 15 Jared Wein [:jaws] (please needinfo? me) 2012-04-10 20:10:35 PDT
Created attachment 613858 [details] [diff] [review]
Patch for bug (Linux)
Comment 16 Jared Wein [:jaws] (please needinfo? me) 2012-04-10 20:11:26 PDT
Created attachment 613859 [details] [diff] [review]
Patch for bug (OS X)
Comment 17 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-04-10 20:29:34 PDT
I think the proposed design looks really good.

I do think the difference between HTTP and HTTPS is not clear enough, especially in the non-EV case. It is better to highlight the "https" the same regardless of EV vs non-EV, as long as there isn't a cert error for the site. The difference between HTTP and HTTPS is *much* more important to convey than the difference between EV and non-EV--take google.com and facebook.com as examples.

The distinction between bad SSL (mixed content, etc.) and good SSL is *way* too subtle.

(In reply to Jared Wein [:jaws] from comment #14)
> This implements the design but doesn't implement the coloring of https in
> the SSL+EV case.
> 
> I think we should push that work to a follow-up bug since it seems
> non-trivial to introduce a third color for the URL.

I suggest that we make black the new green until the green coloring can be added. (That is, for now, show "https" in black for non-mixed, non-override sites, and show "https" in gray for mixed or override or cert error sites, and show "http" in gray.")

Again, as far as the user is concerned, if they care at all about this stuff, then they mostly will care about the distinction between "HTTPS with no problems" vs. something worse, and not the more subtle matters like EV vs DV.
Comment 18 Dão Gottwald [:dao] 2012-04-11 02:03:46 PDT
Comment on attachment 613857 [details] [diff] [review]
Patch for bug (browser/base, browser/app, Windows)

>   onLinkIconAvailable: function (aIconURL) {
>-    if (gProxyFavIcon && gBrowser.userTypedValue === null)
>-      PageProxySetIcon(aIconURL); // update the favicon in the URL bar
>+    // Do nothing.
>   },

remove method

> #identity-box.verifiedDomain {
>-  background-image: -moz-linear-gradient(hsl(215,60%,92%), hsl(215,58%,88%));
>-  box-shadow: 0 1px 0 hsla(215,54%,33%,.05) inset;
>-  -moz-border-end-color: hsla(215,54%,33%,.2);
>   color: hsl(215,54%,33%);
> }

You're removing the hardcoded background color while keeping the custom text color, which means that the text isn't guaranteed to be visible.

>+  list-style-image: url(chrome://browser/skin/http.png);

This file name is a lie, we support more protocols than just http.

>+#identity-box:hover > #identity-box-inner > #page-proxy-stack > #page-proxy-favicon,
>+#identity-box[open=true] > #identity-box-inner > #page-proxy-stack > #page-proxy-favicon {
>+  opacity: 1;
>+}

#identity-box:not(:hover):not([open=true]) > #identity-box-inner > #page-proxy-stack > #page-proxy-favicon {
  opacity: 0.8;
}
Comment 19 Jared Wein [:jaws] (please needinfo? me) 2012-04-11 17:02:39 PDT
Created attachment 614227 [details] [diff] [review]
Patch for bug v2 (browser/base, browser/app, Windows)

Updated to use the new graphics and remove the opacity changes that are no longer necessary since we have different graphics for the normal, hover, and active states. Also addressed other feedback.
Comment 20 Jared Wein [:jaws] (please needinfo? me) 2012-04-11 17:42:06 PDT
Comment on attachment 614227 [details] [diff] [review]
Patch for bug v2 (browser/base, browser/app, Windows)

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

::: browser/themes/winstripe/jar.mn
@@ +37,5 @@
>          skin/classic/browser/reload-stop-go.png
>          skin/classic/browser/Secure24.png                            (Secure24.png)
> +        skin/classic/browser/identity-icons-generic.png
> +        skin/classic/browser/identity-icons-https.png
> +        skin/classic/browser/identity-icons-https-ev.png

I forgot to move these (and the ones below) to be in correct alphabetical order. I can do that in either the next revision or before I land.
Comment 21 Jared Wein [:jaws] (please needinfo? me) 2012-04-11 19:35:04 PDT
Created attachment 614257 [details] [diff] [review]
Patch for bug v2 (Linux)

I'll hold off on requesting review until the Windows patch has r+.
Comment 22 Jared Wein [:jaws] (please needinfo? me) 2012-04-11 19:35:50 PDT
Created attachment 614258 [details] [diff] [review]
Patch for bug v2 (OS X)

I'll hold off on requesting review until the Windows patch has r+.
Comment 23 Dão Gottwald [:dao] 2012-04-12 06:18:24 PDT
Comment on attachment 614227 [details] [diff] [review]
Patch for bug v2 (browser/base, browser/app, Windows)

> #identity-box {
>-  background-image: -moz-linear-gradient(hsl(0,0%,98%), hsl(0,0%,92%));
>-  box-shadow: 0 1px 0 hsla(0,0%,0%,.05) inset;
>-  -moz-border-end: 1px solid hsla(0,0%,0%,.1);
>   padding: 2px;
>+  background-color: #fff;
> }

We only need the background color when the identity box has a label. Also, when it doesn't have a label, can we reduce the space between the icon and the location bar value?

>-}
>-
>+}
>+

Are you removing CRs here or are you adding them?
Comment 24 Jared Wein [:jaws] (please needinfo? me) 2012-04-12 16:01:32 PDT
Created attachment 614595 [details] [diff] [review]
Patch for bug v3 (browser/base, browser/app, Windows)

I kept the background-color on the #identity-box because I don't think it will look good if the background color changes to white when users visit an HTTPS or HTTPS+EV site. Keeping the background-color for all #identity-box styling keeps it looking good even when users change browser.identity.ssl_domain_display.

I removed some of the end padding on the proxy icon so the URL is closer to the icon, and put the padding (and the end-border) on the #identity-icon-labels so that it only appears when the labels are visible. This also has a nice side-effect that the border isn't the full height of the location bar, which fits the design in the mockup closer.

Sorry about the CRs. I've removed them from this patch.
Comment 25 David E. Ross 2012-04-14 11:22:43 PDT
Two unrelated comments -- 

1.  The background color for various levels of secure Web sites should remain settable by users in userChrome.css, overriding the colors implemented in this bug.  To some extent, this would at least provide a work-around for bug #657442 for color-blind users.  

2.  Re the second part of comment #5:  Those users who look for the lock icon do so in the status bar, which still exists in SeaMonkey.  A lock icon on a Web page (e.g., next to the logon area for a bank's Web page, which I actually saw) or in the address area (URI bar) should always be ignored.  I have put considerable effort into creating seven distinct icons (no locks) for my various Web pages.  Icons have also been developed for various commercial Web sites, reflecting the companies' trademarks.  Even bugzilla.mozilla.org has its own favicon.ico.  This RFE would negate all that.
Comment 26 Daniel 2012-04-14 13:53:05 PDT
(In reply to David E. Ross from comment #25)
> Icons have also been developed for various
> commercial Web sites, reflecting the companies' trademarks.  Even
> bugzilla.mozilla.org has its own favicon.ico.  This RFE would negate all
> that.

The favicon is still visible on the tab, if I am not mistaken
Comment 27 Dão Gottwald [:dao] 2012-04-14 20:42:04 PDT
Comment on attachment 614595 [details] [diff] [review]
Patch for bug v3 (browser/base, browser/app, Windows)

(In reply to Jared Wein [:jaws] from comment #24)
> I kept the background-color on the #identity-box because I don't think it
> will look good if the background color changes to white when users visit an
> HTTPS or HTTPS+EV site.

Not sure what exactly you mean here.

> Keeping the background-color for all #identity-box
> styling keeps it looking good even when users change
> browser.identity.ssl_domain_display.

We can remove that pref if it helps.

> I removed some of the end padding on the proxy icon so the URL is closer to
> the icon,

Unfortunately, since you didn't remove the white background, this puts the icon too close to the imaginary border between the white and the transparent part of the location bar. Enable tabs on top with aero glass or use a lightweight theme to see this.
Comment 28 Jared Wein [:jaws] (please needinfo? me) 2012-04-17 14:16:29 PDT
Created attachment 615870 [details] [diff] [review]
Patch for bug v4 (browser/base, browser/app, Windows)

Thanks for the feedback. I've made the requested changes.

I think we can leave browser.identity.ssl_domain_display unchanged as long as we are OK with using the inherited color for verifiedDomain.
Comment 29 Dão Gottwald [:dao] 2012-04-18 00:23:58 PDT
Comment on attachment 615870 [details] [diff] [review]
Patch for bug v4 (browser/base, browser/app, Windows)

> #page-proxy-favicon {
>   width: 16px;
>   height: 16px;
>   margin: 1px 4px;
>+  -moz-margin-end: 0;

margin-top: 1px;
margin-bottom: 1px;
-moz-margin-start: 4px;
-moz-margin-end: 0;

in browser.xul, remove validate="never" and onerror="this.removeAttribute('src');"
Comment 30 Jared Wein [:jaws] (please needinfo? me) 2012-04-18 15:04:51 PDT
Created attachment 616305 [details] [diff] [review]
Patch for bug v3 (Linux)
Comment 31 Jared Wein [:jaws] (please needinfo? me) 2012-04-18 15:05:34 PDT
Created attachment 616307 [details] [diff] [review]
Patch for bug v3 (OS X)
Comment 32 Dão Gottwald [:dao] 2012-04-18 15:49:39 PDT
Comment on attachment 616305 [details] [diff] [review]
Patch for bug v3 (Linux)

> #identity-box {
...
>   padding: 1px;
>   margin: -1px;
>-  -moz-margin-end: 0;
> }

This is wrong.
Comment 33 Jared Wein [:jaws] (please needinfo? me) 2012-04-18 17:01:19 PDT
Created attachment 616361 [details] [diff] [review]
Patch for bug v4 (Linux)

Undid the change of -moz-margin-end.
Comment 34 Daniel Veditz [:dveditz] 2012-04-18 19:22:57 PDT
In the security review we discussed having a separate warning-ish icon for the mixed-content case. That would seem to make bug 515562 obsolete, or, if you need a separate bug to track doing that after the initial landing perhaps you can morph bug 515562 (complete with CC list of interested people) into what we actually plan on doing.
Comment 35 :Felipe Gomes (needinfo me!) 2012-04-19 15:27:12 PDT
Comment on attachment 616307 [details] [diff] [review]
Patch for bug v3 (OS X)

Frank could also do this review if he gets to it earlier
Comment 36 Frank Yan (:fryn) 2012-04-20 02:47:44 PDT
Comment on attachment 616307 [details] [diff] [review]
Patch for bug v3 (OS X)

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

Thanks for writing a patch! :)

::: browser/themes/pinstripe/browser.css
@@ +1029,2 @@
>    color: hsl(92,100%,20%);
> +  -moz-border-end: 1px solid hsla(92,81%,16%,.1);

This doesn't match Stephen's mockup: https://people.mozilla.com/~fyan/identity-block/verifiedIdentity.png

To match the mockup's separator, we could use a 1px-wide vertical linear gradient on the right side of the #identity-box. The text styling of the identity block also doesn't match.

We need to hide the domain name for pages without EV to avoid the following: https://people.mozilla.com/~fyan/identity-block/noEV.png

@@ +1085,5 @@
>    width: 16px;
>    height: 16px;
>    margin: 0px;
>    padding: 0px;
> +  list-style-image: url(chrome://browser/skin/identity-icons-generic.png);

This is great, but we're still duplicating the favicon between the tab and the URL bar once the page loads. We should always display a generic in the URL bar, IMHO, like the mockup illustrates (although we should leave the favicon in the tab).
Comment 37 Dão Gottwald [:dao] 2012-04-20 02:50:04 PDT
(In reply to Frank Yan (:fryn) from comment #36)
You didn't apply attachment 615870 [details] [diff] [review].
Comment 38 Frank Yan (:fryn) 2012-04-20 03:00:36 PDT
Comment on attachment 615870 [details] [diff] [review]
Patch for bug v4 (browser/base, browser/app, Windows)

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

::: browser/base/content/browser.js
@@ -2684,3 @@
>    } else if (aState == "invalid") {
>      gURLBar.removeEventListener("input", UpdatePageProxyState, false);
>      PageProxyClearIcon();

Please remove this line, since PageProxyClearIcon no longer exists.
Comment 39 Frank Yan (:fryn) 2012-04-20 03:03:11 PDT
Comment on attachment 616307 [details] [diff] [review]
Patch for bug v3 (OS X)

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

(In reply to Dão Gottwald [:dao] from comment #37)
> (In reply to Frank Yan (:fryn) from comment #36)
> You didn't apply attachment 615870 [details] [diff] [review].

Ah, that makes more sense. :P
That voids all my concerns, except for the identity block text & border styling, but I won't have that block this from landing.
Please file a followup for matching the identity block text & border styling of Stephen's design.
Comment 40 Tim Taubert [:ttaubert] 2012-04-20 13:58:52 PDT
Comment on attachment 616361 [details] [diff] [review]
Patch for bug v4 (Linux)

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

Nice work. The only thing I noticed that doesn't match shorlander's design is that the "https://" font color is not green for https-ev pages. I think that shouldn't block and we can handle this as a follow-up.
Comment 41 Jared Wein [:jaws] (please needinfo? me) 2012-04-20 22:17:11 PDT
(In reply to Tim Taubert [:ttaubert] from comment #40)
> The only thing I noticed that doesn't match shorlander's design
> is that the "https://" font color is not green for https-ev pages. I think
> that shouldn't block and we can handle this as a follow-up.

This is bug 747085. There are a number of bugs that were filed as part of the security review. I've marked them as blocking this bug.
Comment 44 Marco Castelluccio [:marco] 2012-04-22 04:00:27 PDT
Probably we should back this out from 14 until the follow-ups are resolved (or backport them in 14), otherwise user will experience two behaviour changes in 14 and 15.
Comment 45 Siddhartha Dugar [:sdrocking] 2012-04-22 04:30:16 PDT
Minor UI changes can be uplifted to Aurora when they are ready. Please do not delay this again.
Comment 46 Gen Kanai [:gen] 2012-04-23 16:15:02 PDT
Is there discussion in public regarding the return of the lock icon? If so, please point me to it.
Comment 47 Jared Wein [:jaws] (please needinfo? me) 2012-04-24 06:28:50 PDT
(In reply to Gen Kanai [:gen] from comment #46)
> Is there discussion in public regarding the return of the lock icon? If so,
> please point me to it.

Bug 744304 was for the publicly-accessible security review, and https://wiki.mozilla.org/Security/Reviews/IdentityBox is a link to the notes of the security review.
Comment 48 Mike Beltzner [:beltzner, not reading bugmail] 2012-04-24 06:56:18 PDT
(In reply to Gen Kanai [:gen] from comment #46)
> Is there discussion in public regarding the return of the lock icon? If so,
> please point me to it.

There is now: https://groups.google.com/d/topic/mozilla.dev.apps.firefox/ODX1PJutsLM/discussion

(I encourage everyone to keep design debate to the discussion forums, bugs are for implementation debate!)
Comment 49 Jared Wein [:jaws] (please needinfo? me) 2012-04-24 11:33:23 PDT
addon-compat keyword added because:
Some addons use the PageProxySetIcon function to change the favicon in the address bar. This function is now missing and addons will have to use a different method (such as setting an attribute on #page-proxy-favicon and using CSS to change the icon in the address bar).
Comment 50 Dão Gottwald [:dao] 2012-04-24 11:36:25 PDT
(In reply to Jared Wein [:jaws] from comment #49)
> This function is now missing and addons will have to use a
> different method (such as setting an attribute on #page-proxy-favicon and
> using CSS to change the icon in the address bar).

Please don't make such blanket suggestions to add-on authors. I suspect that many add-ons currently modifying the favicon should just stop doing this rather than finding a new way.
Comment 51 Frank Yan (:fryn) 2012-04-24 11:42:38 PDT
(In reply to Dão Gottwald [:dao] from comment #50)
> (In reply to Jared Wein [:jaws] from comment #49)
> > This function is now missing and addons will have to use a
> > different method (such as setting an attribute on #page-proxy-favicon and
> > using CSS to change the icon in the address bar).
> 
> Please don't make such blanket suggestions to add-on authors. I suspect that
> many add-ons currently modifying the favicon should just stop doing this
> rather than finding a new way.

I agree with Dão here.
If we need to ensure that an add-on's primary functionality doesn't break because the removed function causes the add-on's code to throw an error and stop execution, then we can make the function a blank one that calls Cu.reportError with a brief explanation or something.
I only recommend this path if there are critical add-ons that have this problem that cannot be updated my the vast majority of their users in time, e.g. possibly the official Twitter add-on.
Comment 52 Henrik Skupin (:whimboo) 2012-04-26 03:02:31 PDT
in-litmus- is not correct at this time because we already have Litmus tests available. The removal of the favicon in the locationbar makes some of those invalid. So those need an update. Means I flag it for updates.
Comment 54 Alexei Lerner [:olexijl] 2012-04-26 08:55:35 PDT
@Jared Wein: I am currently thinking, that this is not a bug either.

However: I would like to reenable favicons in the awesome bar as some kind of setting in "options" menu.

Is it possible to disable/reenable the new design in form of setting? It would be nice if the "old style" could be recovered in case.
Comment 55 Nigel 2012-05-03 09:48:34 PDT
I do not believe that the removal of the background colour and the change to a green font to identify Extended SSL sites is a benefit - I think its a change for the worse and more to the point visually impaired users would not always see the colour change or obviously distinguish a safe site compared to an unsafe site potentially.

Showing a green highlighted bar as was introduced with Firefox 4 should be the way that Firefox carries on - as it makes it obvious when a site is using extended SSL as you can see by a lot of colour.  on my screen the green and black for the URL are almost identical!
Comment 56 Nigel 2012-05-03 09:56:48 PDT
As an additional bit of information - the idea of saying that the Awesome bar turns green has been the "selling" method of getting sites to take extended SSL certificates rather than standard SSL certificates.

You need something OBVIOUS as to the site is using Extended SSL and not something buried in the URL itself.  Following Chrome IMHO is wrong because Google at the moment on their web sites only use Standard SSL certificates, and possibly thats the reason why they in Chrome have downplayed whether a site is using Extended or Standard SSL certificates.

This solution is simply a change that needs to be reversed ASAP
Comment 57 Brian Smith (:briansmith, :bsmith, use NEEDINFO?) 2012-05-03 10:43:01 PDT
(In reply to Nigel from comment #55)
> visually impaired users would not always see the colour change 

The difference between EV and non-EV is:

  * EV certs show the company's name; non-EV certs don't
  * EV does (or will) use green in places non-EV uses black or gray

So, people who cannot distinguish color differences can still see the difference. (FWIW, I would rather we remove the second difference and use a green lock and green "https" for non-EV certs too.)

> You need something OBVIOUS as to the site is using Extended SSL and not
> something buried in the URL itself.  Following Chrome IMHO is wrong because
> Google at the moment on their web sites only use Standard SSL certificates,
> and possibly thats the reason why they in Chrome have downplayed whether a
> site is using Extended or Standard SSL certificates.

Chrome's design for EV is much more like Firefox's old design because it uses a green background color. Our new design definitely looks much better than Chrome.

Also, precisely because Google, Facebook, and other MAJOR websites don't use EV certificates, and are unlikely to EVER use EV certificates (AFAICT), it is actually better to de-emphasize the EV vs. non-EV distinction in the UI. It is misleading to make https://twitter.com look "more secure" than https://google.com.

There is at least one thread in mozilla.dev.security.policy that discusses this, including why some major websites avoid EV certificates, where this issue is touched upon in a little more detail. I think it would be better to discuss the issue on mozilla.dev.security.policy or whatever the UI mailing list (newsgroup) is, than discussing it here in this bug, especially because this bug has already been RESOLVED: FIXED.
Comment 58 Nigel 2012-05-03 22:45:19 PDT
(In reply to Brian Smith (:bsmith) from comment #57)
> (In reply to Nigel from comment #55)
> > visually impaired users would not always see the colour change 
> 
> The difference between EV and non-EV is:
> 
>   * EV certs show the company's name; non-EV certs don't
>   * EV does (or will) use green in places non-EV uses black or gray
> 
> So, people who cannot distinguish color differences can still see the
> difference. (FWIW, I would rather we remove the second difference and use a
> green lock and green "https" for non-EV certs too.)
> 
> > You need something OBVIOUS as to the site is using Extended SSL and not
> > something buried in the URL itself.  Following Chrome IMHO is wrong because
> > Google at the moment on their web sites only use Standard SSL certificates,
> > and possibly thats the reason why they in Chrome have downplayed whether a
> > site is using Extended or Standard SSL certificates.
> 
> Chrome's design for EV is much more like Firefox's old design because it
> uses a green background color. Our new design definitely looks much better
> than Chrome.
> 
> Also, precisely because Google, Facebook, and other MAJOR websites don't use
> EV certificates, and are unlikely to EVER use EV certificates (AFAICT), it
> is actually better to de-emphasize the EV vs. non-EV distinction in the UI.
> It is misleading to make https://twitter.com look "more secure" than
> https://google.com.
> 
> There is at least one thread in mozilla.dev.security.policy that discusses
> this, including why some major websites avoid EV certificates, where this
> issue is touched upon in a little more detail. I think it would be better to
> discuss the issue on mozilla.dev.security.policy or whatever the UI mailing
> list (newsgroup) is, than discussing it here in this bug, especially because
> this bug has already been RESOLVED: FIXED.

Having spoken to various UK Government departments I have been lead to believe that the situation is as follows

If a site does not use extended SSL certificates and someone creates a site looking like the original site and people pass information to them, then if the organisation is a large one, such as a bank, google or facebook, then the UK authorities will regard that company as being equally responsible for the customer loosing the data as the fraudsters themselves.

Additionally Firefox made a big play with Firefox 4 to both distinguish between sites with and without extended SSL and when one is getting large UK and overseas companies to change and they put out statements such as "the latest versions of Internet Explorer, Google Chrome and Firefox notify you when you are in a secured session (https://) by indicating with a green highlighted URL or a Padlock icon on the address bar.  If you do not see either Do Not Proceed"
Comment 59 Nigel 2012-05-04 08:47:52 PDT
The play in comment 58 - was on 25 August 2011 where Firefox advertised to signed up users how you were going to make the user experience better and safer.  Is it really correct to make such a fundamental change (not the ICON), but the highlighting of the sites with Extended SSL less than a year later?  Its advertised quite visibly as a big benefit/feature on the Firefox web page and I do not believe that this is correct.  Have looked at the security review for this change, and what is described as the objective - was to remove the favicon was all that was stated - not changing how Extended SSL will be shown.
Comment 60 Dão Gottwald [:dao] 2012-06-21 05:04:11 PDT
*** Bug 433412 has been marked as a duplicate of this bug. ***
Comment 61 Virgil Dicu [:virgil] [QA] 2012-07-04 02:36:09 PDT
Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0

Site identity displayed as follows in F14 beta 10 (Mac OS 10.6, Ubuntu 12.04, Windows 7):
-grey globe icon and grey Larry for untrusted sites (no identity information)
-grey lock icon and blue Larry for sites with basic identity information
-green lock icon and green Larry for sites with complete identity information
Comment 62 jakub.g 2012-07-20 07:33:08 PDT
Created attachment 644321 [details]
SSL indicators in the location bar in Firefox, Opera and Chrome

First, good that the favicon removal from URL bar landed in Fx14 ( I'm not a security expert and I was a bit surprised by that, until I've read the literature, namely http://www.slideshare.net/SecurityTube.Net/black-hat-dc-09-marlinspike-defeating-ssl  - a must-read about SSL by the way; opened my eyes). 

However, I'm surprised why you stick with the white background color? 

Please compare [attachment] the SSL indicators in Fx, Chrome and Opera. Is there any good reason to have the white bg other than and "because it looks nice"? IMHO, the box with distinct background color automatically gets user's attention. 

In fact, in this respect, Chrome's and Firefox's implementations seems best to me from security point of view [always display 'https' + the name of the site owner], while Opera's from the visual POV [colors].

Positive feedback is important and should be clearly visible. Colors carry a lot of information and attract attention. In fact I'm a keen follower of highlighting the whole location bar on SSL pages, but as it was dropped in Firefox 3, I don't expect Mozilla is going to reconsider it...

Just my 2 cents.
Comment 63 Nigel 2012-07-21 01:01:22 PDT
Personal opinion as said previously this change is wrong and it needs to be reversed, however as the UI team have made this change to look like Chrome the question has to be should we not move over to Chrome as Mozilla seems not to care about user security - they hyped the original change only last year (August) and now are changing it again
Comment 64 Marco Castelluccio [:marco] 2012-07-21 02:31:33 PDT
(In reply to jakub.g /aka jamie g/ from comment #62)

See bug 747630.

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