AJAX and the Great Data Cloud in the Sky

Office apps, backup, calendars – trying to store it online was all the rage of the mid-90s. By 2000, we would be hopping on our flying scooters and whizzing past the great data cloud in the sky.

Well, it was nice to dream.

Here are two major reasons it never happened:

  • Options for rich clients – like Java applets and downloadable applications – were never feasible for a range of reasons, meaning that web applications became the only realistic choice. But web applications gave a lousy user experience and were hampered by portability issues.
  • Trusting the host. Are you crazy? You want me to store my prized data on someone else’s box?

Well, AJAX is a big step towards rich clients, and what we’re seeing now will only get better with emerging patterns and frameworks. GMail and Backpack and the thousands of wikis are all examples of web applications with important data being stored server-side.

But right now, you have to trust the host with your data. Feasible in some cases, but it would be ideal if data could be encrypted server-side. So a big challenge right now is to work out how web applications can deal with encrypted data.

It turns out that AJAX may well offer a viable solution to server-side encryption. For the past couple of weeks, Richard Schwartz has been talking about how an AJAX application could decrypt on the fly. The idea is this: in the past, decryption in the browser would have meant a Java applet – with all the usual Java problems – or Javascript-based encryption. But Javascript can’t remember data between page loads, so the user would have to type the passphrase each time (or use frames, which is feasible though messy). An AJAX application need load only once, so the user would only have to enter the password once per session. Richard has a proof-of-concept demo too.

There’s also some further discussion about how practical this idea is. Having to type your password in each session is certainly an issue, but not a showstopper in my view, at least not for techie users. The reason is because of browser plugins. As Richard mentions, it could be solved on Firefox with a GreaseMonkey script. The reality is, it could be solved on IE too with the right plugin. So this is an example of progressive enhancement. You can type your passphrase in if you need to, but install this plugin to avoid it.

8 thoughts on AJAX and the Great Data Cloud in the Sky

  1. Pingback: Software As She’s Developed » Blog Archive » Progressive Enhancement and Browser Plugins

  2. Pingback: Software As She’s Developed » Blog Archive » Progressive Enhancement and Browser Plugins

  3. As someone who’s spent a LOT of time in the webappsec community and the DHTML world (yes, I know that makes me doubly freakish), I would like to point out that this is all…how do I put this nicely…misdirected?

    Firstly, what problem is purported to be solved with this approach? That of guarding content in transit? That’s what SSL is for. Guarding the content in the client? From whom? Bad news: once it’s decrypted, it’s still in the same memory space it started in, so XSS and script injectection will still be able to read it just fine. Is it to guard against transmission through untrusted 3rd party systems? If so, how can he guarantee that the (assumedly uncooperative) serving page isn’t going to add a script that looks to check for decryption and then just posts the decrypted content back (making the whole exercise moot)?

    There is no articulated threat model nor an explination of how/why this is a good thing.

    I can see real value in baking something like 3rd party trust mechanisms into Greasemonkey plugins to solve the last problem I mentioned, but that’s still tricky and it’s a world of difference from the password/passphrase caching mechanism you’re discussing here.

    Back to the drawing board.

    Regards

  4. Pingback: Full(o)bloG » Blog Archive » ancora ajax

  5. Pingback: Full(o)bloG » Blog Archive » ancora ajax

  6. Alex — you’ve missed the point. Which undoubtedly means that I have not explained it well enough. First, no this is not a replacement for SSL. But secondly, the code that executes in the browser can always be detected and examined. Giving the end-user confidence that no unauthorized scripts writtn by untrusted parties run in their browser in the context of a given application may be a difficult problem, but it’s a problem that can be solved. That is to say, the scripting environment in the browser can be made no less insecure than any other part of the desktop environment, and realistically that is the best that one can ever hope for.

    What I envision is this:

    Alice and Bob want to exchange data securely.

    Charles hosts a web server used by Alice and Bob, but is not trusted by Alice or Bob.

    Threat: Charles obtains access to Alice and Bob’s data.

    Solution:

    David provides an expert opinion to Alice and Bob, vouching for the fact that the HTML and Javascript generated by Charle’s server does not transmit unencrypted data, and does not use surreptitious methods to download and load additional scripts for execution. David provides Alice and Bob with a signed version of the actual code from Charle’s server that he is vouching for.

    Ethan provides an open-source tool to Alice and Bob. This tool is a browser plugin capable of validating that the HTML and JavaScript loaded from Charles’ web site site into a given browser matches the code signed by David.

    Alice and Bob run Ethan’s code. They are now assured that any attempt by Charles to modify the scripts in such a way that it would transmit plaintext data to Charles (or data encrypted with a key known only to Charles) can be detected. Only a conspiracy of Charles, David, and Ethan can break that assurance.

    No — I don’t know how to write Ethan’s tool. But I’m convinced that it can be done. The inherent open-source nature of JavaScript makes it possible.

    The problem of theft of plaintext data stored on a remote server hosted by Charles, on the other hand, is one that can not be solved.

    -rich

  7. Pingback: thrashor

  8. I didn’t understand it to be like that at all. I understood it as such:

    Charles hosts a web service which is offered to the general public. Part of the service includes the storage of users’ data on the server (e.g. emails, files, and any other “private” user data).

    Alice wishes to use this this service. Alice trusts that her own private home PC used to generate and/or view this private content is safe from other users, trojan horses, and other nasties. Alice furthermore trusts that the SSL encryption protects her data along the wire in transit. Alice may even trust that her information is safely protected on Charles’s webserver, to the extent that malicious users cannot access it.

    Unfortunately, Alice does not trust Charles himself not to spy on her data. Therefore, Alice will go to Ethan to use a tool which is designed not to protect her data from other malicious users, but rather to protect the data from the service provider himself.

    I’m not sure where David comes in, and Bob, in my understanding, is an optional addition.

Leave a Reply