Nice, seeding a cryptographic! PRNG with math.random(). I'll not comment on the rest of the code, as I'm having trouble following the Javascript here, but I'm not entirely convinced this can create more than one RSA key either...<p>Also, that browser plugin that's mentioned on the page but not in the tarball? Kinda important. Letting the server supply you with arbitrary Javascript code to execute doesn't really get you away from trusting the server.<p>Crypto-in-Javascript is kind of a red flag, and the results so far don't look promising.<p>Oh, and aside from the implementation issues: why'd anyone ever run a server? If you want open source, servers will have to accept data from any application, which pretty much cuts out any way of making money except charging for data storage/server access. And good luck getting people to pay. (Altruistic hobbyists won't cut it for Facebook-scale projects...)
The "Download Code" button just downloads a .tar.gz of code? Doesn't link to the GitHub repo? I mean, either actually describe what 'code' is in this sense (it's a short, simple PHP script, for the curious) or link to the repository. The page itself is hopelessly broad and altruistic without giving any details of the solution, and I'm pretty unimpressed with this code if it aims to be anything more than a proof of concept.
I like the big idea behind this project. Ever since the cloud has started to come into its own I've thought that the trust problem is going to be a big one to solve. That being said I think the approach here is all wrong. To me the cloud isn't the cloud if it is just storage, it needs to store and do the heavy computing.<p>I think the best way to fix the trust problem is to find a way to make the user the one who owns the server. In other words the cloud software should not run on Google's, Apple's, or Microsoft's servers but on a server owned by the user.<p>Of course users will not want to manage their own server, lease the data center space, etc. So the trick will be to abstract that away for them to make it as simple as managing their own desktop or notebook computer.<p>I could imagine a time where you install cloud apps on your own server by licensing them just like you do local software.
This is similar in spirit to the CouchApp platform we've been building into Apache CouchDB. More info here: <a href="http://couchapp.org" rel="nofollow">http://couchapp.org</a>
> No server-side processing.<p>You lost me at hello. While it might seem like a cool P2P idea to remove the central authority of the server, its removal leaves a vacuum of responsibilities. How do you prevent cheating (setting personal bank account to $1,000,000.00), how do you coordinate events (send DM/Notification to clients when a resource changes), how do you handle transactions?<p>Maybe I'm out of date and all those distributed techniques are known, but I don't think so.
My, how times have changed for FLOSS. The project aims to "help keep Google, Facebook and Apple in check" with Microsoft making not so much as a blip on the radar.
I'm planning on incorporating something like this, but it's wayyyy in the future.<p>Right now I am working on a distributed social network, where you own your data. That means if you are hosting it and your machine goes down, then your non-public data is inaccessible to others because your machine is the master source of authorization for who can see it and who can't.
If you just want to build a client app why not build a native one that saves it's data to the cloud instead of restricting yourself to the HTML stack and jumping through all kinds of crazy AJAX hoops? The first step on this project should be creating the storage/permissions protocol that all apps can use. The data is what's important here, not the client app, you have to trust the client app developer if you're going to use his app.
I think he's hit on an important idea. I'd say take it even further - create a distributed datastore amongst all the browsers running on the internet. My laptop has gigabytes of extra storage i could easily part with, and a low priority background process would be unnoticeable. The internet connection speed would be the bottleneck, also peer discovery is a hard problem.
I believe this is very interesting, even perhaps the way of the future for SaaS business apps.<p>Consumers and small businesses are more easy going about having their info hosted elsewhere. But medium to large businesses, maybe because of the competitive nature of the activity and the huge amount of resources at their disposal, are more wary of having their data stored where it's "out of their control".<p>Although many businesses have adopted "the cloud" for certain activities i believe most computation is still done in-house, even if there are some disadvantages to it. A platform that enables them to keep the information to themselves while taking advantage of better infrastructure providers would certainly accelerate the adoption of "cloud" technologies for new applications.<p>There still remains the problem of legacy systems, which through virtualization will be more easily transported to a "cloud" provider.<p>So let's see what happens, good luck on your enadeavor.
I'll go out on a limb and declare the proposed scheme wacky. Why? It ignores so much of the way software brings value to my life.<p>Let's take Mint.com as an example. One could certainly build a Quicken-style application with the Unhosted platform which would perform its processing on the browser but save all data to a server in an encrypted form. Users would be able to access their data from any browser. What's broken is that a core part of Mint's value proposition is that it watches out for you and proactively tells you important stuff. Did you know that your credit card bill is due tomorrow? Mint.com sends you an email. If Mint.com did not have unencrypted access to your data, it could not provide you with this service. You would be back in the dark ages of Quicken when you had to remember to use the application to get such information.<p>The in-the-cloud services which provide the most value to me could not exist without being able to process my data in the background. A more interesting idea to consider is whether the ownership of the hosted software could be decoupled from the hosting provider. There seem to be a few open source projects out there which aim to provide AppEngine-like frameworks which could allow hosting of one's application as-is by a bunch of cloud hosting services. Think AppEngine with choices. What if someone produced an open source, GMail-like appliance bundle built for one of these frameworks? It could be deployed by an individual/company/whatever to a hosting provider's cloud. Included in the project would be easy ways to migrate from to another hosting provider, data export, etc.<p>Although such solutions would solve the background processing requirement problem, they would still require me to think about my email platform. Is it time to upgrade? Which provider should I use? Etc, etc. The likely market outcome would be that hosting providers would offer "managed" hosting of these open source appliances. What's the difference between this state of affairs and the current GMail/Hotmail/etc. landscape? Probably little more than an open standard for data interchange along with an easy way to export one's data.<p>The problem with such SaaS concerns is the same as with Java in 2004 when Stallman wrote about "the Java trap". Most people (me included) saw Sun as a benevolent dictator and didn't worry much about what could go wrong. Now that we've witnessed Oracle's apparent power, we know to be afraid. Perhaps there are some small examples of SaaS gone awry, but it's not like SalesForce.com has doubled its prices and throttled data export to keep users from running.<p>Today, no one thinks to demand complete data export capabilities along with a contractual agreement to continue to provide them. What if customer demand made such features commonplace? An upstart Mint.com competitor could offer Mint.com data import to reduce switching costs. Would such a state of affairs appease the majority of SaaS lock-in concerns?<p>I personally don't see what all the fuss is about. Whenever humans work together in any form to better their lives, they give up some control and risk that others will not act in their interests. The risk and uncertainty are a matter of degree rather than kind. The guy who plows my driveway could decide to run off to Vegas, and I wouldn't know until the next major snowfall. Wouldn't I be better off to operate my own plow so that I have the control? By this same logic, I would be better off running my own servers and maintaining my own applications. With the snowplow guy, the magnitude of my risk is capped -- if he doesn't show up, I can call up a competitor and have him take over the contract. Similarly, smart humans assess the risk of trusting others and make sure that their agreements do not provide too much power to the counter-party. The issue is that we as humans have learned over time what kinds of risks are inherent in various sorts of transactions, and the invisible hand has responded with defacto standards for agreements which constrain these risks to acceptable levels. It is that SaaS is so new that most people are unable to assess the risks of various offerings, so those which transfer power to the provider in extreme ways are not so obviously evil.
Without server-side processing you can't do progressive enhancement on HTML and make your work a usable contribution to the world-wide web of hyperlinked resources. I can't advocate a scheme which will only result in more silos of broken javascript-only crap out there, especially when we still don't have any javascript sandboxes that warrant the trust people put in them.