Another questions is: what sort of information should be published? I imagine most people agree that we shouldn't write another "guide" about how to use tools a, b, & c.
@jonathanstray has mentioned making context-specific rules of thumb, which is both clearly useful and hard to accomplish, since small changes in the context can change the corresponding "best practice" dramatically.
So, I largely agree with @jonathanstray that basing rules of thumb around real world scenarios is the right way to go, I just think that modeling those rules based on adversaries (FVEY nation state, criminal gang, local police, etc) is not the best approach, since those adversaries capabilities vary, case to case, and change over time. I would be worried that this advice would quickly go stale or underestimate certain classes of adversaries, since surveillance capabilities tend to trickle down market, and since adversaries that are nominally within the same category can have vastly different capabilities, in practice.
What might work instead would be to organize suggestions around journalistic activities, such as:
-crossing borders & dealing with check points
-meeting & communicating with sources
-handling large document sets securely
etc.
For each journalistic activity, several approaches could be provided, organized by their level of security (for example, it is common for laptops to be searched at the U.S. border; if your laptop is encrypted and you refuse to provide the passphrase, then it may be seized. However, U.S. Customs is not in the habit of forcing people to log into their email accounts, whereas this is common practice when transiting customs in Israel. Therefore, when transiting U.S. customs, it is necessary to have a burner laptop, and to encrypt and upload your files before transiting. In Israel, you will also need a throwaway email account that has plenty of pocket litter - trivial conversations with non-sensitive individuals).
This way, the journalist could use their judgement and pick which security level is appropriate for their situation.
The Gitlab wiki looks pretty ideal, since it's an easy to use version control system in the form of a web app wiki. I suggested Jekyll earlier, as a way to present the finished information, but since Jekyll is designed for blogging, and thus presenting information chronologically, this may not be best. One option that may work better is Read The Docs. It's designed for publishing documentation and plays nicely with most version control systems (including git) on the backend. The SecureDrop documentation is published using this tool, for example.
Gitlab + Read The Docs?
Thoughts?
