A way of getting feedback from sources about the SecureDrop software itself could be to run our own SecureDrop and include a note and link to it in the footer of the SecureDrop source interface base template. The access to the user feedback SecureDrop could be shared among maintainers, who could check the SecureDrop (thus also serving as a useful dogfooding exercise), and create tickets based on the feedback for implementation.
Of course, including this feedback link in the footer of the SecureDrop source interface should be optional. I suspect some organizations may worry that a source may send incriminating information to us and they might be more comfortable if all communications went directly to the news organization. This is totally reasonable, so we should build that functionality in if this were to be implemented.
This is a really interesting idea! Honestly I don’t know how it would work with a “SecureDrop for feedback”. But it’s a very interesting problem to think about.
Usually it’s useful to ask users open-ended questions when getting feedback from them (qualitative data), as it gives you a richer set of data to analyse when doing usability testing.
However, in this case, since there is an understandable worry a source may send incriminating information, this might be a case where it would be better to use a more “closed” question feedback method - where we specify the question, and the answer is somewhere on a scale of predefined answers.
There could be a “include a comment” with each question. This could be character limited to say 50 chars to limit “oversharing” or “inappropriate sharing”.
The interactions the source could make with SD would limit the risk of them doing something “insecure” or dangerous.
This could be included in AD standard builds and organisations could choose to turn it on/off based on their appetite for it.
This is different than what you’ve proposed I understand, but I thought it was worth mentioning.