
Unhosted - Freedom from web 2.0's monopoly platforms - yungchin
http://www.unhosted.org/manifesto.html
======
JoachimSchipper
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...

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...)

~~~
EGreg
"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.

~~~
JoachimSchipper
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...

~~~
EGreg
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.

~~~
JoachimSchipper
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?

~~~
JoachimSchipper
EGreg - if everyone will have to re-establish trust for each new release,
what's the advantage?

~~~
EGreg
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.

------
tmcw
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.

~~~
mich-unhosted
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.

------
macinjosh
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.

------
jchrisa
This is similar in spirit to the CouchApp platform we've been building into
Apache CouchDB. More info here: <http://couchapp.org>

------
praeclarum
> 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.

~~~
ThomPete
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?

~~~
fleitz
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

~~~
TomasSedovic
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.

------
whatevermatt
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.

------
EGreg
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.

------
guelo
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.

~~~
mich-unhosted
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.

------
donpdonp
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.

~~~
jaen
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.

------
joseakle
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.

~~~
mich-unhosted
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 :)

~~~
joseakle
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.

------
ShabbyDoo
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.

~~~
tzs
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.

~~~
ShabbyDoo
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.

------
prodigal_erik
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.

------
mich-unhosted
We updated the page this links to, but added a link to the previous version
for reference.

