Optinally Preserve Original Document Inside Sanitized (but neutralized)

[deeplow]

(originally posted in simplifying save options #427. Moving it here so it gets its dedicated discussion space)

This idea is a recognition of the two features Dangerzone has:

1. making documents safe to view
2. stripping the metadata

New Operating Mode: Preserve Original

This proposal consists of adding a second operating mode, which includes / embeds the original document inside the safe version but in a way that makes it harmless. This way the document could safely be opened. Should the journalist want to recover the original file, they could recover it using Dangerzone.

Why is this important?

Currently, Dangerzone fully removes document metadata and it becomes hard to manage what is original and what is sanitized. Specifically thinking about the SecureDrop Workstation, when Dangerzone is integrated, newsrooms may prefer to share the sanitized version with colleagues on non-Qubes laptops. But this would also create a document management problem: where to store the original for accountability and further investigation? Should is also be included, but in an unsafe folder?

By embedding the document, it becomes a matter of just managing one document, which can safely be opened, yet with the original a deconversion away, which would not need a specialized machine for. Just Dangerzone.

What could this look like in practice?

On the left is the new mode of operation and on the right, the traditional mode

Here's a breakdown of what each option does:

Embedded Conversion (safe mode)	Embedded Conversion (publish mode)
In "Safe" mode, Dangerzone makes the document harmless. This can later be reversed by using Dangerzone.	In Publish mode, dangerzone also remove the metadata and saves the file in a new location.

Warning document cover (optional)

A cover page could be added to the document to explain the following:

• inform that the file is not the original
• inform that the original is recoverable

Note: the "may have been" language is intentional. It is possible an attacker creates a malicious file with the same cover page. The presence of the cover page does not indicate that the document is sanitized. However, having the dangerzone cover will remind the reader that:

• this document contains the original and therefore should not be directly published (a cover page is a very visual reminder and will show in file previews)
• instructions on how to get the original (use Dangerzone)

Limitations

This approach does not consider the case where Dangerzone cannot create a sanitized version. One solution could be to simply fail. Another could be to return a single Dangerzone cover page indicating that the file could not be converted but the original is preserved inside.

[deeplow]

Implementation Questions

How to neutralize a file?

Some idea exploration in freedomofpress/securedrop-workstation#1139

How to embed arbitrary data in documents?

It turns out that PDFs are pretty flexible. Due to way they are parsed, it is possible to include arbitrary data which does not affect the viewing experience. A great example is the PoC||GTFO magazine which is a PDF which sometimes doubles-up as a zip file (including source code demos) or even a git repo 🤯.

[almet]

Hi, and thanks for this discussion.

My first reaction is: "but if we embed the document, could that be an attack vector?" In other words, how can we be sure that this document is actually "made harmless"?

Also, when you say "should the journalist want to recover the original file", is it a request you got from somebody?

[deeplow]

My first reaction is: "but if we embed the document, could that be an attack vector?" In other words, how can we be sure that this document is actually "made harmless"?

As long as the attacker has no control over the final output, then I think it can be considered harmless. A simple idea is to xor the file with a random key (and random length) and then embed in the sanitized file the key and the xored original. Although this naive idea would need validation.

[almet]

Ah okay, that makes more sense!

When you said "embed" it felt to me like "keep the original in some way and put it in the doc", hence why my interrogation. If we decide to go this direction, I think this might be worth to consider when thinking about the UX / wording we use.

My second question remains, so let me put it back again here: is it a request you got from somebody? (I wonder if journalists actually have a use case for this)

[deeplow]

My second question remains, so let me put it back again here: is it a request you got from somebody? (I wonder if journalists actually have a use case for this)

It's something I think makes sense. After all, documents are evidence. A journalist may not want to publish the original document to protect the original source, but having the original preserved may come in handy if they want to validate the file's authenticity or in case evidence is called into question and they ever need to reference the original file.

So I'd say "having files embedded" is not a use-case, but the broader issue is: being able to preserve the originals. If that is done through unsafe/ directories or embedded files is a matter of implementation and usability considerations.