[securedrop-export] Add device selection menu for printing and transferring files

[sssoleileraaa]

Description

In yesterday's client sync we discussed how there could be multiple devices attached to the Export VM and came up with a solution to send a new status code (referred to in that Issue as both MULTIPLE_DEVICES_CONNECTED_ERROR and MULTIPLE_PRINTERS_CONNECTED + MULTIPLE_DEVICES_CONNECTED) back to the client.

If we use an error code, then all the client can do is inform the user to detach the device(s) that they don't want to transfer documents to from the Export VM and then try to export again. This would be done using the QubesOS device menu (or the qvm-usb detach command).

We discussed how it would be better if the user could select a device from a device menu, but we didn't get any further than that. I'd like to continue the discussion.

What are our options?

I'd like to know if others have ideas, please share, thanks <3. I can think of a few different high-level ways of providing the user with a menu to select from when there are multiple devices to choose from. Basically they are:

• Add a Device API for sending device information between the Export VM and client running on the SVS VM. Also the Export Dialog on the client would need to be updated to prompt the user to select a device.
• Add a GUI to the export script running on the Export VM for managing/selecting devices
• Decouple export from the client: move the entire export experience over to the Export VM: all the client would have to do is transfer the documents to the export VM which would run the Export Dialog that guides the user on printing or exporting to a device.
• Use the QubesOS device manager and focus our efforts in qubes-land to improve it? The problem here is that we want to make sure the device selected is luks-encrypted, so we'll need more brainstorming here (maybe we can have a policy that only allows luks-encrypted devices attached to certain VMs... idk) if people are interested in this idea.
• Something else?

[eloquence]

@creviera - do you think that users are likely to encounter this scenario in practice? Or do you view it as an edge case and this is more of a post-beta, nice-to-have discussion?

My sense is that if we are smart about detecting which device to auto-attach (encrypted USB w/ partition ID we recognize; supported printer) and ignore devices that don't match those limitations, the "multiple USB" scenario is an extreme edge case and an error message is actually warranted. If the user is plugging in multiple storage devices with the partition marker, for example, that suggests to me more that they're trying to work around some other problem, not that this is an ordinary, day-to-day use case.

[rmol]

I like options two and three. If we can avoid treating the presence of multiple valid devices as an error, we should. It seems a reasonable state; perhaps a journalist has fired up the workstation to export something for themselves and a colleague too. We could even eventually allow selection of multiple destinations, perhaps both print and disk?

It doesn't seem like the basic selection GUI (maybe not simultaneous heterogeneous outputs) would be so much work that it would have to wait until after beta, but @creviera @redshiftzero please correct me if I'm underestimating that.

Option three seems to have nice properties; the client could treat export as a simple fire-and-forget operation, right?

[sssoleileraaa]

do you think that users are likely to encounter this scenario in practice? Or do you view it as an edge case and this is more of a post-beta, nice-to-have discussion?

I would not be surprised if multiple devices get attached to the Export VM and a journalist encounters this scenario in practice. A lot of this depends on how many journalists, admins, devices, how frequently the workstation is used, and if it's a shared workstation.

My sense is that if we are smart about detecting which device to auto-attach (encrypted USB w/ partition ID we recognize; supported printer) and ignore devices that don't match those limitations, the "multiple USB" scenario is an extreme edge case and an error message is actually warranted.

I don't think this is an extreme edge case, even with auto attaching and doing our best to guess what the user's intention is when they plug in a device. @rmol just mentioned a couple scenarios to consider, and it doesn't matter if auto-attaching is working or not:

A) A journalist has fired up the workstation to export something for themselves and a colleague too.
B) We could even eventually allow selection of multiple destinations, perhaps both print and disk.

Also, I would add:

C) A journalist doesn't know which device they want to use and would like to insert a couple different transfer devices and attach them to see what's on them first.

I think we should also be aware that journalists and admins might get used to attaching and detaching devices using QubesOS even with our auto-attaching feature. For instance, sometimes it looks like a thumb drive is still being accessed because the light is on and journalists may want to detach it before disconnecting it from the computer. Or our auto-attach script isn't working. Or a news org has some older luks-encrypted transfer devices and the admin hasn't gotten around to adding the partition label securedrop-transfer-device so our script can't auto-attach them. Or users just get used to using QubesOS over time and default to attaching/detaching devices themselves. In most of these scenarios, the chance of multiple devices getting attached increases as a person's knowledge and comfort with QubesOS increases.

