Omitly — Public Threat Model

Status: Draft for review · Last updated: 2026-07-01 · Applies to: Omitly desktop (macOS; Windows at launch)

This document is Omitly's Public Threat Model (PTM). It exists so that customers, security reviewers, and the wider community can evaluate our security claims against the threats they care about — rather than being asked to "trust us." It describes how Omitly is secured; it is not a guide to attacking it.

Why we publish this

Omitly's value proposition is itself a security claim: we remove the underlying data from a PDF, independently verify it is gone, and never send your documents anywhere. A claim like that should be falsifiable. Following the argument made by Loren Kohnfelder and Adam Shostack in "Publish Your Threat Models!" (2025) — and the principle of Open Design (Saltzer & Schroeder) — we believe the benefits of publishing far outweigh the risks. A threat model describes how a product is secured, not how to break it; if any part of it felt too dangerous to publish, that would be a signal of a real weakness to fix rather than hide.

This is also where the industry is heading: the EU Cyber Resilience Act will effectively require documented cybersecurity risk assessments, and CISA's Secure by Design and Australia's Secure by Demand both push toward this kind of transparency.

This model is organized around Shostack's Four Question Framework:

1. What are we working on?
2. What can go wrong?
3. What are we going to do about it?
4. Did we do a good enough job?

1. What are we working on?

1.1 Product summary

Omitly is a local-only desktop PDF reader and editor. Its headline capability is verifiable redaction: it removes the underlying text and image data for a redacted region (it does not merely draw a black box), then independently verifies on the output that the data is unrecoverable.

By default, nothing is uploaded and the application makes no network calls. As of 2026-07, there is exactly one opt-in exception: requesting a trusted RFC 3161 timestamp while digitally signing a document (§1.3). It is off unless the user turns it on for that specific signature, and it sends only a cryptographic hash — never document content. See "Network surface" below §1.3 for the complete, exhaustive list of what is and isn't local; nothing outside that list reaches the network.

1.2 Components

1.3 Trust boundaries and data flow

