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, Omitly makes no network calls. Network access occurs only after an explicit user action: requesting a trusted RFC 3161 timestamp while digitally signing a document (§1.3), enabling sealed-output anchoring (§1.3, B4), clicking Check for updates, downloading an update, or submitting the support form. Neither RFC 3161 path sends document content; each sends only a cryptographic digest. The updater sends only the app's version/platform to fetch the release manifest, and the support form sends only what the user submits plus app version/OS. See "Network surface" below §1.3 for the complete, exhaustive list; 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
    core -.->|B4: OPT-IN ONLY —<br/>sealed-output 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 — PAdES timestamping, 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.
• B4 — certificate anchoring, opt-in and disclosed. Added 2026-07 (issue #107) as default-OFF, default-ON from #561, and default-OFF again since #1060 so redaction makes no automatic outbound request. If the user enables "Timestamp proof" (a real opt-in, persisted across launches), Omitly sends one RFC 3161 request carrying the SHA-256 of the delivered, sealed output file — never the document, filename, or any PDF bytes — to the same user-configurable TSA machinery as B3, and stores the returned token in a <output>.pdf.anchor.json sidecar (raw DER, independently verifiable with third-party tools). Leaving it off means zero network calls and byte-identical behaviour to before the feature existed. A sealed document cannot be retroactively upgraded, so leaving it off forgoes the only mechanism that can later witness a classical-era seal as pre-dating a future break. A failure is never silent: it produces an honest "anchored": false record AND a visible warning stating the document was not timestamped while the redaction itself is complete, verified and sealed. The request runs strictly after the output file is written, so an unreachable or hung TSA can never fail, alter or corrupt a redaction. It is not latency-free: the synchronous call can delay the UI returning to idle by up to the bounded 8-second timeout, after the delivered file is already complete on disk. What the anchor proves — and deliberately does not — is documented in SECURITY.md ("proves WHEN, never WHO").
• App-level (non-document) network paths, for completeness (added in 1.0.0, after this document's document-pipeline boundaries were written): the Tauri updater fetches a signed release manifest only after the user clicks Check for updates, and downloads an update only after a further explicit action. A local-only 14-day reminder tells users that Omitly does not check on their behalf. The About-box "Contact support" form POSTs the user's typed message plus app version/OS string to https://omitly.app/api/support, only when the user submits it. Neither path touches PDF content, document bytes, hashes of documents, or redaction data — the document pipeline (B1-B4) remains the complete map of anything document-derived.
• Redacted/signed PDFs and the audit/anchor sidecars 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 with document-derived data, and whether any of it reaches the network. B3 and B4 above are the only code paths that can send anything derived from a document (each a digest and each opt-in); the app-level updater and support paths (previous section) carry no document-derived data at all. Anything not listed as reaching a network path is, structurally, local-only.

Why an enabled timestamp needs a network call: a timestamp that actually means something under RFC 3161 requires an independent third party (the TSA) to attest to the time. What Omitly controls, and has minimized: (1) the request carries a digest only, never content; (2) B3 and B4 are both explicit opt-ins and never background calls; (3) the TSA is user-configurable, so the destination is the user's to change; and (4) declining is a fully supported, fully local alternative in both cases (PAdES-B-B signing; an unanchored seal).

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. Exactly two code paths can send document-derived data, both digest-only and opt-in — B3 and B4 RFC 3161 timestamping; see the "Network surface" table in §1.3. The manual updater and support paths carry nothing document-derived. No path makes an automatic request.

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.
7. Hidden-content sanitization (added 2026-07) has four stated scope boundaries, not silent gaps: (a) a hidden optional-content layer is detected and blocked from a clean verdict, but its content is not (yet) removed or flattened from the file — a viewer configured to ignore the default visibility state, or a future update to the layer's default state, could still expose it; full removal is planned as a follow-on. (b) PDF/A conformance is not preserved by any of this (it was already broken by the pre-existing metadata scrub, unrelated to this feature). (c) /OutputIntents (the embedded ICC colour profile) is left in place — it carries no document content. (d) The hidden-layer check resolves the default screen viewing configuration only; a layer that is visible on screen but hidden specifically when printing (or vice versa, via /Usage/Print) is not covered. Within that screen configuration, a /D/AS usage auto-state is resolved for the /View category (/ViewState /OFF hides); an auto-state naming only the /Zoom, /User, or /Language categories is deliberately not resolved and does not fail closed, because those depend on viewer state with no single correct default and blanket-failing them would reject ordinary layered CAD/GIS/InDesign exports.
8. Metadata scrub (scrub_all_metadata) has one stated scope boundary, not a silent gap (omitly#592): it removes objects declared as metadata (/Type /Metadata) and everything reachable via the standard /Metadata key at any depth. A stream that declares no /Type /Metadata and is referenced only by a nonstandard key is indistinguishable from ordinary document content, and is out of scope for a metadata scrub — the claim metadata_scrubbed = true supports is "declared metadata is removed," not "no XML anywhere survives." Widening this to a content sniff risks deleting legitimate document content and is deliberately not done without a separate decision; tracked as the open half of omitly#592.

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.