Research alternatives to current print architecture

[eloquence]

There are a few issues with current printer support:

• only two printer models are officially supported
• known issues with Brother printer driver (e.g., Improve printing of images #506)
• xpp frontend has major design and usability issues (#294)
• we're not using viewer apps' native print dialogs, which often offer additional functionality, and are integrated with the view experience (ref "Print" and "Save" actions in sd-viewer VMs are confusing #278)

Informed by user research about how important print support is to a larger set of prospective users, we should reconsider the current architecture, and evaluate alternatives.

Example research questions:

• Could passthrough to another VM be managed via a virtual printer driver installed in sd-viewer?
• Can we avoid the use of xpp altogether, or find a better alternative?
• Can we somehow leverage OS-level autodetection of printers, and automatic installation of drivers?

[cfm]

As discovered in freedomofpress/securedrop-builder#343, xpp has been removed from Debian stable as of bullseye, based on the following (2020) request and rationale:

please remove xpp:

• has been orphaned over 10 years ago, with very little interest since
  2013. The original maintainer said 7 years ago "IMHO, we should just
  remove it from Debian"
• is rc-buggy for over 6 months
• upstream didn't do anything for over 14 years
• alternatives exist: desktop environments nowadays have "printer
  panels", and for other usages gtklp appears to be a viable alternative

[eloquence]

The HP M404n has been discontinued and is no longer available from Amazon except used. It may be relatively straightforward to test one of their other models such as the HP LaserJet Pro 4011ne (Amazon's comparison notes that it adds a USB port, but I don't see evidence of wireless connectivity, which we generally want to avoid).

@tina-ux has offered to house another test printer to help test the user experience; I would appreciate input on which model we should procure for that purpose.

[rocodes]

Have received the long-awaited HP 4001dn, a currently-available HP model that we can test + recommend. Due to the long shipping delay, I also acquired an older Brother HL-L2360DW which I have been using the past month ish, which works with SDW but is discontinued so won't be a candidate for official recommendation.

Just summarizing some things we've said in meetings etc for the record here:

• Printer model numbers, etc: I've updated the wiki so that we don't have to go through such pains again when ordering specific printers (spoilers: no HP+ and no e models ever!), and I will update again once I have had a chance to test the new printer.

Next steps for print support:

• Broader support (i.e. "all printers that support AirPrint and have a USB port"), moving away from bundling drivers or focusing on specific printer models.
• Supporting virtual printing/print to PDF, for dev and staging setups only, to allow team members to test the print workflow without having to have a printer and reduce ongoing hardware support costs.

The above questions are currently triaged behind the upcoming ugprade and migration changes, but after that, we should research them, and include in that research a path to deprecating xpp and/or exploration of using existing print buttons, etc.

[deeplow]

To address @eloquence's original questions from the findings so far:

Virtual Printer idea in sd-viewer

Could passthrough to another VM be managed via a virtual printer driver installed in sd-viewer?
Can we avoid the use of xpp altogether, or find a better alternative?

These two questions I think are fundamentally addressed by the first one. I think it is totally doable. That way we get to have the native print dialogues for every application. I played a bit around with cups-pdf, which is a virtual PDF printer. We could then send this PDF over (even through dangerzone) to sd-devices and print the sanitized PDF.

The downside of this approach is that the virtual printer is unaware of the physical specifications of the printer. One practical example is size mismatch: if the virtual printer prints to A4 and the printer uses US sizes, things may look slightly off.

Shall we track this as #1137?

Printer auto-detection and driver installation

Can we somehow leverage OS-level autodetection of printers, and automatic installation of drivers?

I think the answer to that is driverless printing. I was surprised how well it worked (at least for my specific setup). More details here: freedomofpress/securedrop-client#2088.

[deeplow]

Another thing to think about when rearchitecting this is that we can probably replace our sys-usb udev modifications with a combination of udev+systemd as suggested in this thread.

This combination lets us do the whole setup in the template and conditionally have it enabled based on ConditionPathExists= for Qubes services. This would mean that we wouldn't have store data in sys-usb disposable template.

[ben-grande]

I have an implementation, notice the security warning. Feel free to ask questions.

[deeplow]

I have played around with this a bit and there seems to be an easy way to implement it, which tackling together a bunch of issues:

• "Print" and "Save" actions in sd-viewer VMs are confusing #278
• Research alternatives to current print architecture #564
• Switch printer front-end for SecureDrop Workstation securedrop-client#2156

Here's an architecture breakdown from the current one to some potential alternatives (source diagram).

ℹ️ NOTE: freedomofpress/securedrop-client#2156 (Driverless / IPP printing) is an orthogonal discussion. Nothing in either approach blocks our ability to implement that.

Current Architecture

Currently, sd-viewer has nothing to do with printing / exporting. Files are sent directly from the client to sd-devices and then printed from there to some hardcoded printers.

Proposal 1 - Replace printer front-end (from XPP)

We can for sure explore just freedomofpress/securedrop-client#2156 and have a temporary solution of replacing xpp as the print dialog, but that creates issues of its own:

1. Viewer applications are the ones who implement print dialogues. We either go with an (apparently) document-agnostic one (literally an XPP replacement). Arguable these look quite dated. Or we build a custom one as @eloquence mentioned.

This, however would only be a temporary solution, if we end up implementing #1137 this work won't be useful since in sd-viewer we can simply use the program where the file is viewed at to open its native print dialogue.

Proposal 2 - print from sd-viewer

This is the idea I proposed earlier of printing directly from sd-viewer (Flow B), the user would click the print button and it would present a print dialogue, when confirmed, the file would be printed. Alternatively, the user could choose to print the document by clicking on the client (Flow A).

Here's how the new architecture could look like:

Implementation

1. In sd-viewer create a PDF printer in sd-viewer named "default" or something else (the key is not to name it PDF printer)
   This can easily be created with system-config-printer selecting CUPS-PDF. We can probably easily do the same with lpadmin commands.
2. The CUPS-PDF printer saves files in ~/PDF. We could setup a system service which gets triggered when a file is written to that directory, which then would call qubes.FileCopy (or equivalent) to sd-devices. (*)
3. Once the file is copied to sd-devices, through driverless printing it would print the file to the first available printer. Since this is in a known file format (PDF) we could directly print it without showing any additional dialogues or messing with different viewer application's print dialogues

ℹ️ One risk that this approach carries is that a document can always request itself to be printed. This is because the print action is initiated within the untrusted qube (sd-viewer).

(*) to harden sd-devices we could make it only accept data ran by dangerzone. It would then reassemble the files in sd-devices.

How printing from sd-client would work?

On the current application, there is only one way to print - by clicking the "print" button in the client application. This workflow would still be kept. However, in this case it would instead open the file in sd-viewer and immediately call the printer dialog. As soon as the printer dialog was closed, the disposable would close.

Where should the "document printing risks" be displayed?

When sd-devices receives files for printing, it could be the one showing that information. It's also a good place to have that infrormation since it has direct access to information about the printer. This would reduce the need for sending data back and forth from the client to sd-devices on printer status.

Proposal 2 with Potential Dangerzone integration

Proposal 2 would make a clear path towards integrating Dangerzone (#862). This is not yet considering custom processing / exporting pipelines, of course. But we want to get to that first, then Dangerzone may still take some time to get there.

Here is how it could look in a way where Dangerzone is integrated into the print workflow:

The advantage of the above approach is that sd-devices is less exposed. The coloring change (sd-viewer -> red / sd-devices green -> illustrates this change). Of course, sd-devices is still exposed to USBs and printers (that's besides the attack vector we're considering).

Following the same architecture, we could use Dangerzone for bulk export sanitization as well bulk printing. Here's a simplified diagram:

This last one would also be the approach for bulk actions because we can't expect users to do one print dialogue per export document.

Open questsions remain for documents which can't be sanitized. But that's beyond the scope of this issue. I just wanted to show that #1137 is a reasonable path towards #862.

[legoktm]

Thanks, this is really great and I'm actually quite excited by the idea of just using each viewing application's print dialog. I was concerned about letting things leave sd-viewer, but the PDF restriction plus DZ integration addresses that. I am not sure yet how I'd feel about Proposal 2 without DZ integration.

Since this is in a known file format (PDF) we could directly print it without showing any additional dialogues or messing with different viewer application's print dialogues

The only thing I can think of is if you wanted to print double-sided (or not), which wouldn't be a question you could answer at an earlier stage in a print-to-pdf dialog. Not sure how big of a deal that is.

[zenmonkeykstop]

Good stuff @deeplow - there might be an argument for just dropping the client app print functionality altogether, letting the user open the file in the appropriate viewer app and print from there if they can. Would reduce client complexity by a bit and give folks an unambiguous path to printing.

[deeplow]

The only thing I can think of is if you wanted to print double-sided (or not), which wouldn't be a question you could answer at an earlier stage in a print-to-pdf dialog. Not sure how big of a deal that is.

I thought a bit about this. There are two ways of going about this. The first is that we could have a custom settings widget which configures basic default printer configurations which are then set in sd-devices (e.g. though [vm-config](https://dev.qubes-os.org/projects/core-admin/en/latest/_modules/qubes/ext/vm_config.html?highlight=vm-config)). The other is something @apyrgio suggested. I'll detail it later in the post.

Here is how it could look in a way where Dangerzone is integrated into the print workflow:

After mentioning some initial ideas with @apyrgio about the potential Dangerzone integration, he had some interesting suggestions:

"Hub" model instead of "Chain" model

Instead of having sd-viewer talk to sd-devices, why to have instead sd-app talk to each. This is a discussion point that came up early when we were thinking about how to generically add processing pipelines.

Chain model (the one originally proposed)	Hub Model

Using the hub model has clear advantages:

1. It gives a trusted part of the system (sd-app) the control flow (as opposed to each processing step passing it onto the next)
2. It removes the need to send each processing step information about the processing chain
3. sd-app as the middleman can keep the user informed about the status of the whole thing
4. other benefits like being able to have first page previews of the documents which were already opened (thanks to Dangerzone)

Here is what the "Hub" approach could look like for the sanitized print-from-sd-viewer version:

Printing from the client to directly convert via Dangerzone

However, @apyrgio had a suggestion when printing from the client. Basically the idea idea is to convert through Dangerzone directly instead of having to mess with triggering the print dialogue in the viewer. Here's a diagram to make it more visual, building on top of the "Hub" model:

This idea adds some value:

• no need to figure out how to trigger the print dialogue after the viewer opens
• in this case we could just show the "real" printer dialogue in sd-devices (i.e. the printer dialogue which really sees the physical printer and can thus provide meaningful printer-specific options like duplex or print quality)

But it has some downsides:

• UX would be worse because for large documents because the print dialogue would only show after the Dangerzone conversion (which can take a while). So if the user is printing multiple documents they they run the risk of not knowing for which file the dialogue is for
• final docs could be different. In one case (print from sd-viewer) it prints from the default viewer. Then print from client would directly go through Dangerzone. This would mean that the workstation's viewers would need to be in sync with Dangerzone because otherwise some documents can be printed from sd-viewer but not directly from the client (through Dangerzone directly).

So in general for this one I'm a bit more leaning towards @zenmonkeykstop's option to consider ditching the print from SD-app workflow anyways.

Good stuff @deeplow - there might be an argument for just dropping the client app print functionality altogether, letting the user open the file in the appropriate viewer app and print from there if they can. Would reduce client complexity by a bit and give folks an unambiguous path to printing.

The only thing that I'd add is add some user education. Something like greying out print for a few releases at first and adding a tooltip telling users that print is now available from the document viewing.

[deeplow]

After a team meeting discussion, the team agreed that "print from sd-viewer" sounds like a potentially good idea and we know that this is something users intuitively try do in order to print, but it is probably for for right now, since it still has a fair bit of UX and security complexity. It's more work than what we can take right now for the 0.15.0 milestone.

For now let's just use a drop-in front-end for XPP, let's look at packages already available on Debian, ideally avoiding a custom front-end.