Dangerzone as a file viewer

[apyrgio]

The current functionality of Dangerzone is that of a document sanitizer. Users who open documents using Dangerzone are presented with the Dangerzone UI, asking the user to choose where to save the sanitized document. Then, they can open the sanitized document themselves. This is a manual and time-inneficient way to sanitize documents, so we expect that users will typically choose to do so only for documents they feel it's worth the hassle. Therefore, we don't expect that any user has Dangerzone as the default application for opening files.

This has the following problems:

1. Users may choose not to sanitize a file they is actually dangerous. This can potentially happen if trusted contact points are infected with malware.
2. Users may mistakenly open an unsafe file, even if they wanted to sanitize it.

In this issue we will explore how can Dangerzone act as a file viewer, with the ultimate goal of having Dangerzone as the default document viewer in the user's machine.

Notes / Evidence (added by @deeplow)

It's easy to mistakenly open a document, if Dangerzone is not set as the default document viewer.

[apyrgio]

How would this work?

Method 1: Open the file in a container with X11 support

On Linux, it's pretty easy to mount the host's X11 socket to a container, and open a GUI application. This means that we can open LibreOffice, a PDF, or an image viewer, and it will draw in the user's screen. In Windows, this is supported natively as well in WSL. In MacOS, things are more tricky as users also need to install XQuartz.

This method is probably the fastest one, but it has two important drawbacks:

1. The X11 protocol was not designed with security in mind. An X11 application can sniff clipboard contents, for instance.
2. An X11 server may have a bug, that can be exploited by the application within the container.

Method 2: Stream sanitized content

If we start a container for the 1st stage of the conversion immediately, we can start receiving pixels in a few seconds time. Then, we can show these pixels to the user. There are two ways to show the pixels to the user:

1. Use linearized PDFs: Linearized PDFs use a PDF feature called "Fast Web View". We can create such PDFs with https://github.com/pikepdf and Ghostscript.

   (TODO: How to show linearized PDFs to users, while the conversion is still going? Does Qt's Web Engine View support linearized PDFs?)

2. Show the PDFs as a list of images. In Qt, we can create a dynamic list of images that the user can browse.

[deeplow]

This has been a long-standing hypothesis of mine: if Dangerzone would be better primarily as a viewer application and secondly as conversion tool (to santize docs in bulk or to sanitize one after preview).

Achieving this would allow users to conveniently set Dangerzone as the default document viewer, without getting too much in the way.

[deeplow]

The Qubes-equivalent of this feature is the "open in disposable qube" by default setting that's still in development:

QubesOS/qubes-issues#6366 (comment)

Although in Qubes this is currently possible, one can't do it through the UI. It requires some playing around with some mimetype settings (like what SecureDrop Workstation does here)

[deeplow]

I should also note that the auto-opening of the converted document on the preview app can be confusing because the user takes a moment to realize that they're no longer on Dangerzone. Here's an example of this situation (from our user research)

[screen note] PDF opens in preview App

[participant] um, okay um, this is the... like the preview macOS app? so it just opened in a different. I'm not sure if i'm still working in the... oh, it's is the preview app. Um... so i'm not working in the Dangerzone app anymore.

Having Dangerzone primarily as a preview application would avoid this confusion.

[eloquence]

I would recommend scoping a smaller (but still quite sizable!) issue to add preview to the application as-is, without changing viewer/editor defaults.

This would give us the opportunity to explore preview UX, technical implementation and performance characteristics, and would be a very useful feature in its own right.

As far as the default viewer experience is concerned, if we get preview to work well, what I could imagine is a default integration where Dangerzone opens up and offers the user a two panel view:

Left panel:

• File metadata
• Button option 1: Convert with Dangerzone / save trusted copy
• Button option 2: Open with built-in viewer/editor app

Right panel:

• Safe preview of file contents

In most use cases, users will need to at least have the option to open a file with a standard app (after all, they may need to edit it, or OCR may not be sufficient), but if we can make Dangerzone a convenient tool for the initial inspection of potentially dangerous files, that could offer a viable path for hooking it in as a default handler on systems that are routinely exposed to untrusted files.

[apyrgio]

I would recommend scoping a smaller (but still quite sizable!) issue to add preview to the application as-is, without changing viewer/editor defaults.

I agree, making Dangezone the default app for PDFs / office documents is the tip of the iceberg, and we can introduce it once we have a solid story UX wise. We can open separate issues for the technical parts, as we agree that we can work on them.

In most use cases, users will need to at least have the option to open a file with a standard app (after all, they may need to edit it, or OCR may not be sufficient), but if we can make Dangerzone a convenient tool for the initial inspection of potentially dangerous files, that could offer a viable path for hooking it in as a default handler on systems that are routinely exposed to untrusted files.

That's sensible, I agree.

[eloquence]

Still an open Q: is a single page preview (just the first page) "good enough" to already add significant value for the user?

[deeplow]

It turns out that we can use libreoffice to get just the first page or the first few (or potentially in increasing-size batches). This can be done with:

libreoffice --headless --safe-mode --convert-to 'pdf:writer_pdf_Export:{"PageRange":{"type":"string","value":"1"}}' --outdir /tmp tests/test_docs/sample-odt.odt

This is thanks to this libreoffice commit.