Improving web application security without degrading user experience

Generally speaking, web application security involves a trade-off between security and the user's convenience. But I am not generally speaking in this article. I am trying to explore some areas where it is possible to improve security and let equal or even improve the user experience.

Single-Sign-On with OpenID based authentication

First, this makes live easier for the application developer, because to start with he has only to implement a client library (available for PHP, Ruby, Python, ...) at his server back end and not a whole authentication server. The end user gets a Single-Sign-On and he can chose from any public OpenId provider he wants. That's the theory. In practice, OpenID has been something new, just confusing the user. But this is changing rapidly, according to this document, the adoption rate is exponential and there are already 120 Mio OpenIdDs out there.
Because OpenID decouples the choice for an authentication server from the web application itself, the user can minimize the trade-off between security and convenience purely based on his preferences or his particular situation. And now there exist also innovative, password-less approaches:

• Image-sequence based login: Vidoop. Instead of a password, the user needs to remember an image sequence. There are quite a few interesting facts about Vidoop: e.g. it can generate ad-revenue from the images for the Web application provider, it is resistant against repetitive logins with a stolen token (the image sequence) because it is based on a challenge-response method which is different for every login attempt.
  
• Browser-certificate based login: MyOpenid. This is the most secure and most convenient method, as long and only as long as the authorized user is the only person with physical access to the computer with the browser, which contains that certificate.
  

Javascript filtering of user generated content and applications

Javascript is dangerous and common practice today, when the user is allowed to provide content, e.g. at the comment section of a blog, is to filter out at server side any possible Javascript elements in the HTML text the user provided in his comment. If interactivity is explicitly desired for user generated applications which run on the platform of the hosting application provider, then a subset of Javascript must be allowed, otherwise Web 2.0 user experience is gone. Facebook deals with this by defining its own Javascript subset called FBJS. Recently various technical approaches have been announced / discussed / released which deal with filtering of Javascript:

• AdSafe: A Javscript subset defined by Douglas Crockford. He is initially targeting the advertising industry with it, so that interactive ads can be placed on web pages without compromising the user's security. ADsafe can also be used for of mashup components such as widgets.
  
• Caja: From google. Does Javascript source-to-source translation. Currently written in Javascript, but the source code repository contains an empty folder titled "Java", so I guess that is what will come next.
  
• JStify: Filtering and also automatic replacement of unsecure Javascript code. Announced, no code released yet, written in Ocaml.
• and last and least my own not yet formally announced approach based on lexical analysis and parsing of Javascript in Erlang, as part of a Javascipt-to-Erlang compiler (to be open sourced) which I'm gonna use at the server side of my startup skast.com.