Unhosted - Freedom from web 2.0's monopoly platforms(unhosted.org)
unhosted.org
Unhosted - Freedom from web 2.0's monopoly platforms
http://www.unhosted.org/manifesto.html
46 comments
"Letting the server supply you with arbitrary Javascript code to execute doesn't really get you away from trusting the server."
BINGO! That is the biggest problem with current web technology today. We need to have some kind of mechanism for delivering STATIC content, content that can be verified by independently downloading a hash from somewhere that you trust, and making sure the file is the same. This download has to happen through the browser itself, and not be initiated by javascript.
BINGO! That is the biggest problem with current web technology today. We need to have some kind of mechanism for delivering STATIC content, content that can be verified by independently downloading a hash from somewhere that you trust, and making sure the file is the same. This download has to happen through the browser itself, and not be initiated by javascript.
Do you have a proposal? Something like "code signing" for HTML/JS would be doable in theory, but where do you get the keys from? If you re-use the certificate authority infrastructure, you've only complicated things; a web-of-trust may work for some early adopters, but look at PGP's lack of mainstream success to see how that would work out...
Yes, I have a proposal.
Similar to how we have https:// blabla, and the user agent warns us if the server's certificate is not trusted, we should have httpc:// blabla to indicate constant files. Sites all over the world can download urls from httpc:// and store hashes to them in various formats, and your user agent can trust one or more of these authorities. When downloading, it would compare the hashes against the ones downloaded from these authorities, and if there is even a small deviation, it would give you a warning just like https://
I can see this being used in app stores for the web (curating apps and various versions of apps, like Apple does) and also for secure logins. I would like someone to make guarantees that my password is not being sent in the clear to the server that I am connected to. Currently with web tech it's impossible to be sure you aren't revealing sensitive info to the server. This simple change would make possible a variety of applications that we haven't even thought of, besides these two.
Similar to how we have https:// blabla, and the user agent warns us if the server's certificate is not trusted, we should have httpc:// blabla to indicate constant files. Sites all over the world can download urls from httpc:// and store hashes to them in various formats, and your user agent can trust one or more of these authorities. When downloading, it would compare the hashes against the ones downloaded from these authorities, and if there is even a small deviation, it would give you a warning just like https://
I can see this being used in app stores for the web (curating apps and various versions of apps, like Apple does) and also for secure logins. I would like someone to make guarantees that my password is not being sent in the clear to the server that I am connected to. Currently with web tech it's impossible to be sure you aren't revealing sensitive info to the server. This simple change would make possible a variety of applications that we haven't even thought of, besides these two.
I don't really see how httpc:// would make HTTPS logins work better. Can you explain?
Some sort of "distributed checksumming" like your first example may be useful for myapp-1.0.0.dmg or jquery-1.4.4.js, but how would you handle upgrades?
Some sort of "distributed checksumming" like your first example may be useful for myapp-1.0.0.dmg or jquery-1.4.4.js, but how would you handle upgrades?
distributed checksumming is what I am talking about
upgrades should be done by putting the new version at a DIFFERENT url. As tim berners-lee says, cool uris don't change: http://www.w3.org/Provider/Style/URI
upgrades should be done by putting the new version at a DIFFERENT url. As tim berners-lee says, cool uris don't change: http://www.w3.org/Provider/Style/URI
EGreg - if everyone will have to re-establish trust for each new release, what's the advantage?
what is the advantage of magazines having to review every new version of software?
httpc:// would be used for logins and distributing software. People already publish checksums, this would just be an automatic way of verifying every file that the server claims is constant.
httpc:// would be used for logins and distributing software. People already publish checksums, this would just be an automatic way of verifying every file that the server claims is constant.
JSON is static content. Open an HTML page you trust and have that load the JSON data you want and use it to populate the DOM, making sure to escape HTML characters so it can't inject script tags and such.
The point is to be able to guarantee properties of a resource that is delivered to you via the internet. Whether it contains JSON or not, you are trusting the server. With current web technology you don't have an option.
> Nice, seeding a cryptographic! PRNG with math.random().
that file is part of the JavaScript Big Numbers library by Tom Wu, which unhosted builds on top of. sorry if that wasn't clear, maybe i should create subdirs to better indicate code provenance. it is not something we did ourselves! It looks very difficult to us. ;)
> browser plugin that's mentioned on the page but not in the tarball? sorry! misunderstanding - we originally worked on a plugin, then found Tom Wu's library, and switched to that. It works without a plugin and aims to be "zero-UX" for the end-user. It was an old text - I updated the page to correct this.
> Crypto-in-Javascript is kind of a red flag yes, we are aware of this issue. but our case is different - the updated manifesto page mentions this (sorry, if i knew we would be on HN i would have made sure the web was more current first! ;). The idea is I trust the publisher of the source code. Be it the author, an app channel, etcetera. But I do not trust the storage node that holds my data. The ajax calls are cross-origin resource sharing (CORS). You trust the URL you visit (along with the DNS pointing to it, and unless it's https, all hops inbetween). the encryption only comes into play when your browser does the CORS calls to the unhosted storage nodes.
> why'd anyone ever run a server? One of the most important questions, and one we discovered several possible replies to. If you offer an unhosted facebook, your main worry will be if end-users will use it at all, rather than too much, so quite the opposite. Once it's up and running with a small number of nodes, end users will have a need for unhosted storage nodes, and various parties could be willing to provide that.
The author of an app might have reasons to do so. If all app-authors provide their own resources then we did not gain anything yet, because there still is the connection between app author and hosting costs. But the apps could peer, and gain scalability with pooling. 100 startup companies could share 5 or 6 unhosted storage node in the building they share, and if one company becomes successful, it will scale because of the pooling. After that, altruists could step in for apps with no startup company behind them (look at wikipedia running 300 servers off donations), as may whoever provides connectivity: a university, an employer, an ISP, etcetera. Whenever unhosted becomes more successful than the number of existing nodes, the end-user will experience fail-whales, and ask around for faster and more responsive nodes.
Ask yourself: who runs your mailserver? Why do they volunteer to give you an email address? Different reasons. But taken together, email forms a distributed application, way more desirable than one centralized facebook-messages. When email started, universities were the ones installing the first servers. It didn't cost much, because there wasn't any traffic yet. If traffic on unhosted storage nodes grows, it is because somewhere, an end user is enjoying the service. That is useful.
Imagine I get a free unhosted storage node with my cornflakes. I might remember how slow HN was yesterday evening, and buy those cornflakes. Then people will see [email protected] appear on HN as my guid. Or people would see me use my HN account on slashdot. Every guid contains a well-deserved advertising space behind the @-symbol. It would all (hopefully) become an ecosystem.
> browser plugin that's mentioned on the page but not in the tarball? sorry! misunderstanding - we originally worked on a plugin, then found Tom Wu's library, and switched to that. It works without a plugin and aims to be "zero-UX" for the end-user. It was an old text - I updated the page to correct this.
> Crypto-in-Javascript is kind of a red flag yes, we are aware of this issue. but our case is different - the updated manifesto page mentions this (sorry, if i knew we would be on HN i would have made sure the web was more current first! ;). The idea is I trust the publisher of the source code. Be it the author, an app channel, etcetera. But I do not trust the storage node that holds my data. The ajax calls are cross-origin resource sharing (CORS). You trust the URL you visit (along with the DNS pointing to it, and unless it's https, all hops inbetween). the encryption only comes into play when your browser does the CORS calls to the unhosted storage nodes.
> why'd anyone ever run a server? One of the most important questions, and one we discovered several possible replies to. If you offer an unhosted facebook, your main worry will be if end-users will use it at all, rather than too much, so quite the opposite. Once it's up and running with a small number of nodes, end users will have a need for unhosted storage nodes, and various parties could be willing to provide that.
The author of an app might have reasons to do so. If all app-authors provide their own resources then we did not gain anything yet, because there still is the connection between app author and hosting costs. But the apps could peer, and gain scalability with pooling. 100 startup companies could share 5 or 6 unhosted storage node in the building they share, and if one company becomes successful, it will scale because of the pooling. After that, altruists could step in for apps with no startup company behind them (look at wikipedia running 300 servers off donations), as may whoever provides connectivity: a university, an employer, an ISP, etcetera. Whenever unhosted becomes more successful than the number of existing nodes, the end-user will experience fail-whales, and ask around for faster and more responsive nodes.
Ask yourself: who runs your mailserver? Why do they volunteer to give you an email address? Different reasons. But taken together, email forms a distributed application, way more desirable than one centralized facebook-messages. When email started, universities were the ones installing the first servers. It didn't cost much, because there wasn't any traffic yet. If traffic on unhosted storage nodes grows, it is because somewhere, an end user is enjoying the service. That is useful.
Imagine I get a free unhosted storage node with my cornflakes. I might remember how slow HN was yesterday evening, and buy those cornflakes. Then people will see [email protected] appear on HN as my guid. Or people would see me use my HN account on slashdot. Every guid contains a well-deserved advertising space behind the @-symbol. It would all (hopefully) become an ecosystem.
Ah, I didn't expect a response. Nice.
I totally missed the part where you're willing to trust the server providing your Javascript (but not the storage node). That is a much more feasible design. Thanks for clarifying.
With respect to generating keys: PuTTY uses a blank rectangle and says "please randomly mouse over this". There's a simpler solution, though: since you're willing to trust a server, you can just let that generate a key for you.
Again, thanks for the clarification. You still have some chicken-and-egg problems to overcome, and you'll need to convince people to code in this way, but I'm happy to see that the basic design isn't as impossible as I'd feared.
I totally missed the part where you're willing to trust the server providing your Javascript (but not the storage node). That is a much more feasible design. Thanks for clarifying.
With respect to generating keys: PuTTY uses a blank rectangle and says "please randomly mouse over this". There's a simpler solution, though: since you're willing to trust a server, you can just let that generate a key for you.
Again, thanks for the clarification. You still have some chicken-and-egg problems to overcome, and you'll need to convince people to code in this way, but I'm happy to see that the basic design isn't as impossible as I'd feared.
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 updated www.unhosted.org/manifesto.html to include some more info on how it works.
the code does not claim to be anything more than a proof of concept. As you say, it's a silly 100-line php script, nothing more than that. it is also not very well-written, especially the unhosted.js and hutch.js files (i didn't have any JavaScript background when i started the project, nor did i try, at all, to write production-grade code). But we hope it does, as it were, 'proof the concept'.
i will make the link to the github page (as opposed to the tarball) more prominent, sorry for that.
the code does not claim to be anything more than a proof of concept. As you say, it's a silly 100-line php script, nothing more than that. it is also not very well-written, especially the unhosted.js and hutch.js files (i didn't have any JavaScript background when i started the project, nor did i try, at all, to write production-grade code). But we hope it does, as it were, 'proof the concept'.
i will make the link to the github page (as opposed to the tarball) more prominent, sorry for that.
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.
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.
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.
I could imagine a time where you install cloud apps on your own server by licensing them just like you do local software.
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.
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.
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: http://couchapp.org
> No server-side processing.
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?
Maybe I'm out of date and all those distributed techniques are known, but I don't think so.
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?
Maybe I'm out of date and all those distributed techniques are known, but I don't think so.
I think you've misunderstood what he's proposing. He's talking about getting rid of server processing of client data, such as spreadsheets, word processing documents, schedules, and so on. Things where the data is all yours.
Your bank balance is not your data. That's the bank's data. All you have is a cache of its recent value. If you want to set that cached value to a million dollars that is fine. The bank will still have the correct amount, and that is what determines how much money you actually have.
Your bank balance is not your data. That's the bank's data. All you have is a cache of its recent value. If you want to set that cached value to a million dollars that is fine. The bank will still have the correct amount, and that is what determines how much money you actually have.
It seems a little preemptive to dismiss this idea and frankly I don't think you are looking at this in the right perspective. Trust could be built over time between both the people and their account.
I for one welcome a future where my social interaction isn't a product or service owned by anyone else but myself.
Why so fast to dismiss it?
I for one welcome a future where my social interaction isn't a product or service owned by anyone else but myself.
Why so fast to dismiss it?
I don't think I understand what they are proposing here. When I read this it sounds like a simple return to client applications. The workflow sounds like:
1) I go to the web to download the application.
2) Once I have the application I run it locally.
3) I encrypt and save the data back to "the cloud". Since I own the data, I can specify where to save it and the "web" becomes nothing more than distributed storage.
This is nothing I can't already do if I choose. We already have things like Silverlight applications, Java applications, Flash applications, etc. that all run client-side in the browser. Throw in ClickOnce deployment from Microsoft (which installs a .NET application directly to your computer by visiting a website and agreeing to the install), the linux app repositories, or even just the old "purchase and download" model, and I do not see how this proposal solves a technical problem we currently have - and if it is not a technical problem, then proposing a technical solution isn't going to solve it.
If I understand the intent, it is to prevent companies from owning the data that we create. Where the code executes does not seem to be relevant.
1) I go to the web to download the application.
2) Once I have the application I run it locally.
3) I encrypt and save the data back to "the cloud". Since I own the data, I can specify where to save it and the "web" becomes nothing more than distributed storage.
This is nothing I can't already do if I choose. We already have things like Silverlight applications, Java applications, Flash applications, etc. that all run client-side in the browser. Throw in ClickOnce deployment from Microsoft (which installs a .NET application directly to your computer by visiting a website and agreeing to the install), the linux app repositories, or even just the old "purchase and download" model, and I do not see how this proposal solves a technical problem we currently have - and if it is not a technical problem, then proposing a technical solution isn't going to solve it.
If I understand the intent, it is to prevent companies from owning the data that we create. Where the code executes does not seem to be relevant.
Projects like this never take off. Code first then announce. Also, it solves a problem no one has.
Also the idea of owning a social interaction yourself seems silly and inconsiderate to others. If you don't like facebook just delete your account
Also the idea of owning a social interaction yourself seems silly and inconsiderate to others. If you don't like facebook just delete your account
The code is on github, they link to it from the page.
And personally, I do have the problem this attempts to solve. Whether this is the right solution to it I don't know. But the problem does exist.
And personally, I do have the problem this attempts to solve. Whether this is the right solution to it I don't know. But the problem does exist.
>Why so fast to dismiss it?
Because there are genuine legitimate questions about how this infrastructure can support a lot of fundamental web application work flows and processes?
I'd welcome a future like that too, but I had the same reservations. Raising pertinent questions isn't the same as dismissing something.
Because there are genuine legitimate questions about how this infrastructure can support a lot of fundamental web application work flows and processes?
I'd welcome a future like that too, but I had the same reservations. Raising pertinent questions isn't the same as dismissing something.
* Because there are genuine legitimate questions about how this infrastructure can support a lot of fundamental web application work flows and processes? *
Sure there are.
But before they are answered why not give them the benefit of doubt?
Do you like what they attempt to do? Then why not suggest how they could improve it?
Sure there are.
But before they are answered why not give them the benefit of doubt?
Do you like what they attempt to do? Then why not suggest how they could improve it?
Bank accounts can't be done without letting the bank know a lot of things about you anyway, and I can imagine a "ping me on changes to resource xyz" extension to handle the second problem.
That said, I do agree with you that this isn't the most... convenient... model.
That said, I do agree with you that this isn't the most... convenient... model.
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.
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.
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.
Communication between app and unhosted storage node is over HTTP, yes. In the current version. But the unhosted storage node wouldn't care if it's a browser or a desktop app / phone app / tablet app that's talking to it.
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.
That's what DHT's like Kademlia were invented for, used by P2P systems such as ed2k (eMule), BitTorrent decentralized tracking, and "web-scale" software such as memcached and friends.
I believe this is very interesting, even perhaps the way of the future for SaaS business apps.
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".
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.
There still remains the problem of legacy systems, which through virtualization will be more easily transported to a "cloud" provider.
So let's see what happens, good luck on your enadeavor.
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".
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.
There still remains the problem of legacy systems, which through virtualization will be more easily transported to a "cloud" provider.
So let's see what happens, good luck on your enadeavor.
I hadn't even thought of that angle! i guess businesses also have civil rights online. :) and mainly: it might help us bootstrap the ecosystem. thanks!
it means we should write the unhosted storage node in AWS, GoogleApps, etc, because that is what these businesses will want, right? should be trivial, i'll put this on the tasks list :)
it means we should write the unhosted storage node in AWS, GoogleApps, etc, because that is what these businesses will want, right? should be trivial, i'll put this on the tasks list :)
Well, i´ll tell you as a SaaS provider to small bussinesses and web software provider to large enterprises.
The main reason we sell to large enterprises an on premise solution is because they basically don´t trust us or our platform providers (aws, appengine) with their info.
Just look at github firewall install and other on premise solutions, they are available because of a fundamental and justified lack of trust on third parties.
Good luck on the civil liberties (rights) angle, i believe it´s not such a utopian but more of a practical concern who you trust your info to.
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.
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.
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.
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.
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.
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?
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.
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.
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.
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.
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.
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?
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.
I disagree that this idea is incompatible with this usage profile. You could have your personal computer do alert processing on the box itself, and either setup a system of unencrypted alert messages, or have it ping you every once in a while.
The main idea here is to only allow your personal information off of your own computer in an encrypted form. This seems like a pretty good place to aim for in the future.
The problem isn't lock-in as much as it is privacy. It is better for consumers for all of their private data to be private as they use the internet, instead of having the rely on trusting someone else with the data. Part of the concern is lockin - as in what happens if the service changes their policies or disappears. But this is not the whole picture
The main idea here is to only allow your personal information off of your own computer in an encrypted form. This seems like a pretty good place to aim for in the future.
The problem isn't lock-in as much as it is privacy. It is better for consumers for all of their private data to be private as they use the internet, instead of having the rely on trusting someone else with the data. Part of the concern is lockin - as in what happens if the service changes their policies or disappears. But this is not the whole picture
As far as your mint.com example goes, such notification could still be provided without the server knowing that your credit card bill is due tomorrow. The client can tell mint.com when notice is due, and provide an encrypted blob of data to be sent as the notice. Essentially mint.com would just need to provide a cron service to the client.
When I thought of this example, I had imagined Mint.com querying my credit card company to ask what the due date was and whether or not I had already paid the bill.
>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.
That's a terrible example. If this is your primary argument for web services, then they've been obsolete since cron came with UNIX V7 in 1979.
On Mac OS X, without even running the app, iCal has no problem sending me an email to notify me of an upcoming event. How does it accomplish this magical feat? It runs a background process that just happens to have access to my local calendar database, because it's already on my computer.
>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.
And you would have a very difficult time actually using those services without access to a personal computer that already has far more resources at hand to do the same processing itself.
That's a terrible example. If this is your primary argument for web services, then they've been obsolete since cron came with UNIX V7 in 1979.
On Mac OS X, without even running the app, iCal has no problem sending me an email to notify me of an upcoming event. How does it accomplish this magical feat? It runs a background process that just happens to have access to my local calendar database, because it's already on my computer.
>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.
And you would have a very difficult time actually using those services without access to a personal computer that already has far more resources at hand to do the same processing itself.
Yes, and your local computer must be on, the software must be running, etc. Want that email delivered to your phone, your work computer, etc.? My example is hardly the best one, but it was simple and commonly understood.
Yes, many apps will benefit from an always-on server. Must we rely on a Mega Corp just for some strange desire to turn everything off?
If you don't turn your computer on at least once a day, then chances are you aren't reading your email on it.
Run your calendar/bill-reminder software on the machine you use the most (which you'd do naturally, anyway) — whether it be your phone, your laptop, or wherever — and the justification for remote hosting collapses.
Run your calendar/bill-reminder software on the machine you use the most (which you'd do naturally, anyway) — whether it be your phone, your laptop, or wherever — and the justification for remote hosting collapses.
Unless you're away from your usual location for a couple of weeks, in which case this type of remote hosting is pretty darn useful (unless your primary computer is your smartphone, but not everyone has one).
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.
We updated the page this links to, but added a link to the previous version for reference.
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.
Crypto-in-Javascript is kind of a red flag, and the results so far don't look promising.
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...)