An update to site-identity in desktop Firefox

23 April, 2012 § 61 Comments

Update (24 April): For clarification, there are no plans to remove favicons from tabs, bookmarks, or Awesomebar suggestions.

Starting with yesterday’s Nightly build of Firefox, we have introduced a change to how we display site-identity in the address bar. These changes are intended to increase the security of our users as well as reduce some visual weight.

Since the dawn of time, we have included the site favicon in the address bar as part of the site-identity block. While the favicon can represent a piece of a site’s identity, there are some sites that set their favicon to a padlock. This behavior can trick users in to thinking that a site is using a secure connection when on an unsecured connection. Starting with yesterdays’s Nightly, we will no longer include the favicon in the address bar.

Websites that use SSL certificates with Extended Validation will now have a green padlock next to the certificate owner’s organization name.

Websites that use SSL certificates without Extended Validation will now have a grey padlock. The effective hostname will no longer appear next to the padlock. This information is redundant with our darkening of the effective hostname in the website address.

Websites that do not use SSL certificates or have mixed-content will fallback to a globe icon.

These changes are planned to reach our Release channel in mid-July.

Tagged: , ,

§ 61 Responses to An update to site-identity in desktop Firefox

  • Now if Chrome developers had explained things like that, maybe I wouldn’t have been as eager to switch to Firefox as soon as it got leaner. Thanks.

    …though, I still have yet to see a justifiable explanation for breaking cut-and-paste WYSIWYG-ness and de-emphasizing the intuitive importance of including http:// in href/src attributes by following Chrome’s decision to hide the “http://” in non-mobile, non-IE9 address bars where there’s plenty of room for it.

    (I can see hiding it only when the address bar has no focus to emphasize the relevant bits and pave the way for that proposed styling change that puts the domain in a colored box, but not also when it has focus.)

    • msujaws says:

      Hiding http:// can make it a lot easier for users to distinguish between secure and non-secure connections. Instead of hunting for a single ‘s’ at the end of ‘http’, users can see that the protocol is present and know that they are on a secure connection.

    • msujaws :
      Hiding http:// can make it a lot easier for users to distinguish between secure and non-secure connections. Instead of hunting for a single ‘s’ at the end of ‘http’, users can see that the protocol is present and know that they are on a secure connection.

      Ok, that at least has somewhat valid reasoning behind it, but it still makes things much more complex and error prone than just replacing the favicon with either a globe or a lock like you guys are planning and (I think) Chrome was already doing by the time they made this change. (Not to mention, protocol icons are more visually distinct and intuitive than asking people to check whether there’s an https:// before http://www.likely-wifi-phishing-target.com)

      Also, I know it’s not representative, but everyone even mildly skilled that I’ve talked to asked me to re-enable display of “http://” when I informed them that there was a hidden switch to do so. (If for no other reason than because it made sure that what they selected was what actually appeared on the clipboard)

      Chrome actually had to temporarily disable that feature after their initial attempt to enable it because of all the interaction bugs it caused. (And I actually found some people who interpreted it as a browser bug because the browser “sometimes showed the http:// and sometimes didn’t”)

      (The unskilled users I checked with were just confused by the change and wouldn’t know what a URI scheme is in the first place, let alone how to check one or why it’s important.)

    • msujaws says:

      On the other hand, there are users that don’t understand what ‘http://’ is, and yet they struggle trying to type out ‘http://’ each time they want to view a website when it’s completely unnecessary since HTTP is the default scheme. I hope that this will show them that they can type just ‘cnn.com’ or ‘facebook.com’ in their address bar.

    • Lozzy says:

      msujaws :
      Hiding http:// can make it a lot easier for users to distinguish between secure and non-secure connections. Instead of hunting for a single ‘s’ at the end of ‘http’, users can see that the protocol is present and know that they are on a secure connection.

      I think the point was that we should have the full url appear on focus. Opera has done the right thing here in my mind, and I see no reason not to follow their lead.

      I’m going to miss the old good looking site identity block ;(

  • Anonymous says:

    What about the idea of visibly crossing out the “https://” when mixed-content or otherwise insecure, as Chrome does?

    Also, what happened to the UX plan proposed a while back that would have used the site identity block in place of the hostname?

    • msujaws says:

      Visibly crossing out ‘https://’ can be confusing because it combines something good (https://) with something bad (the strikethrough). This mixed message can be confusing, so we’d rather just treat the page as a regular HTTP connection since the privacy of the communications is no longer guaranteed.

  • That’s what I was thinking of. Replacing the hostname with the site identity block. Thanks, Anon.

    If it changes back to visibly displaying a full, valid URL (including http://) when the address bar has focus, I’m all for it. Otherwise, I’ll be out searching yet again for extensions and about:config tweaks to undo the change. (Usually easier to find than the ideal blend of both ways)

    • msujaws says:

      Replacing the hostname with the site-identity block introduces some awkward UI paradigms as well as being technically complex to implement. For instance, if a user gives focus to the address bar then the button affordance on the hostname should disappear since the input is now editable text. If the user clicks on the hostname, then they will not be able to start a selection since the button’s action will be performed. If the user drags the identity block to create a shortcut, then it may appear that the shortcut will only link to the hostname instead of the full URL.

      These issues are enough for us to decide to delay implementing the combined site-identity hostname feature. If we are able to find a good way to handle these three issues and other ones that people have come up with, then we may revisit it.

  • Does the favicon still appear on the tab? Why was a relocation (to avoid confusion with security assertions) not considered—or, if it was, why was it rejected?

    • msujaws says:

      The favicon still appears on the tab and in the Awesomebar suggestions. In terms of a relocation, we have tried having a secure identifier located on the other side of the address bar, but leaving the favicon in the address bar at any location will still provide the opportunity to confuse and trick users who don’t understand that a lock should only appear in a specific location.

  • matro says:

    Killing the favicon is great news, very glad to hear this is happening!

    Whatever happens, I’m in firm agreement with this:

    Stephan Sokolow :
    If it changes back to visibly displaying a full, valid URL (including http://) when the address bar has focus, I’m all for it. Otherwise, I’ll be out searching yet again for extensions and about:config tweaks to undo the change. (Usually easier to find than the ideal blend of both ways)

    The user should always, absolutely, and easily be able to select and copy the full, valid URL. Hiding or removing that ability would be a sin comparable to turning off view:source.

    And I have to agree with Stephan about hiding the protocol string; this is a bad, bad idea. Every justification I’ve heard for this basically boils down to “it’s unnecessary cruft” and “most users don’t know what it means”. To the former is obviously false, as “http://” is just as relevant to how a URL as “https://” or “ftp://”. To the latter, if someone doesn’t know what a thing is, hiding from them is probably the worst thing one can do to help them learn.

    Instead, let’s garnish and progressively enhance the heck out of the full, truthful URL string; turn it into a learning opportunity for users who aren’t URL-savvy but are inquisitive enough to click on the identity block in the first place, and provide useful information and functionality to those who are. Don’t be hidin’ the truth, yo.

    I really like the idea of refactoring the identity block to wrap around the hostname as well. More generally speaking, it’d be great to see more overloading/enhancing of the URL as a whole, not just the hostname. For example, taking a hint from http://en.design-noir.de/mozilla/locationbar2/ and making segments of a URL clickable links (if a modifier key is pressed) would be pretty neat as well.

  • Jick says:

    My only question is related to this:

    Websites that do not use SSL certificates or have mixed-content will fallback to a globe icon.

    Why display the globe icon? Why not just display nothing? Wouldn’t that help to reduce the “visual weight” even more? If you’re not going to display the favicon there, why display anything at all if the site doesn’t use SSL, etc?

    • msujaws says:

      We still want to provide a proxy target for users to access information about the site identity. This icon currently provides two features. Clicking on the icon will show a doorhanger that gives access to information about the current site, such as how many visits you’ve made previously and any permissions you have granted to the site. Dragging the icon allows you to create shortcuts and bookmarks. If we remove the icon we would still want to provide both of the aforementioned features, and we couldn’t come up with a simpler solution than using a generic icon.

  • This was a useful and user-friendly feature. Would it be possible for Firefox to parse and detect if the favicon is in the shape of a padlock and then do something different if that is indeed the case?

    • msujaws says:

      Trying to be too smart by doing image recognition can lead to blocking legitimate favicons, not blocking some illegitimate favicons, and would also make loading webpages slower.

  • dynamis says:

    We have intentionally removed padlock icon from Firefox 3:

    http://www.dria.org/wordpress/archives/2008/05/06/635/

    Why you use padlock icon again?
    # note: same problem for nativeui fennec

    • msujaws says:

      Unfortunately, there’s really not a better metaphor than a lock to show a secure connection, and the presence of a favicon gets abused by sites who want to trick their users.

  • Greg K Nicholson says:

    On the globe icon: the Firefox icon carefully avoided showing any real land- or sea-mass. This globe icon clearly depicts the Atlantic and neighbouring landmasses.

    Did/would you consider using a simple grid sphere? e.g. https://duckduckgo.com/?q=!i+grid+sphere

    • msujaws says:

      Hmm… we try not to show favoritism to any given hemisphere. I magnified the icon and I couldn’t see any land masses that matched anything on Earth.

  • Jean says:

    A change for the better, but I still have a few question about colors…
    What happened to the blue color to represent https non-ev connections ? I thought the color coding had replaced the lock symbol in the past ?
    Also the green color for the EV identity block is really light. I have a really bad screen at work and I’m pretty sure I wont see it at all…

    • msujaws says:

      The blue color is arbitrary and doesn’t act as a great metaphor for something that is “good” or “safe”. Since we can now differentiate based on icon instead of background color, we can now show a higher amount of information in a simpler representation.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading An update to site-identity in desktop Firefox at JAWS.

meta

Follow

Get every new post delivered to your Inbox.

Join 1,003 other followers