[p2p-hackers] Whistle-blower site platform design

[Len Sassaman]

On Thu, 23 Dec 2010, Ian G wrote:

> If I think of the 3 whistleblower cases I'm mildly familiar with, there
> is no commonality between the source protection aspects.  I think this
> might be something where whatever technical system you put in place, a
> wise whistleblower would not be keen to trust it.  Given that the
> typical cost of being a whistleblower is probably minimum loss of income
> for years, and loss of liberty likely, it might be a really high target.

I think we have to assume that the whistleblowers who are inclined to use 
a web-based submission system are likely to lack the requisite skills to 
even begin an assessment of source protection measures. Several of the new 
leaksites have already been criticised for their security (Balkanleaks 
runs on Joomla, which is making people unhappy; Brusselsleaks is WordPress 
based, etc...), though I don't expect that to fully deter submissions.

At the end of the day, the whistleblowers either trust the site operators 
to get their security right, or they don't. I view our challenge to be to 
provide as "off-the-shelf" a solution as possible, to both aid publishers 
in deploying a system that addresses the security concerns, and to 
provide a base of reference for how those security concerns can be handled 
(in addition to "what security concerns are present.")

> If that view holds, it might be better kicked out of any technical
> design for a publishing system.

As I've said before, I think we need to think of these as complementary 
components.

> OTOH, If you wanted to make source protection strong *and* technical
> (e.g., uploading), then you might want to make it the same system for
> both uploading and downloading.  Hiding the source in a crowd of
> downloaders is one benefit, and making the download protection high
> profile may help to make the overall source/sink protection better.

I've already been thinking along those lines, myself; I'm resisting 
discussing ideas I have for a specific solution to these challenges, since 
I do think we're lacking a coherent problem statement (though this thread 
is making progress on that front). That said, if we're able to provide a 
covert channel for submission as a product of the distribution scheme, I 
think we gain an important benefit.

The idea of using information-theoretic PIR in the document distribution 
system intrigues me. Bi-directional PIR is something of an open problem, 
but should be feasible in a system where the model user downloads far more 
than they upload. In a Chor-based PIR scheme such as the one Pynchon uses, 
one can see the query bitstreams being repurposed as a submission channel. 
It's tricky, though, and I don't want to fixate on a potential solution 
before clarifying the issues.

At the end of the day, these are two discrete problems. If we can compose 
the solutions so that a single product provides for the needs of both, 
with additional benefits, that's great -- but I don't think that 
composition is strictly necessary at this point.

> 4.  Gatekeeper role.  It would seem that any pure technical system could
> be flooded by junk.  Typically a team is needed to analyse, filter, edit
> and approve.

Yes; I touched in this in my response to Joss. A fully automated system is 
not what we need here, imo; this isn't about simply dumping files onto an 
Eternity Service.

> Some thoughts!

Good thoughts!



--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