How we check every hour that our PDF API stores nothing

Every hour, a script tests our PDF API to ensure it does not store any documents sent through it. This is done by sending a document with a unique marker through the public API and searching for the marker in various locations, including the API's own files, logs, temp files, databases and containers. If the marker is found anywhere, the test fails and the result is published on a public page.

Most PDF APIs claim they do not keep your documents, but verifying this claim is difficult as most privacy policies are hard to check. The reason for this is because documents are often stored in unexpected places, such as Chromium's files, logs, crash dumps, and delivery options. To address these issues, our HTML to PDF API, called pagenull, is built to prevent any document storage.

This is achieved by setting up a strict setup that closes off all potential storage locations. The setup includes a read-only filesystem, fresh incognito context per render, crash reporter disabled, and a logger that only accepts specific metadata. Additionally, pagenull does not have any storage option built-in and refuses to keep documents in private or cloud metadata addresses.

The marker used in the tests is a unique string that is only present in one request and can be easily searched for in all potential storage locations. This marker is placed in an HTML document and sent through the API as a free test render. The test searches for the marker in the test render's response, container logs, renderer temp files, all files written by any container, and a dump of the database.

The result of this test is then published on a public page for transparency. In addition to the hourly check, the code is also tested through automated tests before every deployment. These tests specifically check that no files are written, no traces are left on disk, and no write paths are present in the code. This helps to prevent any potential issues from arising in future updates.

Lastly, every render comes back with a signature, called a receipt, which proves what was produced, when, where and with which build. This receipt is an Ed25519 signature over various pieces of information including the render id, SHA-256 of the PDF, the time and region, the renderer build, and stored: false. Anyone can check this receipt against a public key to verify the integrity of the produced document.

However, this method cannot prove that any data has been deleted, only that it was not stored at the time of the test.