PrivatePDF

Trust

Code transparency, and the honest weak point

Every product that does cryptography in a browser has the same unavoidable flaw, and most of them do not mention it. Ours is worth stating in one sentence before anything else.

The problem

What follows is what we actually do about it. We claim only what has shipped: the second list below is the work that does not exist yet, and it stays there until it does.

We ship you the JavaScript on every page load, so we could ship malicious JavaScript tomorrow. No amount of client-side engineering removes that.

In place today

  • A strict Content-Security-Policy in the editor: script-src 'self' 'wasm-unsafe-eval'. No inline script, no third-party origin, and no JavaScript eval. The one addition, 'wasm-unsafe-eval', permits WebAssembly compilation and nothing else — without it PDFium and qpdf cannot start at all, so this is a requirement rather than a relaxation. A test fails the build if any cross-origin source ever appears in this policy.
  • The editor is cross-origin isolated, with COOP same-origin and COEP require-corp. That is also what makes WebAssembly threads available.
  • No third-party code runs in the document that touches your file. This is the narrow, defensible version of the claim — not “no third-party code ever”. Advertising is planned for the content pages, and pretending otherwise would be the same dishonesty we are selling against.
  • Reproducible dependency resolution: a pinned toolchain, exact versions, and a frozen lockfile in CI.

Not built yet

Listed because a transparency page that omits its own gaps is marketing.

  • A SIGNED build manifest. The manifest itself now exists: /build-manifest.json lists a SHA-256 of every file this deployment serves, and scripts/verify-manifest.mjs fetches a live site and checks every one of them. Two things are still missing, and they are the two that matter most. No signing key is configured, so it ships unsigned — which proves the files match the list, not who wrote the list. And it is not published to a public transparency log, without which a release is auditable but not provably immutable: we could serve you one manifest and somebody else another. The /api/manifest endpoint still returns a stub.
  • A verifier extension that checks the page you loaded against that manifest on every visit.
  • Public source, and a third-party audit. Both are prerequisites for any paid tier rather than something that follows one.
  • A desktop build — the real answer for high-assurance users, since it does not change underneath you.

Why in that order

The list is cheapest-first, and each item is worth something on its own. A strict policy does not stop a malicious release, but it does stop an accidental one, and it makes a deliberate one visible in a diff.

The manifest and the transparency log are what turn “trust us” into “check us”. That is why they gate a paid tier rather than following one: charging for privacy before you can verify it would be the wrong way round.