|
> 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 mich@acmeflakes.com 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. |
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.