@micahflee hey @micahflee we are having a discussion whether privacytools.io should provide a securedrop or not. As we currently rent our servers, we are unsure if it would be the right choice to adopt it, would you be willing to give us some input here ? :)
https://github.com/privacytoolsIO/privacytools.io/issues/1691
@blacklight447 it looks like the discussion is whether or not to include SecureDrop as a tool under file sharing software? Not whether privacytools.io actually wants to host its own SecureDrop server, right?
I think I agree with the the comment here https://github.com/privacytoolsIO/privacytools.io/issues/1691#issuecomment-587272512 -- if the purpose of privacytools.io is to help individuals and not organizations, OnionShare is a better suggestion than SecureDrop
@micahflee we aim to help individuals yes. We were considering though whether privacytools.io as an organization might need a secure drop.
You see ww have a fairly trusted reputation in the community, and we often rely on the community to help us keep our recommendations up to date. Providing an securedrop may let people share more stuff with us, which they wouldnt want to make a public github issue for. 1/2
@micahflee the thing is though, we rent our dedicated servers. Which is different of how secure drop would typically run. So would it still be ethical to provide it as an option, even though its security may be lower then a securedrop from lets the intercept or the guardian. 2/2
@micahflee interesting, thanks for the feedback, it has put things in a good perspective :).
@blacklight447 Well, I think the larger issue is running a SecureDrop instance (and specifically check SecureDrop every day) can be annoying and time-consuming. Worth it, if you think you might be handling extremely sensitive info like leaked classified documents.
But for the privacytools.io use-case, I think it would be overkill. There are probably simpler solutions, like you could make an HTTPS contact form, or publish a keybase username or Signal phone number.