November 24, 2024

Web Browser Security User Interfaces: Hard to Get Right and Increasingly Inconsistent

A great deal of online commerce, speech, and socializing supposedly happens over encrypted protocols. When using these protocols, users supposedly know what remote web site they are communicating with, and they know that nobody else can listen in. In the past, this blog has detailed how the technical protocols and legal framework are lacking. Today I’d like to talk about how secure communications are represented in the browser user interface (UI), and what users should be expected to believe based on those indicators.

The most ubiquitous indicator of a “secure” connection on the web is the “padlock icon.” For years, banks, commerce sites, and geek grandchildren have been telling people to “look for the lock.” However, The padlock has problems. First, it has been shown in user studies that despite all of the imploring, many people just don’t pay attention. Second, when they do pay attention, the padlock often gives them the impression that the site they are connecting to is the real-world person or company that the site claims to be (in reality, it usually just means that the connection is encrypted to “somebody”). Even more generally, many people think that the padlock means that they are “safe” to do whatever they wish on the site without risk. Finally, there are some tricky hacker moves that can make it appear that a padlock is present when it actually is not.

A few years ago, a group of engineers invented “Extended Validation(EV) certificates. As opposed to “Domain Validation(DV) certs that simply verify that you are talking to “somebody” who owns the domain, EV certificates actually do verify real-world identities. They also typically cause some prominent part of the browser to turn green and show the real-world entity’s name and location (eg: “Bank of America Corporation (US)”). Separately, the W3 Consortium recently issued a final draft of a document entitled “Web Security Context: User Interface Guidelines.” The document describes web site “identity signals,” saying that the browser must “make information about the identity of the Web site that a user interacts with available.” These developments highlight a shift in browser security UI from simply showing a binary padlock/no-padlock icon to showing more rich information about identity (when it exists).

In the course of trying to understand all of these changes, I made a disturbing discovery: different browser vendors are changing their security UI’s in different ways. Here are snapshots from some of the major browsers:

As you can see, all of the browsers other than Firefox still have a padlock icon (albeit in different places). Chrome now makes “https” and the padlock icon green regardless of whether it is DV or EV (see the debate here), whereas the other browsers reserve the green color for EV only. The confusion is made worse by the fact that Chrome appears to contain a bug in which the organization name/location (the only indication of EV validation) sometimes does not appear. Firefox chose to use the color blue for DV even though one of their user experience guys noted, “The color blue unfortunately carries no meaning or really any form of positive/negative connotation (this was intentional and the rational[e] is rather complex)”. The name/location from EV certificates appear in different places, and the method of coloring elements also varies (Safari in particular colors only the text, and does so in dark shades that can sometimes be hard to discern from black). Some browsers also make (different) portions of the url a shade of gray in an attempt to emphasize the domain you are visiting.

Almost all of the browsers have made changes to these elements in recent versions. Mozilla has been particularly aggressively changing Firefox’s user interface, with the most dramatic change being the removal of the padlock icon entirely as of Firefox 4. Here is the progression in changes to the UI when visiting DV-certified sites:

By stepping back to Firefox 2.0, we can see a much more prominent padlock icon in both the URL bar and in the bottom-right “status bar” along with an indication of what domain is being validated. Firefox 3.0 toned down the color scheme of the lock icon, making it less attention grabbing and removing it from the URL bar. It also removed the yellow background that the URL bar would show for encrypted sites, and introduced a blue glow around the site icon (“favicon”) if the site provided a DV cert. This area was named the “site identification button,” and is either grey, blue, or green depending on the level of security offered. Users can click on the button to get more information about the certificate, presuming they know to do so. At some point between Firefox 3.0 and 3.6, the domain name was moved from the status bar (and away from the padlock icon) to the “site identification button”.

In the soon-to-be-released Firefox 4 is the padlock icon removed altogether. Mozilla actually removed the “status bar” at the bottom of the screen completely, and the padlock icon with it. This has caused consternation among some users, and generated about 35k downloads of an addon that restores some of the functionality of the status bar (but not the padlock).

Are these changes a good thing? On the one hand, movement toward a more accurately descriptive system is generally laudable. On the other, I’m not sure whether there has been any study about how users interpret the color-only system — especially in the context of varying browser implementations. Anecdotally, I was unaware of the Firefox changes, and I had a moment of panic when I had just finished a banking transaction using a Firefox 4 beta and realized that there was no lock icon. I am not the only one. Perhaps I’m an outlier, and perhaps it’s worth the confusion in order to move to a better system. However, at the very least I would expect Mozilla to do more to proactively inform users about the changes.

It seems disturbing that the browsers are diverging in their visual language of security. I have heard people argue that competition in security UI could be a good thing, but I am not convinced that any benefits would outweigh the cost of confusing users. I’m also not sure that users are aware enough of the differences that they will consider it when selecting a browser… limiting the positive effects of any competition. What’s more, the problem is only set to get worse as more and more browsing takes place on mobile devices that are inherently constrained in what they can cram on the screen. Just take a look at iOS vs. Android:

To begin with, Mobile Safari behaves differently from desktop Safari. The green color is even harder to see here, and one wonders whether the eye will notice any of these changes when they appear in the browser title bar (this is particularly evident when browsing on an iPad). Android’s browser displays a lock icon that is identical for DV and EV sites. Windows Phone 7 behaves similarly, but only when the URL bar is present — and the URL bar is automatically hidden when you rotate your phone into landscape mode. Blackberry shows a padlock icon inconspicuously in the top status bar of the phone (the same area as your signal strength and battery status). Blackberry uniquely shows an unlocked padlock icon when on non-encrypted sites, something I don’t remember in desktop browsers since Netscape Navigator (although maybe it’s a good idea to re-introduce some positive indication of “not encrypted”).

