Thursday 07 August 2008

What can we do with the bloated Firefox?

Mozilla Labs are inviting world and dog to "get involved and share their ideas and expertise as we collectively explore and design future directions for the Web".The comments section is filling up with all sorts of ideas for a 'richer' experience, some abusive crud, some cretins saying 'just make it work' like it was a new idea and a few people pleading for it to be kept simple.

I'm adding my vote for the keep in simple camp. The one idea I really do like, posted quite early in the comments process, is auto-hiding button bars. I don't think that hiding the address bar would be a great idea, since it and the status bar provide what little visibility security has - but the nav buttons, bookmarks and app menu could probably make way for a bit more vertical space.

My own request has nothing to with the visual or user experience, it's a something for the programmers - I'd like script only cookies. This would allow a JavaScript to access a value that persisted across pages and could be used to identify a user's session independently of whatever was being put on the wire and could therefore be sniffed. With a script only cookie in place protocols like J-PAKE and SRP could start to make a meaningful contribution to protecting against session hijacking by attackers on the wire.

The solutions to attacks from within the browser (XSS and CSRF) are different and any advances in this area would help to make a script only cookie less exploitable. An uniform global access control mechanism in the JavaScript engine, defaulted to deny, may impose an unacceptable overhead but if someone far smarter than I am could pull it off it would be great.The Site Security Policy project looks like a great step forward in this regard (there's also a nice synopsis if you're not in the mood for a lot or reading).

It's not a silver bullet. It does place some level of trust in the browser and is vulnerable to tampering by a man in the middle. But that's in line with the threat it's trying to mitigate, so it's OK. The gross simplification of the threat is: A generally available browser on a user's system can be tricked into lying to one website by the content of another website the user happened to open simultaneously. The idea would mainly be of interest to you as the owner or webmaster of the first site. You don't want to execute requests that you think come from a legitimate, authenticated, user of your site but were actually faked by some malicious script from the site they visited in the next tab over. An attacker running a customised browser that ignored the restrictions would gain only the ability to hijack their own sessions, not very useful. If the restrictions could be turned off in a broad base of browsers remotely then there would be some gain - which is all the more reason for this sort of protection to be baked in rather than in a plugin. The appeal and danger in this sort of attack is that it requires so little access to the browser's traffic and can thus target so many machines - injecting some code into a vulnerable bulletin board or CMS will provide far broader coverage far more easily than constructing man-in-the-middle scenario. Mitigating, or even completely removing, this class of vulnerabilities would not make the net a magically fluffy and friendly place but it would make attackers work harder for their gains - which is all we can realistically hope for.