On Thu, 23 Dec 2010, Len Sassaman wrote:
<SNIP>
> > Corruption of the leaks via injection of false documents seems an
> > orthogonal problem, and I'm not sure how you'd automate that.
>
<SNIP>
> 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.
Metadata can be (but will not be in all cases) an important data point in
the discussion of a submission. Restated, whether a leak is likely real
or fake may be decided by some of this metadata, so it should be made
available (when it *is* available, ie, not anonymized from the get-go) to
the project reviewers, and only stripped if publication is selected. For
instance, let's say you get a the cablegate leaks from each of the
following two sources:
bmann...@schmuck.airforce.gov
bamnn...@schmuck.coxcable.com
Which one would you have a higher level of trust in wrt the leaks being
real? While the email address doesn't say anything by itself, it can be an
important data point in the big picture.
//Alif
--
"Never belong to any party, always oppose privileged classes and public
plunderers, never lack sympathy with the poor, always remain devoted to
the public welfare, never be satisfied with merely printing news, always
be drastically independent, never be afraid to attack wrong, whether by
predatory plutocracy or predatory poverty."
Joseph Pulitzer, 1907 Speech
_______________________________________________
p2p-hackers mailing list
p2p-hackers@lists.zooko.com
http://lists.zooko.com/mailman/listinfo/p2p-hackers
