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

  • ®om says:

    On GNU/Linux, you can middle-click on the favicon for loading the url stored in your “pasteboard” (highlighting the text anywhere).

    Will this feature disappear ?

    • msujaws says:

      I never knew about this feature. Can you download a Nightly build (http://nightly.mozilla.org/) and test it out to make sure that the functionality is still there?

    • Nox says:

      Middle click still works, using latest UX nightly. The same goes for dragging the icon into the bookmarks and others, as the ‘drag data’ is still set to the URL visited.

  • John P says:

    I have two responses to this idea:

    As a user, I’m a little concerned about the lack of visibility of the greyed-out secure (but not EV) indicator. There’s very little visual distinction between a non-secure mixed https connection and a secure connection — both show https, both have a small grey icon. I can see the difference with a little effort, but it’s very hard at a glance. Minimising visual weight is all well and good, but if it’s so light that I have to concentrate to see if a site is secure, it’s a step backwards. Very few sites use EV (I can think of paypal and github amongst those I use regularly), checking many other https I use regularly is important.

    As someone involved in supporting other firefox users: We’ve been through the process of specifically teaching people not to look for a lock; that it was a blue site name they should check when accessing secure resources. Now, tada, back comes the lock in greyed out (equals unimportant) form, and the blue totally disappears. Aaaaaarrrgh… (that’s the sound of more of my dwindling supply of hair falling out)

    Could we not colour the non-EV lock blue, and preferably colour the top level domain highlighting blue too? It would provide greater continuity (something most users I know appreciate in the systems they spend the effort to engage with, and which doesn’t often seem important to designers).

  • gervmarkham says:

    Could you point me at the bug which covered this work?

  • Stephen says:

    Can you still “click into the padlock” to see the cert details?

  • beltzner says:

    I’m sad to see that we’ve gone back to a visual metaphor (the lock) that we invested several years in trying to move the web away from with good reason. As discussed on many Mozilla blogs (see http://blog.johnath.com/2007/03/21/revisiting-security-ui-part-2/ as an example) the lock provides a far greater sense of security than it actually provides, and is one of the most confused metaphors on the web, with many websites using a lock as an image on their page to imply “safety.” Further, the non-presence of an indicator as a mechanism for alerting a user as to their lack of a secure connection has been proven, time and time again, to be a user experience failure.

    That’s neither here nor there, though. It’s your responsibility as a member of the Mozilla Firefox development team to make changes, and I’m sure this one didn’t come out of pure boredom. That said, however, there’s been little to no discussion in public of this change, and the way it’s been presented doesn’t make it look like any discussion is to be had. That’s what disappoints me most. Not every change must be discussed, but ones that reverse years-long policy approaches on security and identity on the web feel like they deserve more than a “here’s the new design” blog post. The bug is mostly about implementation (as it should be, IMO!) and the security review doesn’t look like anyone actually debated the pros and cons of returning to a metaphor we quite intentionally removed.

  • ®om says:

    Another feature impacted : actually, it is possible to “move” the favicon into the bookmarks menu, into a bookmarks bar, or even into a gnome2 panel.

    If you remove the favicon, you cannot do that anymore…

  • I read some other comments about this, but there needs to be a stronger indicator when HTTPS is broken for whatever reason (e.g. a red broken padlock, a padlock overlaid by a circle with a line through it, etc.).

    All too often I have been told that a site says HTTPS so it must be secure. I’ve even been told this by a VP at a credit union (similar to a bank) and state credit union regulators. If professionals in the banking industry can get this wrong, how can we expect regular users to understand that HTTPS doesn’t necessarily mean they are safe?

    Also, the identity box needs greater distinction when secure. For instance, I’d personally prefer seeing a hybrid of the current (FF12) means of differentiating properly identified sites (green and blue background for identity box) with the new URL bar icons that replace the favicon (provided broken HTTPS was better differentiated).

    Since the favicon is on the tab bar, it makes total sense to me to eliminate the favicon from the URL bar and use that icon location to provide more visual information about the nature of the page (e.g. whether it is secured properly).

    Cheers,
    Ken Barbalace
    AMO Editor

  • John P says:

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

    The blue colour was arbitrary several years ago. It might not have any metaphorical “good” association, but it has been shipped to millions of users. No doubt many have ignored it (as they will any changes you make). Many others have been told to ignore padlocks and check for the blue text when accessing secure services they rely on. Any sudden change in this is an issue (separate from whether that design was a good one or not).

    In any case, I’m not sure much a “good” or “safe” metaphor is appropriate for the “content was retrieved over an encrypted connection” guarantee that https provides — viruses hosted on https are just as nasty as plain http.

  • zzzzz says:

    Nox :
    Middle click still works, using latest UX nightly. The same goes for dragging the icon into the bookmarks and others, as the ‘drag data’ is still set to the URL visited.

    Middle-click does not work on m-c win32 15.0a1 running on win7 x64
    tested using latest hourly based on cset:
    https://hg.mozilla.org/mozilla-central/rev/424cb3a6141b

    • msujaws says:

      Apparently that has only ever been a Linux feature and I have been told that it still works as expected.

  • […] 14 nightly removed web-sites’ favicons from the address bar, change performed with increasing security while […]

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s

What’s this?

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

meta

%d bloggers like this: