Why We Open-Sourced Our Privacy Claims

We are not anti-policy. Legal text matters for rights, liability, and governance. But policy alone is a weak trust signal in fast-moving software products. Terms can be updated, feature boundaries can shift, and users rarely have the time to re-audit every release.

The gap between "we protect your data" and "here is exactly what happens to your file bytes" is where trust usually collapses. We wanted to close that gap with something operational, not rhetorical.

We framed a simple engineering question: what would a privacy claim look like if it were treated like a test case? The answer became /verify-claims. It gives users explicit steps: open DevTools, filter XHR/Fetch, run a file operation, inspect requests, and confirm whether payload data left the browser.

That workflow is intentionally boring. Boring is good in security. If a claim depends on hand-wavy interpretation, it is not robust.

If a privacy claim cannot survive a Network tab check, it is not a guarantee.

Share this tipCopy

We are not just publishing code snippets. We are publishing testable assertions and the method to challenge them. For example:

• Claim: core PDF tools process files locally.
• Test: observe network traffic during merge/split/compress/redact actions.
• Expected result: no file payload requests to remote processors.
• Failure condition: any outbound request containing document bytes.

This model converts trust from "believe us" into "repeat the test." That is a better default for developers, auditors, and security teams.

Engineers dislike unverifiable promises, especially in privacy and security. Hacker News, Reddit, and technical communities consistently reward products that show evidence, include caveats, and define threat models honestly.

We built Plain with the same cultural expectation we use in production engineering: if a behavior matters, instrument it. If a claim matters, document how to falsify it.

Once you commit to verification-first privacy, implementation choices change quickly. You avoid hidden upload fallbacks. You reduce optional third-party scripts. You expose clear UI consent boundaries. You treat network silence during core file processing as a non-negotiable product requirement.

The result is often a simpler system: fewer moving parts, fewer legal ambiguities, and clearer user expectations. Privacy becomes an architectural property, not a compliance afterthought.

You do not need to trust Plain by default. In fact, please do not. Use this checklist across all tools:

• Can I verify file data flow with built-in browser tools?
• Is there a documented offline test for core operations?
• Are AI features explicitly opt-in and separately disclosed?
• Are deletion/retention claims tied to specific workflows, not vague promises?

If a vendor cannot answer these clearly, you are not buying certainty. You are buying risk.

Start with /verify-claims. Then test a real workflow in Merge PDF or Redact PDF. Keep DevTools open while you process. If the claim holds under your own inspection, that is real trust.

Privacy should be inspectable infrastructure. That is what we are trying to build, and that is what we think users should expect everywhere.