[p2p-hackers] Whistle-blower site platform design

[Len Sassaman]

On Thu, 23 Dec 2010, joss-p2phackers at 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 at 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