A while back I happened across this article on programming.reddit.com — “Moving the ‘C’ in ‘MVC'” — about web applications whose logic is implemented primarily on the client-side, in javascript, as opposed to the server-side. Interesting stuff, the sort of thing that’d bubbled around my head at one time or another.
That article mentioned clipperz.com and their concept of a “zero knowledge web app.” The idea here is to implement client-side cryptography in javascript and store nothing on the serverside except wads of encrypted data. Data that is encrypted on the client, that is. So it never passes over the wire in the clear, and it’s never decrypted on the other side of the wire.
That’s pretty cool. In fact, clipperz.com hosts their own best shot at a zero-knowledge web app, a password manager. A web-based password manager seems insanely insecure, but not so if you implement it as a zero-knowledge web app. It’s basically like keeping a local HTML with all your passwords and javascript which allows you to click on those passwords and have it launch the appropriate page and log in to the service in question (Google, Facebook, whatever) — except that instead of keeping it locally you’re keeping an encrypted version of it on clipperz.com’s servers.
As far as usage goes, it’s pretty simple, but unusual. In a normal web app, you log in once, after which you are recognized by cookies until some timeout period. That’s because you’re logging in to an app running on the server, and cookies help maintain the illusion of a persistent connection. In clipperz, the app is running in your browser. So if you close the page and come back to it, you have to log in again. But you can leave that page open forever and it never times out, because there’s a real connection between you and the app (an open browser window) so there’s no need for the whole cookie deal.
Adding logins to the app is an unusual process but easy once you get used to it. When you’re on the login page to the service in question (myspace, yahoo, whatever) with your username and password typed in the blanks, you can click on a bookmarklet you’ve previously saved from clipperz, and it will extract a chunk of JSON data from the page you’re on, representing the login form, your username, and password. You cut and paste that into your running clipperz session in another tab or window, and it takes that JSON chunk and adds that to its data store, and now you have a clickable link on your clipperz page which will log you in to that service.
Knowing I’ve got an instant one-click login to a service makes it easier for me to make a habit of logging out of a service when I’m not using it.
It’s also easy to maintain more than one login to the same service using clipperz. Each is just one click away.
Clipperz has a sometimes-friendly, sometimes not-so-friendly competitor named “PassPack,” whose authors consider Clipperz.com’s zero-knowledge thing “fallacious” in some way, though reading through it I’m still not sure exactly what they think is wrong with Clipperz’s way of doing things. I guess the idea is that any privacy and security that Clipperz provides for you that PassPack doesn’t is just silly and you shouldn’t worry your pretty little head about it, for such worrying is a “fallacy.” I don’t know. It sounds like PassPack might be easier to use, and harder to understand what they’re doing. With clipperz you just have a username and passphrase; with PassPack you have a username and password and an additional crypto key. (UPDATE: see comments below, from Tara from PassPack for clarification of what they were getting at.)
In any case, PassPack and Clipperz have each posted a list of the pros and cons with their respective services. Overall I have to say that having actually used Clipperz for a while I don’t see anything about PassPack that encourages me to explore it as an alternative.
Anyway, my review of Clipperz after a couple weeks of use — thumbs up! It’s unusual but worth getting to know.
Hi- I’m a Passpack founder. You’re right, we do have a love/hate relationship with Clipperz. On one hand, we are both Italian companies, we’ve met, had coffee, looked for ways to collaborate (never worked out).
On the other hand, despite our technology being nearly identical, we have very different philosophical approaches. It’s in this realm where we tend to lock horns.
Just a note – the technology that you mentioned, where Javascript is used for encryption on the client, and the server is “blind”, is called Host-Proof Hosting. Both Passpack and Clipperz use Host-Proof Hosting.
The definition of a Zero Knowledge Web Application, is a theoretical extension of Host-Proof Hosting. It’s not actually possible right now to build an application which adheres to the ZKWA definition – whereas it is possible to build a Host-Proof Hosting application.
HPH is a technique. ZKWA is an idea.
Clipperz, as an HPH application is well executed and perfectly valid. What was being criticized in the Trust Fallacy post was not the password manager, but rather the definition of ZKWA.
Sorry for the long comment. It’s hard to distinguish between the two, and judging by the reaction we’ve had to the Trust Fallacy post, I think we weren’t really able to get our point across. Some people were confused, others didn’t really understand, and others felt we were bashing our competitors.
Oh well, no one is perfect. I hope I’ve cleared things up a bit.
Cheers,
Tara
Thank you, Tara. That clarifies well the point you were trying to make, which I didn’t really get.
Tangentially related: check out sproutcore.com for a “thick-client” javascript application framework that does most stuff in-browser. It’s apparently what’s powering Apple’s new MobileMe, and looks pretty neat, both from a nifty UI perspective and a shift in application design perspective.
Thanks, I will check it out!
Thank you Ed. :)
@Joel, sproutcore looks cool. Would you say that it is a competitor for JQuery and other js frameworks? Or is it something more than that?
@Ed, if you don’t want this thread to become a giant javascript framework discussion, just let me know and we can I’m sure take our conversation offline.
@Tara, no, it’s aimed at a different development model. jQuery and Prototype and their ilk try to smooth out browser inconsistencies in event handling, provide cross-browser AJAX capabilities, and allow for quickly adding behavior that would be complex to create by hand. Prototype also infests (I say that in a non-pejorative way) the Javascript language with added functionality, providing new, Ruby-like syntax.
Those JS frameworks also tend to provide widgets for interaction that are not provided by stock (X)HTML, like accordion controls, sliders, combo boxes, etc. However, they all still rely on the server for most of the heavy-lifting for data storage, business logic, and forth; they add the UI shine to something that could (or should?), in theory, function without JS enabled.
SproutCore, OTOH, is an application development framework along the lines of Rails, Symfony, CakePHP, etc., except that it’s implemented in Javascript. It uses Ruby to generate code during development, but when you “deploy” you’re actually sending just XHTML and Javascript to the server to be run. If a user cannot run Javascript, then there is no possible way they could use a SproutCore-run website (by design).
I don’t fully understand all that it does, but I’ve seen references to SproutCore doing data storage entirely client-side, using some new features of HTML5. You can, of course, communicate with a backend server, but I get the impression that you use largely RESTful URLs to sync data with from the client back to the server.
My knowledge of the specific implementation of SproutCore is fairly spotty and shouldn’t be relied upon, but I think the difference is that SproutCore enables entirely in-browser applications like http://280slides.com/ (though I think that site uses a similar-in-concept project called Objective-J), where as thin frameworks like jQuery (I love jQuery, btw) focus on enhancing and easing Javascript authoring without providing a full-fledged development environment.
@Joel
That’s fascinating. I’m not the JS developer on the team, so my knowledge probably spottier than anyone else’s. I know there were some experiments (since abandoned) going on here with Jaxer which takes another approach altogether by running a JS directly on the server. I’ll ask around and see if anyone has tried playing with SproutCore yet.
As for HTML5, yes, the client-side storage is promising, though not fully supported yet. But I think you can get most of the browser/OS combination covered by combining both native HTML5 support and Google Gears.
Thanks for the info! I’ll look into it.