April 16, 2014

avatar

Firefox Changes its HTTPS User Interface… Again

A year and a half ago, I wrote about major changes to the way that Firefox indicates whether the connection to a web site is encrypted. I noted that, especially with the emergence of mobile browsers, the traditional “padlock icon” of standard SSL-secured connections and the “green glow” of Extended Validation was being implemented in varied and conflicting ways across different browsers (“Web Browser Security User Interfaces: Hard to Get Right and Increasingly Inconsistent”). For standard SSL connections, Firefox had removed the padlock icon entirely, relying instead on a “blue highlight” color. I criticized this change because it confused users and made Firefox even more atypical:

Firefox 14 shipped last week. The padlock icon is back and the blue glow is gone (this page describes the new indicators):

This change brings Firefox back into closer parity with the other major browsers, which is good. It’s unfortunate that along the way users have gone through a series of confusing changes.

Mozilla seems to have made this change not primarily because of the confusion I identified, but because they had moved the site “favicon” from the URL bar up to the site tab:

This change was made to prevent attackers from using a padlock icon as their favicon, which could fool users into thinking that they were using a secure connection when they actually were not. In the process, they needed to put something else in the spot where the favicon used to be, and evidently they thought they’d return the padlock icon to its former glory.

Security usability researchers have repeatedly shown that few users pay attention to security indicators or warnings. Trying to meaningfully indicate security status to users may be a losing battle, but this these frequent rejiggerings can’t help.

Ultimately, site operators have the greatest ability to ensure that their users’ connections are encrypted. They can tell the browser that the connection should always be encrypted by using HTTP Strict Transport Security, and may soon be able to do “CA pinning” to tell the browser that encrypted connections to unfamiliar Certificate Authorities should not be trusted. At some point, they may even be able to indicate this via secured DNS as part of the “DNS-based Authentication of Named Entities” (DANE) standard.