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