Hi, What is going on with that cute otter hidden service publishing project?
What do people think about having it use the Tahoe-LAFS Onion Grid and lafs-rpg instead of telling users to run their own webservers? Tahoe-LAFS could help to greatly increase the security and censorship resistance of the data being published.
If the people involved with this were interested in using Tahoe-LAFS as the data store then I would be more than happy to help out with this. (I don't do any web development at all)
Sincerely,
David
I'm working on a project with the same goals (Stormy), but not sure what the status is for formalized Torstuff.
For me at least I'm not interested in using Tahoe because it adds unnecessary complexity. My work with users typically shows that people have learned or been taught how to use PGP/OTR, but don't have experience as sysadmins and don't have consistent access to advanced technical help. It's also far beyond what most sysops actually need. For WikiLeaks, it might make sense. But for The Dubai Times, it might not and the complexity is more likely to confuse/demoralize people.
~Griffin
On 2014-05-16 01:56, David Stainton wrote:
Hi, What is going on with that cute otter hidden service publishing project?
What do people think about having it use the Tahoe-LAFS Onion Grid and lafs-rpg instead of telling users to run their own webservers? Tahoe-LAFS could help to greatly increase the security and censorship resistance of the data being published.
If the people involved with this were interested in using Tahoe-LAFS as the data store then I would be more than happy to help out with this. (I don't do any web development at all)
Sincerely,
David _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
I think the idea would be to have a web publishing app which doesn't necessarily expose Tahoe-LAFS to users directly, but rather just has a "Publish" button which uploads to it. The only user exposure to Tahoe-LAFS would be that the URLs contain lengthy cryptographic idenitifers (read capabilities). For instance, this is the URL to a page about the Onion Grid: http://etg4ersbwhmvoywb.onion/uri/URI:DIR2-RO:j7flrry23hfiix55xdakehvayy:pn7... This is certainly not something you'd write on paper and expect users to type in, whereas the current 80-bit .onion address might be. But, I believe the hidden service improvements plan includes onion addresses getting a lot longer anyway, so this loss of typability isn't a unique problem here.
What properties does stormy provide? Can I read about it somewhere?
~leif
On Fri, May 16, 2014 at 12:12:40PM -0400, Griffin Boyce wrote:
I'm working on a project with the same goals (Stormy), but not sure what the status is for formalized Torstuff.
For me at least I'm not interested in using Tahoe because it adds unnecessary complexity. My work with users typically shows that people have learned or been taught how to use PGP/OTR, but don't have experience as sysadmins and don't have consistent access to advanced technical help. It's also far beyond what most sysops actually need. For WikiLeaks, it might make sense. But for The Dubai Times, it might not and the complexity is more likely to confuse/demoralize people.
~Griffin
On 2014-05-16 01:56, David Stainton wrote:
Hi, What is going on with that cute otter hidden service publishing project?
What do people think about having it use the Tahoe-LAFS Onion Grid and lafs-rpg instead of telling users to run their own webservers? Tahoe-LAFS could help to greatly increase the security and censorship resistance of the data being published.
If the people involved with this were interested in using Tahoe-LAFS as the data store then I would be more than happy to help out with this. (I don't do any web development at all)
Sincerely,
David
Leif Ryge wrote:
I think the idea would be to have a web publishing app which doesn't necessarily expose Tahoe-LAFS to users directly, but rather just has a "Publish" button which uploads to it.
That would be really cool =) The URL problem is still a problem, but for use cases where url memorability isn't a factor, it would probably be fine. (Such as Crabgrass instances where people are organizing rather than sharing files, or where visitors are mostly following links from the front page.
What properties does stormy provide? Can I read about it somewhere?
The original roadmap/code repo is Github[1]. The project has expanded rather a lot, and I'm happy to talk about it off-list sometime. =)
The basics: a command line wizard that guides users through the install process, adds keys, performs critical server hardening (that most users currently don't do), sets up unattended security updates, sets up their platform of choice[2], sets up the Tor portion & torrc, sets up regular backups, sets up all of the init files and cron jobs, then backs up all config files and keys to a zip for easy retrieval by the user.
I'd love to have guides translated across Tor's 15 supported languages, but that's wishing for too much ;-) Maybe if I write *one* guide, the community will help with the rest. The wizard itself detects language, but because environments tend to be in en_US, that's not as helpful as just giving an option to select language.
best, Griffin
[1] https://github.com/glamrock/stormy [2] There are several good options here that I've used in the past. With an eye toward avoiding Apache, the current roster includes Ghost, Crabgrass, MoinMoin, ejabberd, just a basic webserver, and just hardening. GlobaLeaks and SecureDrop would be perfect for this, but development on both is moving really fast right now.
-
David Stainton -
Griffin Boyce -
Leif Ryge