Hey there. My organization is planning on setting up a Securedrop instance in the coming weeks.
The Securedrop will come into public production earliest in September.
Now, I’ve seen that a qubes-os based approach for the workstation is currently being piloted. This looks very promising, and our team would definitely prefer to use it over the old version. Also, quite a bit easiert to setup.
The reason I have do the set up now (and would prefer to do it in a way that I don’t have to change the architecture later) is simply because I have much more time right now, also I’d prefer not to make big changes to the securedrop once it’s in public production.
Now, my approach would be to implement the qubes-os version for the client and, in case it gets thrown out after pilot, reconfigure to the SVS approach. That way I could save time and still revert back.
Is that a good idea, especially from a security standpoint? Are the chances big, that the client gets thrown out after the pilot?
Hi @someadmin, based on feedback so far from beta participants, we’re very likely to continue expanding usage of the SecureDrop Workstation. There are some limitations to be aware of (Limitations and known issues — SecureDrop Workstation stable documentation) and we’re also still in progress of adding support for Qubes 4.1 (Qubes 4.0 does not have support for a lot of newer hardware).
Generally our recommendation for new installs as this time is to set up a conventional SecureDrop install with an air-gap, so you have that as a fallback, and once you’re comfortable with that setup, to consider adding Qubes to the mix. I would suggest we discuss a bit more outside of this forum e.g. on a call – if you’re comfortable with that, shoot us a note at securedrop@freedom.press 