Omitly — Public Threat Model

Version: 2.2 · Status: Published · Last updated: 2026-10-19 · Applies to: Omitly 4.1.x — the desktop app (macOS and Windows), the engine CLI, and the omitly-mcp server

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 seal keys on each install; the integrity of the Omitly binary itself.

1.5 The tamper-evidence seal (seal v2)

Since Omitly 4.0, a redaction output is sealed with seal v2, specified in docs/SEAL-SPEC-v2.md (version 1.0.1, frozen 2026-10-08). This section summarises what it is; the threats against it are in "Tamper-evidence seal" under §2 & 3.

What a valid seal means. Every byte of the delivered file, apart from the ranges the spec explicitly excludes, is byte-for-byte unchanged since it was sealed by the holder of the sealing keys. "Byte-for-byte" is literal: a re-save, linearisation or re-compression of the same document does not verify. The excluded ranges are the seal's own region and, for a PAdES-signed file only, the PAdES signature value (see below).

What a valid seal does not mean. It does not identify a person or organisation, it does not mean "produced by Omitly", and it does not prove when the document was sealed — time evidence is the separate, opt-in RFC 3161 anchor (B4), which is off by default. It also proves nothing about the redaction itself: the seal covers the embedded audit report, which is the producer's own record of what it checked (see "Audit log"). We do not describe the seal as "quantum-safe".

Construction.

• Two signatures ("legs") over one signed message: ECDSA P-384 (deterministic nonce per RFC 6979, low-S enforced) and ML-DSA-87 (FIPS 204, hedged, with a fixed context string). Both sign a deterministic-CBOR core that carries a SHA-512 digest of the file, the region's position, both public keys and, when a report is embedded, the SHA-384 of the exact report bytes. Both legs must verify; a leg that fails makes the seal invalid, never "partly valid".
• Carrier: the signatures live in an uncompressed embedded file named omitly-seal.env inside the PDF, and the file ends with a short tail line, %%OMITLY-SEAL v2 <offset> <length>. The verifier locates the region from the tail and the core; it does not parse the PDF to find or check the seal. Nothing may follow the tail: one extra byte, including a line-ending conversion, makes the seal invalid.
• Keys: each sealing identity is one 32-byte master seed, from which both legs' private keys are derived (HKDF-SHA-512). The desktop app keeps one seed per install in the OS keystore — macOS Keychain or Windows Credential Manager, service app.omitly.signing-key, account seal-v2 — written once. The engine CLI uses a fresh seed for every run, held only in memory. If the desktop cannot load its key, that one output is sealed with a one-time key instead and labelled as such. No Omitly-held (vendor) key is involved in sealing at all.
• Minting fails closed. Before a seal is published, each public key is derived by two independent implementations and must match; the ML-DSA-87 signature is checked by two implementations other than the one that made it, and the P-384 signature by one other implementation; and the finished file must then pass the shipping verifier. Any disagreement refuses the output and nothing is published. There is no fallback to a v1 seal for the same output.
• PAdES-signed output: when a document is digitally signed (PAdES) and sealed, the seal covers everything except the PAdES signature value, and the PAdES signature covers everything except its own value — including the seal. The verifier checks that the excluded range really is the signature field's hex value, so the exclusion cannot be pointed at document content. The verifier's result says the seal covers the document "except its digital-signature value" and to check the digital signature separately.

Policy epochs. Which legs a seal needs is decided by the verifier, not the file. Today (epoch 1) a seal is valid only if its P-384 leg verifies, and every other declared leg that this build implements (today: ML-DSA-87) must verify too. A published plan moves the requirement to ML-DSA-87 at a cutover release no later than the end of 2029 (epoch 2). How epoch 2 will treat seals made before the cutover is not decided yet.

Verdicts. valid; policy_insufficient ("signatures check out, but this seal does not meet the current requirement" — never shown as valid); invalid (any structural, digest or signature failure, content after the tail, or a stripped tail); unsupported (a newer format or feature this build cannot check — indeterminate, and unauthenticated, because anyone can write such bytes); and not sealed. The desktop Verify screen, the engine CLI's verify_seal command (which the npm package's omitly verify-seal and omitly-mcp's verify_seal / verify_document run), and the redactor's own pre-publish check all use the same dispatch and verifier code. There is no WebAssembly seal verifier.