flowchart TD
    user([User]) -->|chooses file via OS dialog| webview

    subgraph device[User's device]
        webview[Webview UI<br/>PDF.js / pdf-lib<br/>no FS access]
        core[Tauri/Rust core<br/>file/redact/verify/sign commands]
        engine[redaction-core<br/>lopdf + Sig placeholder]
        qpdf[qpdf sidecar<br/>native C++]
        disk[(Local disk)]

        webview -->|B1: IPC — paths, PDF bytes, regions| core
        core -->|B2: untrusted PDF bytes| engine
        engine -->|process boundary| qpdf
        qpdf -->|sandboxed: temp-only writes, no network| engine
        core -->|redacted/signed PDF + audit.json| disk
    end

    tsa[(RFC 3161 Timestamp<br/>Authority — third party)]
    core -.->|B3: OPT-IN ONLY —<br/>signature hash alone,<br/>never document content| tsa

    classDef boundary fill:#fef3c7,stroke:#b45309;
    classDef network fill:#fee2e2,stroke:#b91c1c,stroke-dasharray: 5 5;
    class core,qpdf boundary;
    class tsa network;

• B1 — Webview ↔ Rust core (IPC). The lower-trust webview cannot touch the filesystem; it can only ask the Rust core to act on paths the user selected through an OS dialog. Enforced by Tauri capabilities (no fs: capability granted to the webview) and a restrictive Content Security Policy.
• B2 — Rust core ↔ qpdf sidecar (process). Untrusted PDF bytes are processed by a native C++ binary — the largest native attack surface. On macOS this runs under a deny-by-default seatbelt sandbox (read anywhere, write only to temp, no network). Arguments are passed as explicit argv, never through a shell.
• B3 — the app's only network boundary, opt-in and disclosed. Added 2026-07 alongside PAdES digital signing: if (and only if) the user turns on "add a trusted timestamp" for a specific signature, Omitly sends an RFC 3161 request (a SHA-256/384 digest of the signature, plus the digest algorithm identifier — never the document, filename, or any PDF bytes) to a Time-Stamp Authority over HTTPS. The TSA endpoint is user-configurable (default: a public TSA; an organization can point this at its own internal TSA to keep the request off third-party infrastructure entirely). Signing without a timestamp remains fully available and makes zero network calls. See "Network surface" below for the exhaustive local-vs-network map.
• Redacted/signed PDFs and the audit sidecar are written only to the user-chosen location on local disk — this has not changed.

Network surface — the complete local-vs-network map

Everything Omitly does, and whether any of it reaches the network. This table is exhaustive by construction: B3 above is the only network-capable code path anywhere in the app, so anything not listed as reaching it is, structurally, local-only.

Why the minimum can't be lower than this: a timestamp that actually means something under RFC 3161 / PAdES-B-T requires an independent third party (the TSA) to attest to the time — that attestation is the entire value of the feature, and it cannot be produced without a network round trip to some TSA. What Omitly controls, and has minimized: (1) the request carries a digest only, never content; (2) it is per-signature opt-in, not a background/automatic call; (3) the TSA is user-configurable, so the destination of that one request is the user's choice, not Omitly's; (4) declining the timestamp is a fully supported, fully local (PAdES-B-B) alternative — the feature degrades gracefully to zero network calls rather than requiring one.

1.4 Assets we protect

The user's document content (especially the data being redacted); the integrity of the redaction result; the integrity of the audit record; the integrity of the Omitly binary itself.

2 & 3. What can go wrong, and what we do about it (STRIDE)

Threats are enumerated with STRIDE against the elements and boundaries above. Mitigations marked ⚠ Gap are not yet implemented and are tracked in §4.2.

Redaction engine (the core asset)

Audit log

Boundary B1 — Webview ↔ Rust core

Viewer text layer (selectable text in the preview — added 2026-07)

The preview now materializes the document's text as invisible DOM spans (a PDF.js text layer) so text can be selected and copied with the native OS gesture. This changes the in-webview surface and is bounded as follows:

Boundary B2 — Native PDF processing (qpdf / lopdf)

Application / supply chain

4. Did we do a good enough job?

4.1 How we validate (and how you can check)

• The redaction-correctness tests are treated as the product. ~20 tests assert that secrets (e.g. SSNs) are unrecoverable from the decompressed output, that neighboring content survives, that metadata and comment annotations are scrubbed, that image markers are removed, and that pages the engine can't fully reason about (inline images) are flagged rather than silently passed. These run with plain cargo test against the Tauri-independent engine.
• Verification is independent of redaction. The verify step re-derives its result from the output file, not from the engine's own bookkeeping, so a bug in removal does not produce a false "verified."
• The local-only claim is scoped and structurally enforced, not just asserted. There is exactly one network-capable code path in the entire app (boundary B3, opt-in RFC 3161 timestamping — see the "Network surface" table in §1.3), and no updater to invoke. Every other feature is checkable by the same method used before: there is no other network code path to find.

4.2 Known gaps and roadmap (stated honestly)

Per Shostack's guidance, a published threat model should include the complete set of threats — including those not yet fully mitigated. The following are known and tracked:

1. Signed audit log — not yet implemented. The audit sidecar is currently unsigned JSON with a local-clock timestamp. Planned: cryptographic signing (Ed25519 capability already exists in the licensing crate) and a tamper-evident format, ideally with a post-quantum / hybrid signature option. Until shipped, Omitly does not claim a "signed" audit log.
2. Code signing / notarization for distributed binaries — to be configured before public release.
3. Sandbox parity off macOS — extend the qpdf sandboxing approach to Windows.
4. MCP server (omitly-mcp) is a non-functional stub. When built, it would widen the trust boundary from "a human selecting files through an OS dialog" to "any local AI agent able to drive redaction over arbitrary file paths." It will need its own threat-model section and access controls before release.
5. Published SBOM / CBOM to substantiate the supply-chain and cryptography claims.
6. PAdES signing (added 2026-07) has two stated scope boundaries, not silent gaps: (a) no OCSP/CRL revocation checking — a signature that was valid when checked could have since been revoked and this build won't know; (b) no CA trust-chain validation — this is a bring-your-own-certificate (BYOC) self-signing feature, so a signer's reported identity is read directly from the certificate and is not confirmed against any external trust authority (the same "integrity, not identity" scope as the existing Ed25519 seal). Both are surfaced in every verify_signature result's warnings, not just here. Planned: PAdES-B-LT/LTA (embeds revocation evidence) and, longer-term, hardware-backed signing keys (YubiKey/Secure Enclave/Windows CNG) so the private key never exists as an exportable file at all.

4.3 Scope and assumptions (non-goals)

This model assumes a trustworthy host: Omitly does not defend against a compromised operating system, malware already running with the user's privileges, physical access to an unlocked device, or screen-capture of content displayed on screen. It covers the desktop application and redaction engine; it does not cover the marketing website (separate codebase and trust boundary) or any future cloud service (none exists today).

Methodology & precedent

This document follows the Threat Modeling Manifesto (2020) and Shostack's Four Question Framework, with threats enumerated via STRIDE. We publish in the spirit of peer privacy-and-security tools that publish their own threat models, including SecureDrop, Tor, cURL, and Kubernetes. We welcome scrutiny: if you find a threat we've missed or a mitigation that doesn't hold, please contact us.

This is a living document and will be revised on architecture changes, new features, security incidents, and at least annually.