On Sat, Dec 25, 2010 at 1:12 PM, <m...@gmx.com> wrote: >> 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. > > Could someone target the reviewers after the leak has been published, to get > access to an unredacted copy that might identify the submitter?
Arguably, yes, unless the reviewers are suitably hard to find as well. Minimizing the amount of metadata that reviewers see is a useful thing, though; there may be non-personally-identifying metadata that still helps to authenticate a file as real. > Maybe we should split the role of the leak site into two parts - a redactor, > who helps the submitter to anonymise the leak, and who may be able to > identify the submitter from metadata etc; and a publisher, who prepares > redacted documents for publication, and who can't identify the redactor or > the submitter? If this separation is desirable, I think the redaction can be done in software, and furthermore I think it can be done entirely browser-side. Provide a browser-side image editor (like http://www.pixlr.com/editor/ without tracking every action via Google Analytics) so that the *user* can manually black out anything s/he wants, and provide in-browser metadata scrubbers for various file types (PDF, .doc, EXIF? What else?). Now you have two choices. Either the redactor (which is made up of a combination of the submitter and some software) can decide to discard the metadata forever (remember, it's all browser-side), which is as simple as flushing the cache (well, srm too), *or* the user can decide to keep the metadata himself. Maybe as diffs between stripped and unstripped files, for simplicity. This metadata could be sent, encrypted, to the publisher, while the submitter keeps the key. One desirable property here might be for the submitter to decide which files to release (which?) metadata for -- I'm unsure what the tradeoffs are between convenience and degrees of control. Anyway: If the publisher ever determines that some form of metadata is needed in order to verify the authenticity of some document, s/he will somehow have to get the attention of the submitter, who will then have to get the appropriate key to the publisher; it seems to me there are a lot of ways that could be done. > Agreed, this could be a separate project and would be useful in all kinds of > privacy-sensitive situations. Len and I have been discussing something pretty similar for a long time; we've been calling it the Redact-O-Matic. Cheers, --mlp _______________________________________________ p2p-hackers mailing list p2p-hackers@lists.zooko.com http://lists.zooko.com/mailman/listinfo/p2p-hackers
