Manifesto for the unhosted web from <http://www.unhosted.org/manifesto.html>
Freedom from Web2.0's monopoly platforms. Free/libre and Open Source Software (FLOSS) frees us from having to install proprietary software on our terminals. But installable software is losing ground to hosted software (websites). The server software is often open source (e.g. LAMP), but the website itself as a software product is almost always proprietary. There is an obvious reason for this: Even if an Affero license allows us to download the website's source code, only a commercial company can finance the thousands of servers needed to host a successful website. To make things worse, hosted software has more power over its users than installable software, because it forces you to put your user data on servers owned by the same company that publishes the software. If you want to use Google Docs, you have to reveal your work to a Google-owned server (what Richard Stallman calls "careless computing"). Unhosted I left my dayjob and started the UNHOSTED project to try and stop this. We needed to break the one-to-one link between the software publisher who writes a website (e.g. "Google, Inc") and the "hostage provider" who hosts that website (e.g. also "Google, Inc"). Unhosted creates a simple grease layer in the form of an open web standard (UJ/0.1) between the hosted software and the servers that host it, so this is decoupled. FLOSS-as-a-Service on top of a commodity infrastructure A hosted website provides two things: processing and storage. An unhosted website only hosts its source code (or even just a bootloader for it). Processing is done in the browser, with ajax against encrypted cloud storage. These unhosted storage nodes can be provided by whoever provides your email hosting: your employer, ISP, university, mobile operator, public library, a hobbyist friend who runs a server at home, a hosting company, etc. They become just like mailservers, BGP switches, fibre links and other commodity infrastructure: independent of which application you run on top of them. And they only get to see encrypted data. We probably don't need a lot of storage nodes until unhosted apps really start to attract end users. When they do, everything will degrade gracefully, and users will have an incentive to look for a faster and bigger storage node to migrate to. To maximize the control of the user over his data, migration from one storage node to another will be an integral part of the protocol. Unhosted can in the future be combined with recent projects like Mozilla's Open Web Applications for free-speech "app channels", and is inspired on architectures like tahoe-LAFS for the underlying encrypted cloud storage. how it works Unhosted consists of two parts: the unhosted storage node (a very simple server that receives json-data over HTTP, stores it, and allows you to retrieve it) and a JavaScript library that allows you to interact with these storage nodes from code that runs within the browser. All data is RSA-encrypted and signed before it is sent, and unencrypted and verified when it is received. We used Tom Wu's big numbers library for this. Normally it doesn't make a lot of sense to encrypt user data in the browser using a website's JavaScript, and then send that data to that same website: If the server wanted to see what is inside the encrypted data stream, all it would have to do would be to tinker with the JavaScript. So usually, in-browser encryption is not very useful. But in this case, the host storing the data is different from the host providing the JavaScript. So then it starts making sense. A FLOSS programmer would host his website as purely static content - only the source code. The user logs in with a globally unique identifier (a guid, like an email address) that indicates on which storage node that user's data should be stored. With Cross-Origin Resource Sharing (CORS), the RSA-encrypted JSON-data is sent there, and retrieved from there. Payload-encryption is possible with PGP-encrypted email, but never reached the mainstream so far, probably because it requires extra clicks and actions. With unhosted, we tried to make it "zero-UX": The user doesn't even notice whether the website he is using is hosted or unhosted, unless you tell him. Just like https is zero-UX in that it requires zero clicks from the end user. The webdeveloper only has to call unhosted.set() and unhosted.get() from inside his JavaScript code. fabric-based pki When we implemented all this, and played with a few example apps, we noticed how cumbersome it is to have to deal with people's public keys all the time. If I want to send a message to a new contact, I need not only his guid, but also his public key. In a normal, hosted situation, where you trust the server that hosts (provides persistance for) a user profile, this is easy, you just ask the server what that user's public key is (spki, for instance with WebFinger). But we don't want to trust unhosted storage nodes if we don't have to. That is why we invented what we call a fabric-based public key infrastructure (pki). We call it fabric based, because unlike CA, FOAF and SPKI, it relies on complete strangers to sign other people's keys. We define a deterministic way to "walk" from a given guid to another one. Every guid signs the public keys of "neighbouring" guids, even if he doesn't know who these people are. It helps to create a fabric of users, where the hosting providers have no power to stage man-in-the-middle attack. This pki is the most complicated part of unhosted, and is still quite new and in need of some peer review by people who know about this. current state of the project Apart from the StarSign pki, the rest of unhosted (setting and getting a key, or sending an receiving a message) seems to work in the examples that come with the tarball (see download link above). But it is only a proof-of-concept! Please be aware that the code is still very rough, and it is not well-written yet. We didn't follow any coding standards. Feel free to make fun of it - we ourselves do as well. :) But please don't judge this project by its current code quality, it is only meant to test if this could work, and to get the idea across. We do not, at all, propose anybody use this code in production. And if (unlike me!) you have any JavaScript skills, then please also consider to contribute, instead. We also received some reactions about us currently using twitter instead of identi.ca, and google groups instead of our own lists server. We are thinking about how we can change this, and not be like "vegetarian butchers". For now, please join the project if you like its goals. Even (or especially) if you have some different ideas from what we have done so far. What is done so far is only the start of a meme. We need more people on board to make this a succes! unhosted applications The unhosted infrastructure could form the support for open-source web apps like (or compatible with) diaspora, federated social web, vendor relationship management, bitcoin, and hopefully all hosted services we currently use. Websearch will be the most challenging one because of its inherent centralization, but social search variants (propagating friends-of-friends' recommendations) should definitely be possible on an unhosted infrastructure. Once that is achieved, open source software can become as successful in the "Software as a Service" world as it is in "installed" software. It will help keep Google, Facebook and Apple in check, so they compete on merit only. If you think this project is worthy of pursuing then please download our source code, join our mailing list, or @mention us on identi.ca/unhosted and twitter. We need web developers to start using this as a scalable way to design FLOSS web apps. And if you like a challenge, participate in our Hacky Holidays dev contest, and be one of the first developers to create an unhosted web app. We depend on web developers to create an unhosted web, where all apps are free software, and without commercial companies spying on our data. further reading We recommend you to read Eben Moglen (he started the "Freedom in the Cloud" movement that we are part of), Tim Wu (about internet monopolies), and Glyn Moody (about history, present and future of the open source movement). -- Parin Sharma http://identi.ca/fossmaniac Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html -- -- l...@iitd - http://tinyurl.com/ycueutm