Where the legacy v1 seal remains. v1 (Ed25519, %%OMITLY-SEAL v1) seals keep verifying exactly as before, permanently. Omitly still mints a v1 seal in one place: PAdES signing of a document that already carries a v1 seal and v1 report from before 4.0 (a v2 seal could not keep that report verifiable, because the report names the old key). Until 4.1 a replacement-stamp ("restamp") of a delivery also minted v1; since omitly#1571 the engine draws Replace and pseudonym labels before the report is built, and those outputs carry the v2 report and seal. A password-protected export is not sealed at all, because encryption changes the bytes the seal would cover; the report says so.

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

Tamper-evidence seal (seal v2)

What the seal is and is not is in §1.5. Four attackers are considered: a tamperer who edits a sealed file; a forger who wants a valid seal under keys they do not hold; a key holder who seals files with keys of their own (anyone can: the CLI makes one-time keys on every run); and a parser-differential attacker who builds a file that different PDF readers, or different parts of Omitly, see differently.

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. The engine's suite (over 1,100 Rust tests in redaction-core) asserts 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 seal is tested against the spec's attack cases and external vectors, not only round-trips. Seal v2's tests cover the spec's conformance cases (among them a stripped tail, appended bytes, a line-ending conversion, non-canonical encodings, a removed leg, a high-S signature, a wrong ML-DSA context and each PAdES-hole rule), the FIPS 204 ACVP ML-DSA-87 and Wycheproof ECDSA P-384 vector files, and a key-derivation known-answer test whose cryptographic steps were computed with OpenSSL rather than the crates under test. The engine CLI's seal-verification output is pinned by a shared contract case (contract/cases/verify_seal_v2.json) that the npm package and omitly-mcp also test against.
• 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 sidecars — not implemented for redactions. The redaction .audit.json and .audit.html sidecars are unsigned files (Check's saved report is sealed since 4.1.0, omitly#1570), and the report's created_at is the local clock. The copy of the report embedded in the delivered PDF is covered by the whole-file seal (seal v2 binds its exact bytes) and, when anchoring is on, by the RFC 3161 anchor — see the Audit log table. Omitly does not claim the sidecars are signed; verify the PDF.
2. Code signing / notarization — in place on both platforms (see Application / supply chain). The live residual is the Windows OV code-signing certificate, which expires on 2027-07-17; renewal into the HSM-backed key store is tracked as omitly#372 and must happen before that date, or Windows release builds cannot be signed.
3. Sandbox parity off macOS — extend the qpdf sandboxing approach to Windows.
4. MCP server boundary — not yet documented here (omitly#1558). omitly-mcp is published and functional (§1.2). It widens the trust boundary from "a human selecting files through an OS dialog" to "a local AI agent choosing file paths", and a document's content can steer what that agent asks for next. Access controls exist: every path is confined to one directory (OMITLY_ALLOWED_DIR, otherwise the directory the server was started in — so a server started from the home directory is confined only to the home directory), symlinks are resolved before the check, outputs never overwrite an existing file, and licensing is enforced inside the engine binary. These are guardrails against confused-deputy mistakes, not a sandbox against a hostile local user. The full section is still to be written: it will map each tool to read or write, and confirm the MCP network surface — including create_pdf, which renders HTML in a headless browser through a separate binary not distributed outside the source repository. A known open issue: verify_redaction follows a symlinked .audit.json sidecar outside the allowed directory and can echo reason codes from it (omitly#1563, low severity; it needs such a symlink to exist already).
5. SBOM / CBOM — partly done. Both are generated and drift-checked in CI. The CBOM is public on the security portal's Cryptography page; the full SBOM is available to customers through the portal's customer access. Not yet done: attaching the SBOM and CBOM to each release.
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 tamper-evidence seal, §1.5). (a) is surfaced in every verify_signature result's warnings; (b) is emitted by the backend only when the certificate carries a common name, so the Verify panel's "Digital signature" section additionally renders it as a fixed UI line on every signed document (omitly#923) — the boundary must not disappear in exactly the case where the signer's identity is least legible. Both reach the user in the UI, 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 the object each standard /Metadata key points at, wherever that key appears. An object that has to stay because something else still references it is emptied completely — its whole dictionary and content — so nothing it pointed to stays reachable through it. Before 4.0.1 an XMP stream held by a nonstandard key kept its other keys, and an object hanging off it survived into the output while the check reported clean (omitly#1586, fixed in 4.0.1 and pinned end to end through the real qpdf finalize). 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, so it is a known limit, by decision (owner, 2026-10-15; omitly#592): the scrub is not widened, and any claim about metadata removal — marketing, questionnaires, certificate wording — must say "declared metadata", never "all metadata" or "no XML remains".
9. Seal v2 has stated limits, not silent gaps: (a) No origin. A valid seal shows only that the file is unchanged since someone holding those keys sealed it; there is no Omitly signing identity, so anyone can seal anything (§1.5, "Tamper-evidence seal"). (b) Time needs the anchor, and the anchor is off by default. A seal minted before the post-quantum cutover rests on P-384. Lasting evidence that it predates a future break needs an RFC 3161 anchor, which most outputs will not have (#1060). How the cutover release treats such seals is not yet decided. (c) Unknown algorithms. A leg whose algorithm a verifier does not know is reported as "not checked", not as valid. Its signature bytes can be replaced without that verifier noticing; a verifier that knows the algorithm detects the change. No such leg is minted today. (d) Seals can be removed. A file rewritten without its seal envelope and tail reads as "not sealed", unless it still carries Omitly's sealed report: then, since 4.0.1, Verify says the seal was removed (omitly#1591). The seal cannot be moved onto changed content, but a recipient who expects a sealed file must treat "not sealed" as a failure. (e) v1 files. Legacy v1 (Ed25519-only) seals keep verifying as before and gain no post-quantum leg. A separate "witness" for pre-4.0 files is planned, but its format is not yet specified.
10. Check: Omitly's own attachment names (sev:high, fixed in 4.0.1). Before 4.0.1, Check skipped an attachment named omitly-audit.json or omitly-license.json as Omitly's own whenever it was held in Omitly's single-holder shape, and nothing tied that attachment's content to a genuine Omitly report or licence. A file carrying an arbitrary payload under one of those names could read Safe to Send on every Check surface — desktop, the web checker, MCP and the CLI — with no seal or key needed (omitly#1579). Since 4.0.1, Check skips the report only when it is bound to the file's verified seal, and never skips the licence name; anything else is flagged like any other attachment. Since 4.0.1 the skipped attachment must also verify as a genuine audit report, through the same checks Verify runs; before that, any JSON naming its own sealing key was skipped (omitly#1582). The bound is still integrity, not origin: seal keys are per install or one-time, so anyone can build a schema-valid report naming their own key, put text in its ordinary fields, seal the file, and Check will skip it (omitly#1595, open). Do not treat Check's "no embedded files" line as covering an attachment named omitly-audit.json in a file whose sender you do not trust.
11. v4.1 "Trust the verdict": fixed after 4.1.0, and what was deferred. These fixes landed after 4.1.0 shipped and reach users in the next release: the Type3 refusal (omitly#568), unreferenced-object reporting (omitly#1610), the v2 report for Replace and pseudonymised outputs (omitly#1571), the .notdef glyph check (omitly#1519), and stale-evidence removal on Save, Extract and Sign (omitly#1103). Until then, 4.1.0 behaves as the earlier text of this document described. Deferred, and not claimed: (a) the drawn-glyph check does not yet cover CID fonts, codes with no single-character /ToUnicode mapping, TrueType remappings that can only be compared by glyph name when the font has none, or a font whose outline for one character draws as another (omitly#1620); (b) the stale-evidence rule does not yet cover the print path, the CLI and omitly-mcp publish paths, certificate export, encrypted export or omitly-compare -o (omitly#1621); (c) the Check report-binding limit in item 10 (omitly#1595) is open.

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.

Changes in 2.2 (2026-10-19). Updated for the v4.1 release, "Trust the verdict" (omitly#1559): the annotation and form-field removal and the Type3 refusal (omitly#568); a new row for false Safe to Send verdicts, covering the survivor-check fixes (omitly#1528, #1529, #1533, #1607, #1459, #1518, #1532, #1601) and, after 4.1.0, #1610 and #1519; the sealed Check report (omitly#1570) and the encrypted export without a report (omitly#1497); the PAdES revision walk (omitly#1605, #1614); the write rule for delivered outputs (omitly#1613); and §4.2 item 11, which separates what shipped in 4.1.0 from what ships next and lists what was deferred with its issue numbers.

Changes in 2.0 (2026-10-13). Added the seal v2 description (§1.5) and its threat model ("Tamper-evidence seal" under §2 & 3, §4.2 item 9), and the open Check finding on Omitly's own attachment names (§4.2 item 10). Corrected statements that had fallen behind the product (omitly#1556): the status, date and platforms; the MCP server, described as both functional and a stub, is now described once and correctly, with its boundary documentation recorded as the gap (§4.2 item 4); code signing and notarization, which are in place, and the certificate-renewal residual; SBOM/CBOM status; the read-path allowlist; both unsigned sidecars; the anchor's coverage of the embedded report; the size of the engine's test suite; and the engine's environment inputs. The earlier revision was dated 2026-07-01 and carried no version number.