Create proof-of-concept print workflow

[eloquence]

As of #259, we now have a basic workflow for exporting documents to an encrypted USB volume. Significant work remains: UI design, client integration, better error state reporting (#264), VeraCrypt support (#265).

Separately, we also want to support printing documents. Ideally, the initial implementation would provide a similar guarded workflow, e.g.:

• ensure a supported printer is available in a disposable VM
• invoke the appropriate viewer application, ideally with a "print" subcommand that takes the user directly to the print dialog

As we did with USB export, let's start with an initial CLI-only implementation spike to discover challenges and limitations that will inform the final architecture and design.

[eloquence]

Open questions from my end:

• Should the same VM be used for print, or a different one?
• Should the same USB port be used (potentially requiring switching), or a different one?
• Should non-USB printers be supported?
• Do we need to put in some hardware purchases for testing?

[eloquence]

For 6/12-6/26 sprint, we've committed to a 16 person hour timebox. As with export, our main objective is to answer the most pressing questions about what's feasible and what isn't, to inform UI design and subsequent iterations.

Should non-USB printers be supported?

Per discussion today, the answer is almost certainly no; the preference will be for printers without wireless (if such a thing can still be found), and certainly for the printer to plugged in during usage.

Do we need to put in some hardware purchases for testing?

As discussed today, @emkll currently does not have a printer. Mickael, probably easiest for you to propose a printer that seems worth testing with, and then buy and expense it.

[ninavizz]

Also: printers must be laser, not inkjet. Super important, as inkjet media goes fast and is very expensive. Likewise, laser printers are just far quicker for large document outputs. Color is not a necessity, just black and white is fine. Xerox made a wax-media for their "Phaser" printer tech, for some time, and that may still exist—it'd be ok, too.

Brother and HP both feature "Wireless Printing" capabilities on most of their laser printers; which is not intended to integrate with a standard 802.11 wifi network, but some other way (that I have yet to muster the patience to figure out with my own devices).

Lexmark is a brand that's mostly been for offices, and as such may offer no-wireless-option laser printers. Ditto on Xerox.

[eloquence]

First round of open issues, questions & feedback from today's proof-of-concept review:

• Implementation status: Current proof of concept implementation only supports Brother printers. The printer is reconfigured on each run. It uses the same port as the USB file export. It includes support for printing a test page.

• Major issue: Qubes sometimes re-assigns device IDs like sys-usb2:4 on boot (this behavior manifests itself when sys-usb is rebooted, or when the workstation resumes from sleep). This makes it impossible to predictably configure a USB port for printing or export. More investigation and potential upstream collaboration required.

• Major issue: For a persistent disposable VM with USB access, a USB device has to be plugged in to the attached USB port when the VM starts, or it will fail to start (this appears to be a limitation in using qvm-usb attach with the --persistent flag on the disposable VM. More investigation and potential upstream collaboration required.

• Printer support: We currently only have an implementation for Brother printers. At minimum, we'll want to add support for 1-2 additional common printer models; it's worth investigating whether there are auto-detection methods we can employ to broaden support.

• Print job status: Given that the printer in the disposable VM is re-configured on reach run, we want to ensure that the qvm-open-in-vm call is blocking until the print job is completed (not until it is enqueued) or failed. If it fails, we want to pass some error information back to the client. Can this be done through lpstatus, CUPS, or by other means?

• File type support: The current implementation works with PDF, PS, PNG, TXT. Other printable file types supported by the workstation include CSV, ODT, ODS, ODP, DOC, XLS, PPT, XLSX, PPTX, JPG, GIF, TIF, SVG, DJVU. We'll want to test with these file types as well, and understand the security implications of invoking lpr against different formats.

• Print options: Can we show a standard printer dialog when the user prints, so they can configure paper options and the like?

[eloquence]

For quick reference, this is the spreadsheet with the supported file types:
https://docs.google.com/spreadsheets/d/1l-DGR5UnnvYA5jfeZtplER933ANPWgFLx_uWbnJZKWI/edit#gid=0

[ninavizz]

Random thought: HP printers have the broadest availability of off-brand/generic toner cartridges (which means you pay $30USD instead of $150USD, or can buy toner to refill cartridges, as an example), too. It'd be great to include at least one HP model in the 2nd or 3rd option.

Sorry, yes, I love my treeware. :)

[ninavizz]

Question for @emkll and @redshiftzero: I'm wondering why we couldn't use the Libre Office workflow for printing? It should have all the drivers/PPD support things built in, and if the printer automagically mounted/attached to the same disp-VM as LibreOffice, then queuing and other things could be managed by that VM, too.

I don't feel it's a bad experience to require users to open something before printing it, and in many ways that may be a more desirable flow. Especially since LibreOffice has solved so many other design problems, such as queuing and the "Print Options" dialog. I do expect users will likely wish to queue multiple print jobs, and the ability to manage that would be highly desirable.