Last thought is that we need to be careful not to transfer documents to the wrong device. A journalist could have two luks-encrypted thumb drives plugged in, and one has the new partition label on it and the other doesn't, we shouldn't default to transferring the documents to the labeled drive.

[sssoleileraaa]

It doesn't seem like the basic selection GUI (maybe not simultaneous heterogeneous outputs) would be so much work that it would have to wait until after beta, but @creviera @redshiftzero please correct me if I'm underestimating that.

I think it's not a ton of work, we just don't have much wiggle room with all the other things we'd like to deliver in beta. If we decide to go ahead and decouple export from the client, we could do this in stages such that it's okay if only some of them make it into beta. Before we move client logic and gui code to export, it will need to change from a script into a Qt application.

[eloquence]

Thanks for laying this out very clearly! As a counterpoint, I would caution that a simple instruction ("unplug SecureDrop export devices other than the designated one") sometimes beats a complex choice ("Pick storage device: sys-usb:1-3 SANDISK STORAGE; sys-usb:4-1 SANDISK STORAGE") in terms of UX. When faced with a complex choice they cannot answer, the user may default back to the behavior that the error message would have encouraged: unplug all devices and try them one by one.

I don't think the error behavior necessarily prevents some of the other scenarios you describe, Allie, in combination with automatic attachment:

• The user can still inspect storage media, one by one, before starting an export;
• Manual attachment should IMO still be possible (if a device is already attached to a VM, the automatic attachment script should ignore it).

As far as the options you enumerate go, regardless of where we would place it (in the sd-svs or the sd-export-usb VM), we would still have to build a device chooser UI that helps users make a clear choice between two fundamentally very similar options (two encrypted storage devices that meet some criteria that we define). IMO, that's a difficult UX problem, which is why I would hesitate to tackle it before the pilot (== beta). I also suspect the pilot will give us some good insights into what multi-device scenarios are likely to occur in practice.

I think you both make a good case that maybe more logic should be moved to the export VM, but it would be possible to revisit the current architecture without implementing a device chooser. So, if we end up deferring the device chooser, that may be worth scoping into its own issue.

[redshiftzero]

The idea of enabling the export of the same document to e.g. 2 export drives at once is clever! That said we should really wait until the pilot gives us a better understanding of how often users want to take this action before implementing support for that (since we have lots of remaining items to implement for the beta that we know users will need/want).

Add a Device API for sending device information between the Export VM and client running on the SVS VM. Also the Export Dialog on the client would need to be updated to prompt the user to select a device.

Add a GUI to the export script running on the Export VM for managing/selecting devices

If we were to support multi-device selection, I think adding the GUI selector in the export logic itself is a great idea as it reduces coupling between application components. Regarding moving all the export logic to the export VM, I do think it nicely addresses the potentially weird experience if the user is interacting with the ExportDialog in the client VM and then the selector pops in from another VM - though we might be able to address that by having the qt dialog pop up in the upper right of the screen. We'd want to implement this along with #551 since we don't handle concurrent exports on the export side: recall that with the current logic the exports will race each other (i.e. we can't treat them as fire and forget from the client VM) and one will fail. Right now the proposal is to allow only one concurrent export from the client at a time to handle this, which we should stick to for beta.

Use the QubesOS device manager and focus our efforts in qubes-land to improve it? The problem here is that we want to make sure the device selected is luks-encrypted, so we'll need more brainstorming here (maybe we can have a policy that only allows luks-encrypted devices attached to certain VMs... idk) if people are interested in this idea.

Yeah, if we find ourselves in the future considering spending a lot of hours on the UI for exposing and attaching different USB drives in the future, we might have a shorter path to a sufficient solution for end users if we improve the UX of the qubes USB attachment UI/process upstream and train/instruct users to use it.

[eloquence]

We've agreed that a device chooser is a Post-Beta feature; we'll target handling this as an error case as a must-have requirement for the beta.