On Fri, Oct 04, 2013 at 04:40:38PM +0200, Adam Back wrote:
Seems to me if people care about anonymous publication security and robustness they need static content, distributed, encrypted and integrity protected. eg like say tahoeLAFS over Tor or something like that.
Thanks for mentioning Tahoe-LAFS, Adam. I think combining Tahoe-LAFS with Tor is a good idea. It is already almost there. It is usable, but it doesn't yet protect your anonymity correctly. There is a recent burst of work to improve usability, security, and performance, and we need help. Also, below, I'll talk about the different, but complementary idea of "decentralized web apps" (i.e. Javascript apps hosted on Tahoe-LAFS). But before we get into decentralized web apps, here's the status of Tahoe-LAFS+Tor: it is currently working, by using a socks proxy that routes through Tor and configuring your Tahoe-LAFS instance to use it. Here are some open issue tickets about tweaks to the Tahoe-LAFS software or documentation which are needed: https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1010# use only 127.0.0.1 as local address https://tahoe-lafs.org/trac/tahoe-lafs/ticket/1349# Improve docs about Tahoe-LAFS+Tor https://tahoe-lafs.org/trac/tahoe-lafs/ticket/517# make tahoe Tor- and I2P-friendly Note that some of these tickets refer to I2P, which is another re-routing network sort of like Tor, but the ones I mentioned above are just as applicable to Tor as to I2P. The tickets mention I2P because I2P developers, in addition to Tor developers, are contributing bug reports and patches. There is a recent move to a better approach which doesn't require the user to configure a socks proxy. That approach is to switch Tahoe-LAFS to using a new network abstraction provided by the "Twisted" library which Tahoe-LAFS uses. That abstraction is named "Endpoints". The idea is to switch Tahoe-LAFS from IPv4 to "Endpoints", and then implement Tor and I2P routing as implementations of the "Endpoints" abstraction. This approach would also probably work with a cjdns transport, too. (Also it would help Tahoe-LAFS work over IPv6.) This approach would also allow other Twisted-based applications (besides Tahoe-LAFS) to use those interesting new transport layers. We could use help! If you know Python, please do code-review of these patches: http://foolscap.lothar.com/trac/ticket/203# switch to using Endpoints How to review patches: https://tahoe-lafs.org/trac/tahoe-lafs/wiki/PatchReviewProcess By the way, we LAFS hackers are well aware that anonymity is very hard. In fact, low-latency anonymity against a modern "global surveillance" threat model may be impossible. But even the anonymity properties that *are* possible, and the ones that are currently provided by Tor, might get ruined by some mistake that Tahoe-LAFS makes, so I wouldn't rely on the Tahoe-LAFS+Tor for anonymity until it has had a lot more study and testing. (Which we need help with!)
Of course not as jscript, form, click etc but thats just asking to be hacked anyway.
I don't quite follow this sentence. You can write code that uses Tahoe-LAFS from Javascript if you want. I think that is a *great* idea, and I think that it is inevitable that in the future "decentralized web apps" will be written in either Javascript + LAFS, or else Javascript + some-other-decentralized- storage-system. However, if you are not ready to accept the inevitable and start running Javascript in your web browser, you can also poke at Tahoe-LAFS from plain old HTML forms, or use Tahoe-LAFS from code (written in any programming language) running on your local machine.
As I recall Zooko mentioned you can actually do that - back a web server in LAFS, then the webserver is nothing but a read-only consumer of LAFS data. Presumably someone can figure out how to route encrypted, authenticated change sets or form submussions back to the underlying LAFS over Tor.
Here's a live demo of a "decentralized web app" in which all storage in an encrypted, decentralized, fault-tolerant storage network, and all computation is in the client -- in fact in the web browser. The demo is my blog: https://zooko.com/uri/URI:DIR2-MDMF-RO:jf3sqg535zufb43iafx7fpmszq:7icvjsf6lt... That link gives you read-only access to my blog. If you interact with it, for example by clicking on "Tags" or using the search box, then you're interacting with Javascript running in your web browser. When *I* interact with it (I have read-write access to my blog), for example by creating new entries or editing existing entries, then I too am interacting Javascript running in my browser. There is no server anywhere that has code for the functionality of my blog. All code that implements functionalit is in the client. The storage server does nothing but store ciphertext to which it doesn't have the decryption key. Now, there's a subtlety here that will probably confuse some people. To be truly *decentralized*, the URL you put into your browser has to start with "http://localhost/", rather than with "http://someone-elses-domain.com/", right? So when you look at the URL above, you aren't actually *using* a decentralized web app, you're looking at a demo of a decentralized web app. To put it another way, when *I* use https://zooko.com, I'm using a decentralized web app, because I control my own node in the network. When I allow *you* to use https://zooko.com, then you are not controlling your own node in the network -- you are relying on me and on my node. But if you install Tahoe-LAFS yourself and connect to the Public Test Grid, then you can join us in playing with true decentralized web apps. :-) Start with the newest version of TiddlyWiki, which comes with a Tahoe-LAFS plugin: https://github.com/Jermolene/TiddlyWiki5/blob/master/plugins/tiddlywiki/taho... (The demo above -- my blog -- is a much older and more kludgey combination of TiddlyWiki and Tahoe-LAFS.) Regards, Zooko