Some of my more cynical realistic colleagues have said that given the research showing that most users don’t pay attention to this stuff anyway, trying to fix it is pointless. I am sympathetic to that view, and I think that making more sites default to HTTPS, encouraging adoption of standards like HSTS, and working on standards to make it easier to encrypt web communications are probably lower hanging fruit. There nevertheless seems to be an opportunity here for some standardization amongst the browser vendors, with a foundation in actual usability testing.

CITP Visitors Application Deadline Extended to Feb 1st

The deadline for applications to CITP’s Visitors Program has been extended to February 1st. If you or someone you know is interested but has questions, feel free to contact me at

The Center has secured limited resources from a range of sources to support visiting faculty, scholars or policy experts for up to one-year appointments during the 2011-2012 academic year. We are interested in applications from academic faculty and researchers as well as from individuals who have practical experience in the policy arena. The rank and status of the successful applicant(s) will be determined on a case-by-case basis. We are particularly interested in hearing from faculty members at other universities and from individuals who have first-hand experience in public service in the technology policy area.

For more details and instructions about how to apply, see the full description here.

RIP Bill Zeller

All of us here at CITP were saddened by the death of Bill Zeller, our respected and much-loved colleague. Bill was a Ph.D. candidate in Computer Science here at Princeton, who died last night due to injuries sustained in a suicide attempt.

There has been a huge outpouring of sympathy for Bill, both at Princeton and across the Internet, which is entirely appropriate. But I’d like to focus here on the positive side of Bill’s life.

Bill has made at least two appearances here on Freedom to Tinker, first as the instigator of the Miraculin experiment (Miracle Fruit: Tinkering with our Taste Buds), then later for his research on web security (Popular Websites Vulnerable to Cross-Site Request Forgery Attacks).

Bill always had a new project brewing. His projects ranged from the quirky (the cult favorite Cats in Christmas Trees site) to an early blogging tool (Zempt, which was incorporated into Movable Type) to many useful software development tools (such as jLambda). Tens of millions of people have read or used something that Bill created.

Bill’s sense of humor was much appreciated by his friends. He would sometimes go to considerable lengths for the sake of a joke. Once, for the sake of an office joke, he created a technology package including an online game, an RSS-based miniblogging tool, and a screen saver. Then, later, he shut it all down, as a birthday present for the friend who was the target of his (good-natured) joke.

We have many, many fond memories of Bill, more than we could possibly fit here.

Those of you who knew Bill are invited to add your own fond memories in the comments.

The Flawed Legal Architecture of the Certificate Authority Trust Model

Researchers have recently criticized the Certificate Authority Trust Model — which involves the issuance and use of digital certificates to authenticate the identity of websites to end-users — because of an array of technical and institutional problems. The criticism is significant not only because of the systemic nature of the noted problems, but also because the Model is universally relied upon by websites offering secure connections (SSL and TLS) to end-users. The Model comes into play in virtually every commercial and business transaction occurring over the Internet, as well as in a wide variety of other confidential and private on-line communications. What has not been addressed to date, however, is the nature of the legal relationships between the parties involved with, or impacted by, the Model.

Steve Schultze and I tackle this topic in our recent article “The Certificate Authority Trust Model for SSL: A Defective Foundation for Encrypted Web Traffic and a Legal Quagmire.” We looked at the standard legal documents issued by the certificate authorities or “CAs,” including exemplar Subscriber Agreements (agreements between CAs and website operators); “Certification Practice Statements” (statements by CAs outlining their business practices); and Relying Party Agreements (purported agreements between CAs and “relying parties,” such as end-users). What we found was surprising:

  • “Relying Party Agreements” purport to bind end-users to their terms despite the apparent absence of any mechanism to either affirmatively alert the end-user as to the existence of the supposed Agreements or afford the end-user an opportunity to register his or her acceptance or rejection of the Agreements’ terms
  • Certification Practice Statements that suffer from the same problem (i.e. no affirmative notice to the end-user and no meaningful opportunity for acceptance or rejection of terms)

There were other issues as well. For example, the Relying Party Agreements and Certification Practice Statements set forth various obligations on the part of end-users (i.e. “relying parties”) such as: the requirement that end-users make an independent determination of whether it is reasonable to trust a website offering a secure connection (isn’t that the whole point of having a CA, so that the end-user doesn’t have to do that?); the requirement that the end-user be familiar with the crypto software and processes used to carry out the authentication process; and the end-user’s duty to indemnify and hold harmless the CA in the event of legal claims by third parties.

Given the absence of notice to the end-user and assent by the end-user, it would appear that many CAs would have a difficult time holding an end-user to the terms of the relying party agreements or certification practice statements. To date, the CA Trust Model’s legal architecture has apparently not been the subject of any published court decision and remains untested.

The bottom line is that the CA Trust Model’s legal architecture inures to the benefit of no one. Neither website operators, certificate authorities, nor end-users can be sure of their rights or exposure. The Model’s legal structure may therefore be just as troubling as its security vulnerabilities.

You can read the full article in PDF form.

[Editor: Steve Roosa gave a followup luncheon talk at CITP entitled The Devil is in the Indemnity Agreements: A Critique of the Certificate Authority Trust Model’s Putative Legal Foundation. Slides and audio are now posted.]

Ninth Circuit Ruling in MDY v. Blizzard

The Ninth Circuit has ruled on the MDY v. Blizzard case, which involves contract, copyright, and DMCA claims. As with the district court ruling, I’ll withhold comment due to my involvement as an expert in the case, but the decision may be of interest to FTT readers.

[Editor: The EFF has initial reactions here. Techdirt also has an overview.]