Browser developers meet, see eye to eye on security


Author: Stephen Feller

Developers of four major Web browsers — Konqueror, Mozilla Firefox, Opera, and Internet Explorer (IE) — gathered at an informal meeting in Toronto on November 17 to review plans and share progress on security improvements and standards. The intents were making security information more meaningful to users, and balancing security for high-traffic sites (such as banks) and smaller organizations and businesses.

No commitments were made to adopt the same things, but developers came to common understandings on ideas such as the location of the padlock icon that appears when visiting authenticated sites, stronger certificates and certificate validation techniques, shortcomings in browser cryptography, and solutions to the problem of phishing.

Among the most visible improvements is how browsers inform users of Web sites’ transaction security. The padlock icon — which appears somewhere in every browser when a user visits a secure site — will be moved to the address bar in all four browsers to make it more noticeable.

“I think it’s a goal to come to common interfaces and implementations, where they make sense,” said George Staikos, the KDE core developer who organized the meeting. “I think we all feel that it’s for the common good if the browsers work together — as opposed to recreating the big mess we had in the old Netscape-Internet Explorer [browser war] days. And I think we will see some more working together in the future.”

Unprecedented meeting

The meeting grew out of discussions that developers of all four browsers have been carrying on for about seven months, Staikos said. Since their paths were crossing in Toronto, Staikos called the meeting in the hopes they could spend a full day going over issues and ideas, and he believes it was successful in moving forward on the things they discussed.

In addition to Staikos (who represented Konquerer and KDE), Mozilla sent its certification expert Frank Hecker. Opera was represented by developers Carsten Fischer and Yngve Pettersen, and Microsoft sent IE developers Rob Franco, Kelvin Yui, and Tom Albertson.

Calling it unprecedented and “quite refreshing,” Staikos said it was significant that Microsoft is “working both with their arch-enemies from the browser [war] days, and with the open source community as well.” He added, however, that there is not much choice, because problems like phishing and more secure connections between users and Web portals are problems they all have had to deal with. Thus, it makes sense to work together to solve them.

Hecker pointed out that browser developers and others already collaborate, often in the context of formal standards bodies and working groups put together by outside organizations. Since there is no formal standards body or related organization looking at the Secure Sockets Layer (SSL) protocol, user interface, or server certificates, he said, the browser meetings were less formal and without an audience or reporters.

Protecting users from phishing

According to a November 21 post on the IE Blog blog, Franco presented the Anti-Phishing User Experience and Phishing Filter as a “counter-example” for well-identified sites. Planned for inclusion in IE 7 and due out as a plugin next year, the filter will indicate in the address bar whether a site is known or suspected of phishing and color the address bar red or yellow depending on which it is.

Microsoft collects this information from a combination of customer reports and data providers who confirm phishing sites, and updates the service several times an hour to protect users from scams as quickly as possible, according to a November 17 post on the IE Blog from John Scarrow, general manager for Microsoft’s Anti-Spam and Anti-Phishing Team. A version of the plugin is already available for IE 6.

In a November 21 post at KDE Dot News, Staikos indicated his hope that Microsoft would allow other browsers to develop something similar to the Anti-Phishing plugin — if not release some form of it to the open source community to work on and improve.

“I hope that Microsoft will be open with this system and allow us to write our own Konqueror plugin, allowing our users to contribute to their [phishing Web site] database and take advantage of it,” Staikos wrote in the post. “They didn’t rule out the potential to open up their client technology in the future. They suggested that others interested in offering similar technologies could take their own approaches and work with the same industry data providers that they use.”

Opera 8 already includes what the company calls a “lock box,” wrote Fischer and Pettersen in a November 23 post to the Opera Web site. The lock box is a yellow bar intended to help users verify that the site they visit is in fact owned by the company they are looking for — in addition to offering information about the encryption of sensitive information sent over the Internet.

A good number of phishing concerns were also addressed in discussions about strengthening Web sites’ certificate verification (which help in identifying whether a site is phishing) and making that information more easily understandable to users.

Certificate and security improvements

The browser developers discussed increasing the level of cryptography being used in browsers, and agreed to disable or remove lower-strength certificates and weaker ciphers from their applications, Staikos said. SSL 2.0 has already been removed from Konquerer, he said, and the others have agreed to do so too. Other ciphers will likely be disabled or removed in “upcoming months and years,” with much stronger ones being promoted by the browsers.

Certificate verification and security of encrypted information will be exposed by filling the address bar with one of three colors: red when the verification fails, yellow (on some browsers) for questionable verification, and green when a high-assurance certificate is verified. The name of the company who owns the Web site will also be rotated with the name of the verifying agency beside the URL, offering users further security information.

In IE, verification alerts will also be triggered by Microsoft’s Anti-Phishing Filter, offering additional security information. Franco cautioned, however, that while the system will check certificates as they are used now, more specific information won’t be available until everybody — browser vendors and certification authorities (CAs) — is on the same page.

“I wish we could promise you that you will see this experience in IE7 and … other browsers but there are a lot of details to work out before browsers can differentiate SSL sites based on how well-vetted they are,” Franco wrote. “For this to work, Microsoft, Mozilla, Opera, and Konqueror, amongst others, think there should be some common validation guidelines for rigorous Web site identification. There is a lot of preliminary agreement but also a lot of work to do.”

If CAs don’t offer the extended validation certificates the browsers are working to propose, it may not make sense to implement changes to the user interface, Hecker said. Consistency between the browsers’ user interfaces and public messages about good practices are the key to making any changes worthwhile.

“If CAs do offer new types of certificates then there has to be a consensus on how information in those certificates is represented and used,” Hecker said. “CAs don’t want to do different things for different browsers, and browser developers don’t want to do different things for different CAs.”

Calling CAs the “major players” in making any proposal work, Staikos said the potential business opportunities could attract them to follow along once the software is finished. He added that all browser vendors will have to agree to something similar, as will email clients and other applications that use SSL.

Ford said that Opera developers have long felt that security aspects such as those discussed at the meeting should be the same in all browsers. He added, however, that certificate authorities need a common platform — if not method of information delivery — in order to implement the changes that browser vendors are considering.

“You will see similar things, but it’s more important to handle the information in a common way,” Ford said. “We can still choose different UI implementations, but we’re working toward a common position to present to the other companies who influence encryption.”

More collaboration in the future?

Calling the meeting a great, positive experience, Staikos said he is hopeful the browsers can translate their success in agreeing on security standards to other areas of Web browsing. Among other things, he said he would like to work together on creating more compatibility in rendering and style sheets, XML support, and more advanced forms.

“If we can start to move into those areas over time, I think that this would be a really positive thing for Web developers and the users,” Staikos said.

Ford also said he expected more collaboration between the browsers, but beyond security did not elaborate as to what they might work on together. He did add, though, that phishing is “a threat to the entire Internet,” and that everyone from domain registrars and browser vendors to CAs needed to work together to stop it — especially because industry-wide agreements are necessary for anything to work.

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