Freedom and privacy in the cloud: a call for action
May 30, 2008This is a post about freedom. The freedom to keep your data for yourself and the freedom to run free software. You should be able to reclaim and enjoy these freedoms also when using web applications.
If you are a supporter of the free software movement, you can easily opt for Gimp instead of Photoshop, or Firefox instead of Internet Explorer. You can also protect the privacy of your data by using the many encryption tools that are available (GPG, TrueCrypt, …). But when it comes to web applications things get complicated.
The benefits of web apps (ubiquitous access, seamless upgrades, reliable storage, …) are many, but quite often users lose their freedom to study, modify and discuss the source code that powers those web apps.
Furthermore, we are forced to trust web applications provider with our data (bookmarks, text documents, chat transcripts, financial info, … and now health records) that no longer resides on our hard disks, but are stored somewhere “in the cloud”.
It’s not a nice situation when you have to chose between convenience and freedom.
Let me be clear: web apps are great and I’m in love with them. But I think it’s time to ask for more freedom and more privacy. Here is a three step plan to achieve both these results.
1. Choose AGPL
Why is AGPL important? Because it means that, if you are an application service provider and your services are based on software with an AGPL license, you have to make the source code available to anyone that uses the service! FSF guidelines suggest to add a “source” link that leads users to an archive of the code right into the web application interface.
(Don’t ask me why it took so long to tackle this problem within the free software community!)
Action points
- Help Clipperz to assemble an “AGPL Suite”: a collection of web applications that provides tools for the most common needs.
- Join Clipperz in its effort to evangelize the benefits of AGPL to the maintainers of open source web projects. Ask them to convert to AGPL.
The suite should include: word processor, web chat, password manager, wiki, address book, to do list, calendar, bookmark manager, … Each web app must be released under an AGPL license! Therefore forget Google, del.icio.us, Plaxo, Meebo, … at least unless they switch to AGPL.
There are already a couple of candidates for inclusion (Ajax Chat for the web chat and, of course, Clipperz for the password manager, but most of the spots in the suite are still vacant!
2. Add zero-knowledge sauce
Web developers and web users are still largely ignoring the opportunity offered by browser-based cryptography to bring the privacy and security of traditional software programs to web applications.
At Clipperz we envisioned a new architecture paradigm called “zero-knowledge web apps” (here a more detailed description) that combines the idea of host-proof hosting with a set of rules focused on the “learn nothing” mantra.
The name was both an homage to cryptography (a “zero-knowledge proof” is a standard cryptographic protocol) and a promise of a specific relation between the application provider and the users. The server hosting the web app could know nothing of its users, not even their usernames! Clipperz applied this paradigm to implement its online password manager.
Action points
- Apply zero-knowledge techniques to each component of the “AGPL Suite”. Converting an existing web applications to the zero-knowledge architecture is not easy, but at Clipperz we have a considerable experience on the subject and we will be happy to share our knowledge and code base. We could eventually enjoy a web based word processor that can’t read our documents, a truly off-the-record web chat, a wiki where we could lightheartedly store valuable information, and so on.
- Build and maintain a list of ASPs that host the whole “AGPL Suite”. It will be a useful reference for those who value free software and privacy, but don’t possess the necessary skills and resources to run web apps from their own server.
3. Build a smarter browser
We are almost there, but we still need to provide users of web apps with an even more flexible and secure environment. In fact, given the architecture of a zero-knowledge web app, the server typically performs the following tasks:
- loads the Javascript code to the user’s browser (the actual program);
- optionally authenticates the user (using a zero-knowledge protocol);
- retrieves and stores encrypted data as requested by the user’s browser.
Free software implies full control over anything that runs in my computer. Therefore two questions arise:
- How can I run a modified version of the Javascript code instead of the one loaded by the server?
- How can I be alerted of changes in the Javascript code that the server loads to my browser?
I recently had the tremendous honor to exchange thoughts with the very Richard Stallman about the above issues and he proposed a smart solution to both problems.
Stallman suggests to add a feature to the browser allowing a user to say: “When you get URL X, use the Javascript from URL Y as if it came from URL X.” If the user does invoke this feature, he can run his copy of the Javascript and still being able to exchange data with the server hosting the web application.
A browser with such capabilities could also easily verify if the Javascript from URL X is different from the alternative Javascript stored at URL Y. If the user trusts the present release of the Javascript code from URL X, he could make a copy of it at URL Y and be alerted if any change occurs.
This solution protects the user from malicious code that could be unknowingly executed by his browser, stealing his data and destroying the whole zero-knowledge architecture.
Action points
- Write add-ons for the major free browsers (Mozilla, Webkit, …) that implement the Stallman’s solution.
- Advocate for including the “AGPL Suite” along with the above enhanced browsers into GNU/Linux distributions.