Add section about scrubbing metadata to front page

[runasand]

The default front page (or perhaps the page where users upload documents) for SecureDrop instances should include a section about metadata; what it is, how to scrub it, why it matters.

[fpietrosanti]

@runasand I think that SD should make this (the info on scrubbing metadata) part of a "Standard set of Guidelines" for the adopters, that they will copy/paste/adapt to their website sections. At GlobaLeaks we've done that guidelines that way, it report also metadata scrubbing, but in a more general way considering that the average whistleblower does not even know what javascript is https://docs.google.com/document/d/1ZrndvBj9eTg-ooIRfKbXxX18Ie-ODlcjnHjKXSY78Ew/edit?usp=sharing

[runasand]

@fpietrosanti Does SD currently have a set of guidelines for adopters? If not, then I suggest putting together a draft version soon. I think it's important that the guide also explain why certain things are necessary, and not just state that it has to be this way or that way.

[gnusosa]

Looking into these, I was @ SF hackathon.

[garrettr]

@trevortimm is working on this, it will be included in the 0.2 release but it's not needed for the security audit, so it's ok that it's not finished yet.

[garrettr]

@trevortimm, Do you have an ETA on these docs?

[garrettr]

We have a draft Source Best Practices guide that we should complete and share. We should also consider posting some or all of that content as part of either SecureDrop landing pages or SecureDrop front pages (which is what this issue was originally opened for).

[psivesely]

First, I think Garrett makes a good point in #497 (comment). Second, downloading and installing MAT on your personal computer is probably more risky than trusting journalists to properly do it for you as it leaves a trail in addition to just downloading Tor Browser, which is a much more popular piece of software. If you're already using Tails, it's not a bad idea, but tbh I don't think this belongs on the front page--it will just unnecessarily scare and/or confuse non-technical users. In the source documentation perhaps...

[heartsucker]

I'm with @fowlslegs on this one. I think the average source doesn't have the technical capacity to be able to do this safely, and already asking someone who (presumably) hasn't used Tor or the TBB before to engage in yet another new and unknown action seems like to a) scare them away or b) lead to user error. I think it's better to instruct the journalists (who are likely the experts in this case) on how to protect their sources.

If the journalists are trained with the idea that source scrub their data, they might begin assuming data is clean and free to publish. Even if 99% of sources scrub it perfectly, the 1% that don't are being opened to deanonymization. I think it makes sense to place the sole responsibility of this on the journalists since we are already operating on the assumption that the data is safe in transit and thus the only leak would a compromised server (unlikely) or journalist err while publishing.

[psivesely]

I think that, conversely, we could do a better job with our documentation for journalists on how they can (a) use metadata for verification (not strictly security related, but is a cool concept we can share information on to help journalists do their job better), and (b) scrub it before publishing any material (with due warnings on the limitations of MAT for certain file types).

On the note of (a), do we talk anywhere about how journalists should exclusively be using Tor Browser for research related to stories from SecureDrop sources, or verification of documents? Just monitoring certain journalists' Internet traffic might mostly obviate the need (of ostensibly powerful organizations who seek to control the dissemination of their secrets) to break SD in any manner. Does this warrant another ticket?

This deals with usability and training so much--I think @harlo and @olivemartini might have some really valuable input here.

[evilaliv3]

I agree also with @fowlslegs in most of investigative journalism use cases preservation of the originals is fundamental.

a source would not be able (it would be too demanding) to remove selectively the information about himself/herself and will be possibly removing important relevant metadata about the perpetrator of the abuse.

imho, this action could only be taken by the recipeit of the initiative that properly trained will be able to redact the information for eventual publishing and preserve the original for the possible further needs.

[psivesely]

I think there's enough consensus on this one to close it considering @trevortimm also recently noted, regarding a PR that added a metadata warning to first-time submitters, that such warnings serve to scare off non-technical users who might not immediately understand the implications or be able to address them. As noted elsewhere, it's far from simple and sure to remove metadata from documents.