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.

Chrome design is the solution ! What a surprise. But in fact this design doesn't avoid redundancy.

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.

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

(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.

Kai, you asked for the lock icon to come back right? Well, here it is.

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.

Will this bug cover the new drag panel that was being developed in Bug 588270 or even that got WONTFIXed?

(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.

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

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.

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.

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 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 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; }

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

I'll hold off on requesting review until the Windows patch has r+.

I'll hold off on requesting review until the Windows patch has r+.

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?

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.

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.

(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 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.

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 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 on attachment 616305 [details] [diff] [review] Patch for bug v3 (Linux) > #identity-box { ... > padding: 1px; > margin: -1px; >- -moz-margin-end: 0; > } This is wrong.

Undid the change of -moz-margin-end.

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

(In reply to Frank Yan (:fryn) from comment #36) You didn't apply attachment 615870 [details] [diff] [review].

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

(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.

https://hg.mozilla.org/integration/mozilla-inbound/rev/479edc4c0af4 https://hg.mozilla.org/integration/mozilla-inbound/rev/e79686174491 https://hg.mozilla.org/integration/mozilla-inbound/rev/961ec289d615

https://hg.mozilla.org/mozilla-central/rev/479edc4c0af4 https://hg.mozilla.org/mozilla-central/rev/e79686174491 https://hg.mozilla.org/mozilla-central/rev/961ec289d615

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.

Minor UI changes can be uplifted to Aurora when they are ready. Please do not delay this again.

Is there discussion in public regarding the return of the lock icon? If so, please point me to it.

(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.

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

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

(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.

(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.

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.

Modified the following test cases: https://litmus.mozilla.org/show_test.cgi?id=16266 https://litmus.mozilla.org/show_test.cgi?id=16267 https://litmus.mozilla.org/show_test.cgi?id=16360 https://litmus.mozilla.org/show_test.cgi?id=17321 https://litmus.mozilla.org/show_test.cgi?id=15429 https://litmus.mozilla.org/show_test.cgi?id=16805 https://litmus.mozilla.org/show_test.cgi?id=16834 https://litmus.mozilla.org/show_test.cgi?id=16835 https://litmus.mozilla.org/show_test.cgi?id=16840 Waiting for a resolution on bug 748385 before modifying the following test: https://litmus.mozilla.org/show_test.cgi?id=16782 This will be tracked separately in bug 748385.

@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.

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!

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

(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.

(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"

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.

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

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.

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

(In reply to jakub.g /aka jamie g/ from comment #62) See bug 747630.