How to move personal publishing to the desktop

You can do everything "in the cloud" these days, from blogging to posting photos to running servers. Most impressively, you can now also lose control of your files and personal information with unprecedented ease, or simply lose it, period. This is exactly the worst possible feature for the personal publishing use-cases of cloud computing. Possibly the most distressing aspect of cloud-based publishing is that it firmly designates the intangible network as the primary resting place of one's data. (I will note here that this aspect is itself what I am using to define "cloud computing" for the purposes of this blog post.) If the first place you put your creations is some hosted service on the great wide interwebs, you're playing with fire.

As it stands, the cloud is not safe for primary storage. I lost some data in the Magnolia bookmarking service fiasco myself, with my most recent backup several weeks before the crash. I only backed up my bookmarks when I remembered to, not having the time to work up an automated downloading script. Now I save all my bookmarks locally, and my twice-weekly backup takes care of everything. My online photo gallery is not in any similar danger, because I wrote it myself with such a failure mode in mind. The photos and tags and descriptions live on my laptop and propagate from there out to my public website. Images and tags that I don't want to be public never even leave my machine.

Why do people use the cloud, then? To put it simply, front-end convenience. I can create a Flickr or Numsum account in minutes, and right away I have a URL I can point my friends to to see what I have created. The cost (lost data) only comes much later. These hosted applications also present a reduced computer security risk to users, compared to desktop-based publishing software such as my photo gallery uses. If you want to use my application, you have to trust my code and run it on your own machine. However, Flickr only runs Javascript on your machine, safely sandboxed in your browser.

I want all of our current hosted-publishing systems move to the desktop. Clearly, a competitive answer to the cloud/hosted systems of today must compete on both convenience and easy security. Using an application must be as easy as surfing the web, and publishing photos, text, and video must only take a few clicks of the mouse.

What I envision is a desktop platform that allows users to download from the web and run (in a sandbox) any compatible software in a single click, where each application is given fine-grained permission to talk with other applications, read and write user data, and publish to the web, and a peer-to-peer communication system for non-public publishing (e.g. LiveJournal-like friend-locked blogging.) Since most users will not have always-on desktops, communications and storage would be optionally mediated by paid and freemium hosted services serving only as relays for encrypted user data.

With this imagined software, a user would be able to get started with photo publishing by finding a good-looking gallery application's website, clicking a special URL, and approving installation. Perhaps the user would then approve the application's request for 1) read-only access to a specified photo directory and 2) publishing permissions (to the public web, approved peers' inboxes, and relay servers). The application might provide a tagging and organization interface itself, or possibly just scrape data out of KPhotoAlbum, FSpot, and Picasa's databases. The user would connect certain tags to defined groups in their master contact list, allowing e.g. grandparents to be shown different sets of photos than coworkers.

Now imagine that at platform installation time, users are provided with a brand-new set of encryption keys and instructed how to hold key-signing parties, assisted by the platform's authentication module. Privacy-sensitive content (photos, blog entries, video, source code) would be created on the desktop, encrypted to group and personal public keys, distributed on personal and paid servers or via P2P, and downloaded to peer machines. At no point would the prime copy of a user's creations be offsite -- and at no time would personal information be out of the control of the user or those they trust with it.

This project is totally feasible in technical and social terms. It could revolutionize user privacy and even be the required bootstrap for layman's practical encrypted communication. It just needs the right group of people to start the work. Comment if you think you could be one of those people.


Responses: 5 so far

  1. nablacdotu says:

    I'm (once again) reminded of http://xkcd.com/743/

    Actually, if I understand it correctly, iOS is already halfway there, in that each app is already sandboxed from the rest of the system. (http://developer.apple.com/library/ios/#documentation/iphone/conceptual/iphoneosprogrammingguide/RuntimeEnvironment/RuntimeEnvironment.html)

    Of course, Apple holds the keys, not you.

  2. Tim McCormack says:

    Yeah, I like the concept of the app store, but I'm not familiar with how their sandboxing works. I don't really follow mobile development news, but I thought I heard something about Android apps with malware in them.

  3. Alex Feinman says:

    It looks like you're using "the cloud" to mean "machines not directly under my control, which I access over the network".

    And you're highlighting, primarily, the very poor backup policies of most machines not under your control. This is a real issue, but I don't think that a move to "the desktop" is the right way to think about it.

    What do you want?

    1. Some realistic guarantee that content you have now will be available in the future.
    2. Some realistic guarantee that functionality you have now will be available in the future.
    3. Veto power over how 'your' content is used (e.g., whether your Facebook pictures are used to sell products to your friends).

    These are three separate goals, and vary wildly in how hard they are.
    Easy backup/restore may be the best solution for 1. But the other two may be a bit harder, given that the people providing that functionality depend on 2 and 3 to make a profit...

  4. ethan says:

    how does what you're talking about relate to this:
    http://diasporafoundation.org/

  5. Tim McCormack says:

    Update: It looks like RetroShare is trying to do something like this, although the software is pretty rough so far.