I do have a lot of experience working with large/off-brand plotters via my art stuff with SRL.org, and trying to get them to work on Windows machines. Drivers, PPD things, and then that damn "Print Options" dialog, are deep/dark rabbitholes it'd be great to avoid. Even when I've documented things on cheat-sheets, it's still a shitty experience to always have to navigate—and one my fellow SRL artists too often just didn't feel up to navigating, and would ask me "Hey Nina, I know you could do in 5min what it'd take me 20min... cd u just do it for me?" Newsrooms currently experience that user bottleneck w/ how SD's current experience runs. I'm wary of entering that zone with how the workstation prints.

Finally, random additional thought: printers sold in other countries may likely have whole other PPD & driver needs, than the same model sold in the US, because of random regulatory things. One of the printers I work with the most at SRL is Japanese, and for specific reasons I cannot remember (other than the manual's English translation being awful) I also recall that presenting a major headache with driver/PPD stuff.

[emkll]

Question for @emkll and @redshiftzero: I'm wondering why we couldn't use the Libre Office workflow for printing? It should have all the drivers/PPD support things built in, and if the printer automagically mounted/attached to the same disp-VM as LibreOffice, then queuing and other things could be managed by that VM, too.

The initial proof of concept was mirroring the existing export to USB functionality, maybe too much so: even though both printing and sending to usb are considered "export flows", you make a good point that they do work quite differently.

Being able to use the contextual print menu in the disposable VM when a submission is displayed might be somewhat challenging:

Using the current (simple) approach of the sd-export-usb vm, connecting the printer to the specific DisposableVM that is displaying the file the user is currently viewing is challenging:

• The name of the VM must be passed to dom0 in order to attach to usb device (printer) to the correct VM
• Attaching a USB device to a VM requires user intervention in dom0 (the SecureDrop Client, or any process in any VM can't initiate an action in dom0)
• We might be able to get around this by polling sd-svs from dom0, but it might not be sufficiently reliable)
• To ensure reliability, it's very likely that we would need to ask the user to invoke the Qubes USB attach menu (or create our own button to automatically attach to the sd-export-usb vm)

Another way this could be achieved (significant research required) is having a (network or qrexec) print server running in sd-export-usb, which:

• Uses either local-only network or qrexec-style IPC similar to sd-proxy
• sd-svs-disp DispVM template could be configured to use it, and all dispVMs spawned would inherit the configuration.

Some drawbacks with that approach:

• Introduces significant complexity and maintenance burden
• potentially impossible for a user to debug (in the current approach, a user can just blow away and re-create the export VM with zero side effect)
• introduce certain risks (ensure the network is properly configured), ensuring that the network is local only and connects to only those dispVMs.

[eloquence]

Thanks for that additional background, @emkll! Nina, Allie and I discussed this a bit more today. We agree that being able to print directly from the disposable VM used for viewing files would be the ideal user experience. We think it's worth investigating whether this can be done in a secure manner, after the pilot.

It's worth noting that users will be exposed to essentially useless "Save as" and "Print" dialogs in applications launched in sd-svs-disp VMs. This is potentially a significant point of user confusion. It may be worth thinking about creative solutions to at least indicate to the user that this won't work; I will file a separate issue for that.

A couple more points:

• Upon consideration, the requirement of having a device plugged in before the VM starts is one we think we can live with for the pilot. If you look at the current beta export flow, this is essentially already assumed: the user is prompted once to insert a drive before the VM is started up.

• In this group we agreed that it'd be acceptable have print be a blocking action from the user's point of view for the beta (meaning, they can't do anything else in the client until print completes, errors out, or is aborted). Ideally, we'll be able to actually use a printer queue, post-beta, but again, that adds a lot of complexity. At the same time, having some in-between "busy" state where print actions are disabled but other actions remain available strikes us as more trouble than it's worth.

• We would recommend considering another name for the "export" VM as long as it's used for both print and export to USB. We call these actions "print" and "export" in the UI, so having the same VM name for both is a bit confusing. We were kicking around a few possibilities and came up with sd-transfer (or sd-transfer-to-usb) as an alternative.

[ninavizz]

...below, per discussion yesterday with @eloquence where he clarified/reminded me CUPS has been decided to be the spooling thingbob we'll be using for the Workstation.

CUPS Things

CUPS is the standards-based, open source printing system developed by Apple Inc. for macOS® and other UNIX®-like operating systems. CUPS uses the Internet Printing Protocol (IPP) to support printing to local and network printers.

• CUPS is the Linux print thingbob (more than a spool, or just a spool?) Qubes will use with Ubuntu/Debian. The above summary was cut-and-pasted from their website.
• Design Spec
  

[emkll]

closed via #277