Updated May 13, 2005
The blogdriver's post on the Ajax Summit got me thinking.
First, it brought back ambivalent memories of hundreds of hours of consulting time spent telling clients that they cannot have client-server style features like search string autocomplete or search-as-you-type á la Google Suggest in their web applications. These memories are ambivalent because on one hand some of these conversations were very challenging like smashing rocks with your bare forehead. On the other, it was precisely the non-client-server nature of everything that we were doing with web apps back in the day (a few years ago) that made what we were doing so cool and made us web folk feel like members of a secret cabal. Now, of course, times have changed again, and with approaches like Ajax you can do this stuff on the web - the smooth responsiveness of moving around in Google Maps is my favorite example to prove this point. Gone forever is the mystique that was once attached to writing Perl CGIs (although mod_perl is still pretty interesting), being the only one in the office who could use Photoshop to make a decent looking GIF with a non-dithering CLUT, and being able to edit raw HTML without a reference!
Secondly, and more to the point, it occurred to me that there is an excellent information security opportunity here. If you have a need for secure web communications your current options are limited to the following:
- Use SSL/TLS available to your browser combined with an authentication mechanism of your choice at the application layer;
- Use SSL/TLS available to your browser with client side certificates, which is rarely done for a number of reasons including usability issues; or
- Establish a VPN connection lower down the OSI stack then pass on the user's authentication credentials to web applications that need them.
Figure: A concept for Ajax-driven secure web communications (and it could even be easy and productive to use)
This Ajax-driven model could provide web applications with modular access to an array of cryptographic services such as:
- Confidentiality
- Sender and receiver validation
- Message integrity
- Non-repudiation
- Authentication
- Secure timestamping
Secure email vendor hushmail has gone part way down the Ajax road in delivering PKI-based secure email and other security services via the web. Essentially, the folks at hushmail have placed a Java applet implementation of OpenPGP where the Ajax Engine would go. The JVM applet container is responsible for handling authentication, encryption, and signatures (pdf description). The php driven user interface, which falls a little short on the usability front in comparison with other webmail competitors, then interacts with the applet container via JavaScript. While hushmail's application architecture is analogous to the Ajax model, hushmail falls short in the realm of asynchronous communications. All hushmail communications are strictly synchronous when significant user experience gains could be made through judicious use of asynchronous preloading of unread mail, preloading the contents of mail folders, matching addresses in your address book as you type, and probably other areas.
Figure: An over simplified hushmail architecture
Will Ajax be the next big thing in secure web communications design? I honestly do not know. At the very least, the concept of embedding security services into the Ajax Engine layer provides an alternative model to currently deployed secure web communications models - and in the metaphorical ecosystem of information security, diversity is good.
Notes: "Maturing" XML security standards (referred to above):
1 comment:
Good info, but now I have another few hundred pages more to read!
reeder
Post a Comment