On Thu, 23 Dec 2010, joss-p2phackers@pseudonymity.net wrote:

I think that it's worth re-emphasising what you say in your second point: an idea like this is not going to succeed if it relies too heavily on solving the fun technical problems. Creating a theoretically nice leak submission/distribution system is definitely fun work, and I'd love to come and play, but if it were to be truly applicable then there is probably going to have to be serious compromise made in the security/usability stakes.

Absolutely agreed. I don't, personally, see it as a "compromise" to security that concessions are made to usability, given that usability is a factor in security. In fact, in this case we really must assume no technical sophistication on behalf of the whistleblower (and if some of the leaksites that have popped up are any indication, only minimal technical prowess on behalf of the site operators.)

(On that point: does Wikileaks' submission system rely on a Tor hidden service, or is there one running that you can use if you jump through the right hoops?)

I believe it's the former, but I'm not certain. Can anyone comment?

A website seems necessarily the right model for access and submissions, or at least for kicking off a submissions process. Computer = Internet = web (and maybe email) for most people, and breaking that assumption is counterproductive. No-one reading non-existent submissions isn't the goal.

Agreed.

A threat model for source protection is surely going to be sender anonymity against the standard global passive attacker. How you bootstrap that from a "click here to submit" button will be interesting. As you point out, though, we aren't seeing a great deal of technical attacks against source anonymity. While it's definitely a real threat, I'd say it's lower on the list of priorities than the availability problems.

Agreed, though it remains a real problem. But we can divide the components of such a system so that working on solving the one doesn't block on solving the other. [snip]

actual URL (see, for example, http://rww.to/a4egy9 ). The real-world net censorship we see is akin to censoring a library by burning the catalogue.

Very well put.

The critical Eternity Service (and Freenet) issue of hosts being ignorant of the data that they carry will be important in resisting more legal attacks.

I'm not sure we should get hung up on that; that argument always stuck me as "legal cleverness" of the sort judges laugh at. If the purpose of this platform is to disseminate documents in the public interest, which happen to upset some legal entities be they corporations or governments, the "public interest" argument is what's going to keep them online, imo. Further, "But I don't technically know what I'm hosting" isn't going to change Amazon's mind when they want to pull the plug on you.

Corruption of the leaks via injection of false documents seems an orthogonal problem, and I'm not sure how you'd automate that.

So, I'm imagining a system where the "leak site" receives files from a source (somehow; we want this to be an anonymous submission process but it can be treated as a black box), *reviews them and selects documents for publication*, and then pushes them to a document distribution platform, which should be syndicated to mirrors to leverage jurisdictional arbitrage and affect censorship resistance. The problem of false documents entering the distribution process is one of human error; however, the leak-site operators are acting in the role of journalists, and the onus is on them to authenticate their source material. I don't think a technical fix is in order here. One thought I should mention: on the submission side, it would be very nice to have a built-in metadata stripper either as part of the submission process, or as part of the publication process. Where you put it depends on whether you want the leaksite operators to have access to potential metadata or not; arguments can be made either way. But we can't assume either party is sophisticated enough to worry about this themselves. (Nor can we expect to produce a metadata redaction filter that is anywhere close to comprehensive, and metadata will continue to be a major attack vector for outing whistleblowers, but the protections provided by this system are not binary.)

Anonymous access to the data seems to fit very neatly into Tor's use-case, with the assumption that you mainly want a web interface. For large chunks of data you might want something able to handle that kind of load, and could probably tolerate higher latencies, but again you'd probably want to start looking at building on a BitTorrent-style approach.

I've used BitTorrent in conjunction with anonymous publication systems before; it served as the distribution protocol for the design of a Private Information Retrieval based nym server Bram and I proposed a few years back. I'm considering the suitability of PIR in the present use case; it turned out that our use of BitTorrent opened the system up to certain attacks on the querant's anonymity, but that may not apply in our use case. (For reference: http://www.abditum.com/pynchon/ ) --Len. _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://www.ativel.com http://postbiota.org 8B29F6BE: 099D 78BA 2FD3 B014 B08A 7779 75B0 2443 8B29 F6BE