A Truce in the Browser Wars: Toronto Ideas Create Common Ground

By Carsten Fischer and Yngve Nysaeter Pettersen

November 23 2005

Who knew that all it would take for browser vendors to get together was a little pizza? But that was the scene in Toronto last week when members of development teams from Opera, Microsoft, Mozilla and Konqueror sat around a table - no suits, no microphones, no reporters - to tackle the pressing issue of secure certificates.

A Little History

In Opera 8, we introduced the lock box: a yellow anti-phishing bar that helped users identify that the site they were visiting was actually owned by the company they intended to visit. The intention was to give users additional security when it mattered most - when sending sensitive information through an encrypted connection.

When you visit a secure site, all browsers use the padlock to identify that the site is secure and your information will be encrypted. But protecting an identity matters more than encrypting data. When you visit your bank, you want to make sure you're sending your personal information - password, account number, etc - to that bank. The lock box gave you a second opinion. It made sure you knew.

The lock box takes information from the certificate that comes with the encryption key used in the secure connection. But this information is not always as meaningful as it should or could be. This is partly because there is no clear guideline on how this information will become meaningful in the browser although the various UI implementation may differ.

At the same time, the other browser vendors were wrestling with this very issue. So we decided to do something about it. Together.

Throughout this year there have been mails and discussions with members of the Microsoft, Mozilla/FireFox, and Konqueror development teams, all with the goal of finding a common interpretation about how to deal with secure connections in the future. George Staikos from the KHTML/Konqueror Team kindly invited everyone to Toronto (slightly warmer than Oslo) summarized our common goals quite nicely. He also laid down a two-part challenge:

Find a way to make the security information presented to the user more meaningful, easier to recognize and understand, and
Balance the need to distinguish high-impact sites (banks, payment services, auction sites, etc) while retaining the accessibility of Secure Socket Layer (SSL) for smaller organizations.

Whew! We're trying to get this done in one day?!?

A Meeting of the Minds

Going into the meeting, so many emails and phone calls had been exchanged that we knew things would be amicable. We just didn't realize there would be so much common understanding and agreement.

It turned out smart minds (at least those other guys have those... ) do think alike. Everyone independently reached a similar conclusion about what high-impact sites require and how to implement these features in the UI. For example we all will display the padlock close to the address bar and we think that as much as possible the padlock should have the same meaning throughout all browsers.

We all think it's a good idea to remove breakable encryption like SSLv2 or 40 and 56 Bits ciphers from our upcoming browser versions. In addition, we will encourage Certificate Authorities (CAs) to issue certificates from stronger roots, most likely 2048-bit keys.

We will consider creating a new display mechanism in addition to the padlock to display these types of certificates that are strongly encrypted and strongly validated.

We will consider using Certificate Policy Extensions (an extension defined by X509, the format used for certificates) in the issued certificate and intermediate certificates in the chain, and a list (stored outside the root certificate as meta data, for example in the certificate database) of Policy Extensions permitted for the root certificate associated with the chain. By analyzing the policy identifiers and matching the associated validation profiles we could then decide which kind of indication - strong or normal - to show the user.

Microsoft has suggested green for certificates that meet the criteria of strong encryption and strong validation, red for Websites that are obviously phishing and yellow for suspect sites - the last two visual indications are triggered by their anti-phishing filter. Frank Hecker of the Mozilla project also published his thoughts on these UI proposals, along with some opinions on the role of CAs and how the CA industry might evolve.

Getting a policy added to the list of accredited policies, in particular the strong category, for a root will require that the CA owning the root must meet a number of criteria, which are not yet decided upon. These criteria, which remain unfinished, must be agreed upon not just by the browser vendors, but also by the Certificate Authorities.

It's good to see all of us put aside our marketing wars for a few days and get down to what really matters: making the Internet a safer place for the people who use our products, whether it is Opera, Firefox, IE or Konqueror. The onus for end-user security increasingly rests on the browser vendors. After all, it's our products that stand between the scammers and the scammed.

We can compete over so many aspects of our products, but security at this level requires cooperation and collaboration. And by sitting down at the same table, we have done more to enhance the security of the Internet than we could competing alone.

Thanks to everyone involved - George, Frank, Kelvin, Rob - for making this important step.

Write a comment »