For HTTPS Everywhere releases, we export signed data from the airgapped machine as a QR code (scanned with a normal QR code reader on a mobile phone). I could adapt the scripts we use to do this for the airgap machine in SecureDrop.
The main benefit is that if the airgap machine is infected with malware, it is probably harder for the malware to exfiltrate data over the airgap if we export as a QR code instead of via a USB stick. Addresses issue #160.
Supposedly we can fit a max of 4,296 alphanumeric characters in a single QR code set to the lowest error correction rate. So this method may not be usable in cases where the journalist wants to export a lot of data from the airgap machine.
I would like to take a look at the scripts if you can share. What do you mean by signed data, the detached signatures?
@ageis sorry, just got this. The HTTPS E scripts are not public for opsec reasons but I'll put something together.
signed data == inline signature using an obscure firefox XML data format,
In light of https://github.com/freedomofpress/securedrop/issues/2238, can I suggest we close this as training journalists on which QR codes are safe and which are not is going to be somewhere in the realm of "as hard as teaching them to not get phished," which is to say a losing battle. Also, when we move to the journalist workstation model, this will become irrelevant.
@heartsucker No contest, thanks for flagging. I agree that the risk of exfiltration from the airgap is too great to accommodate bad-versus-good QR codes. In the interest of usability, we're already turning toward a more robust SecureDrop Workstation experience over in https://github.com/freedomofpress/securedrop-workstation/
@heartsucker Well said. For now, the training for journalists using the SVS should be "never scan QR codes on the SVS, ever", until the current Tails-based SVS is replaced entirely with SecureDrop Workstation. Additionally, the Qubes-based SecureDrop workstation will allow us to develop much more user-friendly and robust techniques for journalists to _intentionally_ migrate data out of a secure area (similar to Qube's untrusted PDF's feature).
Most helpful comment
In light of https://github.com/freedomofpress/securedrop/issues/2238, can I suggest we close this as training journalists on which QR codes are safe and which are not is going to be somewhere in the realm of "as hard as teaching them to not get phished," which is to say a losing battle. Also, when we move to the journalist workstation model, this will become irrelevant.