https://en.wikipedia.org/wiki/Traitor_tracing#Watermarking
https://arxiv.org/abs/1111.3597
The watermark can even be contained in the wording itself (multiple versions of sentences, word choice etc stores the entropy). The only moderately safe thing to leak would be a pure text full paraphrasing of the material. But that wouldn't inspire much trust as a source.
And specifically about them not being hacked by malicious code. I'm not seeing anything that suggests it's about trying to remove traces of a file's origin.
I don't see why it would need a warning for something it's not designed for at all.
Like IDEs do when you open random projects
I don't think watermarking is a winning game for the watermarker, with enough copies any errors can be cancelled.
This is a very common assumption that turns out to be false.
There are Tardos probabilistic codes (see the paper I linked) which have the watermark scale as the square of the traitor count.
For example, with a watermark of just 400 bits, 4 traitors (who try their best to corrupt the watermark) will stand out enough to merit investigation and with 800 bits be accused without any doubt. This is for a binary alphabet, with text you can generate a bigger alphabet and have shorter watermarks.
These are typically intended for tracing pirated content, so they carry the so-called Marking Assumption (if given two or more versions of a piece of content, you must choose one. A pirate isn't going to corrupt or remove a piece of video, that would be unsuitable for leaking). So it would likely be possible to get better results with documents, may require larger watermarks to get such traitors reliably.
Security-wise, our main concern is protecting people who read suspicious documents, such as journalists and activists, but we do have sources/leakers in our threat model as well. Our docs are lacking in this regard, but we will update them with information targeted specifically to non-technical sources/leakers about the following threats:
- Metadata (simple/deep)
- Redactions (surprisingly easy to get wrong)
- Physical watermarking (e.g., printer tracking dots)
- Digital watermarking (what you're pointing out here)
- Fingerprinting (camera, audio, stylometry)
- Canary tokens (not metadata per se, but still a de-anonymization vector)
If you come in FOSDEM next week, we plan to talk about this subject there [2].
The goal here isn't to provide a false sense of security, nor frighten people. It's plain old harm reduction. We know (and encourage) sources to share documents that can help get a story out, but we also want to educate them about the circumstances in which they may contain their PII, so that they can make an informed choice.
[1]: https://social.freedom.press/@dangerzone/115859839710582670
[2]: https://fosdem.org/2026/schedule/event/JZ3F8W-dangerzone_ble...
(Dangerzone dev btw)
Isn't this what newspapers do?
https://github.com/caradoc-org/caradoc
http://spw16.langsec.org/slides/guillaume-endignoux-slides.p...
How hard did you look the other times?
It doesn't seem to be meant for usage at scale -- it's not for general-purpose conversion, as the resulting files are huge, will have OCR errors, etc.
There is indeed a dangerzone-cli tool¹, and it should be made more visible. We plan on updating/consolidating our docs in the foreseeable future, to make things clearer.
Also, plans are here to make it possible to use dangerzone as a library, which should help use cases like the one you mention.
¹ https://github.com/freedomofpress/dangerzone/blob/main/dange...
It is a passion project and will always be free because commercial CDR[1] solutions are insanely expensive and everyone should have access to the tools to compute securely.
1. https://en.wikipedia.org/wiki/Content_Disarm_%26_Reconstruct...
For some reason, printing 1 page of an Excel or Word document to a PDF often gets up to around 4MB in size. Passing it through this compresses it quite well.
Just ran a quick test:
- 1-page Excel PDF export: 3.7MB
- Processing with Dangerzone (OCR enabled): 131KB
But you can use qpdf or PDFEdit to interpret a PDF's raw code.
https://stackoverflow.com/a/6562443
And thus, you can compare the raw XLSX (XML) vs raw PDF.
The size is probably font embedding.
And then the OCR will probably not be 100% correct if you ever intend to copy-paste from it.
But probably the main security here is just using the chrome pdf viewer instead of the adobe one. Which you can do without google drive. The browser PDF viewers ignore all the strange and risky parts of the PDF spec that would likely be exploited.
That's something I do from time to time as well. AFAIK Google Drive renders all documents on the server-side (which implicitly means that they don't trust the browser sandbox), so that's a reasonable price to pay for less privacy.
Dealing with sensitive documents though is another story, you just can't upload them to a third-party service. That's where projects like Dangerzone come into play.
https://github.com/mate-desktop/atril
A crafted PDF can potentially exploit a bug in atril to compromise the recipient's computer since writing memory-safe C is difficult. This approach was famously used by a malware vendor to exploit iMessage through a compressed image format that's part of the PDF standard:
https://projectzero.google/2021/12/a-deep-dive-into-nso-zero...
The Chrome PDF parser, originating from Foxit (now open-sourced as PDFium), has been the source of many exploits in Chrome itself over the years.
That's a good question :-)
Opening PDFs, or images, or any other document directly inside your machine, even with a limited PDF viewer, potentially exposes your environment to this document.
The reason is that exploits in the image/font/docs parsing/rendering libraries can happen and are exploited in the wild. These exploits make it possible for an attacker to access the memory of the host, and in the worse case allow code execution.
Actually, that's the very threat Dangerzone is designed to protect you from.
We do that by doing the docs to pixel conversion inside a hardened container that uses gVisor to reduce the attack surface ¹
One other way to think about it is to actually consider document rendering unsafe. The approach Dangerzone is taking is to make sure the environment doing the conversion is as unprivileged as possible.
In practice, an attack is still possible, but much more costly: an attacker will be required to do a container escape or find a bug in the Linux kernel/gVisor in addition to finding an exploit in document rendering tools.
Not impossible, but multiple times more difficult.
¹ We covered that in more details in this article https://dangerzone.rocks/news/2024-09-23-gvisor/
Aren't risks similar when opening any untrusted web page in a browser?
The only difference is that browser sandbox and exploit mitigations are probably better than that of a PDF viewer.
You are correct: that's basically what Dangerzone is doing!
The challenges for us are to have a sandbox that keeps being secure and make it possible for non-tech folks (e.g. journalists) to run this in their machines easily.
About the sandbox:
- Making sure that it's still updated requires some work: that's testing new container images, and having a way to distribute them securely to the host machines ;
- In addition to running in a container, we reduce the attack surface by using gVisor¹ ;
- We pass a few flags to the Docker/Podman invocation, effectively blocking network access and reducing the authorized system calls ;
Also, in our case the sandbox doesn't mount the host filesystem in any way, and we're streaming back pixels, that will be then written to a PDF by the host (we're also currently considering adding the option to write back images instead).
The other part of the work is to make that easily accessible to non-tech folks. That means packaging Podman on macOS/Windows, and providing an interface that works on all major OSes.
It would be better to strip active content like javascript and actions, without flattening the PDF and losing all the text data having the original text is better than sending it through ocr again.
This would have been useful-- but I think I would have layered it on top of other isolation.
([1] constructed from a media converter pair, a fiber splitter to bring the link up on the tx side, and some off the shelf software for multicast file distribution).
I imagine that folks like journalists could have that type of attack in their threat model, and EFF already do a lot of great stuff in this space :)
0. https://isc.sans.edu/diary/31998
1. https://www.cloudflare.com/cloudforce-one/research/svgs-the-...
The employment readyness check if you can trust a company.
