Supported outlets: https://securedrop.org/directory/
In terms of how it's different. We attain anonymity without requiring a user to install Tor Browser, which we think is significant. Building this feature into our news app lowers the barrier of entry for non-technical sources quite significantly, and we think helps them achieve good OPSEC basically by default.
CoverDrop (aka Secure Messaging) has a few limitations right now that we'll be working to overcome in the next few months. Primarily that we don't support document upload due to the fact that our protocol only sends a few KB per day. Right now a journalist has the option to pivot the user onto another platform e.g. Signal. This is already better since the journalist can assess the quality of, and risks posted to, the source before giving their Signal number.
The current plan to improve this within the CoverDrop system is to allow a journalist to assess the risk posted to a source and, if they deem it acceptable, send them a invite link to upload documents which the client will encrypt with their keys before sending. This affects anonymity of course so we'll be investigating ways in which we can do this while doing our best to keep the source anonymous. There are a few techniques we could use here, for example making the document drop look like an encrypted email attachment being sent to a GMail account. I like this[1] paper as an example of an approach we could take that is censorship resistant.
Another limitation is that the anonymity of our system is largely predicated on the large install base of our app. In the UK/US/AU we have a pretty large install base so the anonymity properties provided by the protocol are nice, but if another smaller news agency were to pick up our tech as it stands right now then they wouldn't have this property. That said, in practice just having our plausibly deniable storage approach is a pretty big improvement over other whistleblowing approaches (PGP, Tor based, etc), even if you're the only person in the set of possible sources using the app.
[1] https://petsymposium.org/popets/2022/popets-2022-0068.pdf
the difficulty of including a dependency should be proportional to the risk you're taking on, meaning it shouldn't be as difficult as it in, say, C where every other library is continually reinventing the same 5 utilities, but also not as easy as it is with npm or cargo, because you get insane dependency clutter, and all the related issues like security, build times, etc
how good a build system isn't equivalent of how easy it is include a dependency, while modern languages should have a consistent build system, but having a centralised package repository that anyone freely pull to/from, and having those dependencies freely take on any number of other dependencies is a bad way to handle dependencies