Omitly — Public Threat Model

Version: 3.0 · Status: Published · Last updated: 2026-10-28 · Applies to: Omitly 4.1.x, plus the v4.3 "Certificate honesty" changes as built and not yet in a release (the Audit log rows and §4.2 item 13 marked v4.3) — the desktop app (macOS and Windows), the engine CLI, and the omitly-mcp server — and Legal Production Mode (folder redaction) as built for 4.2, which is not yet in a release (§1.2, §1.4)

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"). What the certificate says about time (v4.3, omitly#1560): nothing. The Omitly Release Check Certificate and the .audit.html report print no time claim beyond a Generated time taken from the verification result, and no anchor line; the RFC 3161 anchor, when present, is a separate .anchor.json sidecar that Verify checks on its own. No anchor is the default state (above), so a certificate without one is the normal case. OpenTimestamps, C2PA and PAdES B-LTA/LTA are planned, not attested: no surface prints them and none is claimed here.
• 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.
• Legal Production Mode (v4.2) adds no boundary and no network path. It drives B1 and B2 exactly as a single-file redaction does, once per file. It never anchors: the orchestrator passes no timestamp authority for any file (anchorTsaUrl: null in src/batch/orchestrator.ts), whatever the single-file "Timestamp proof" setting is, so B4 is never reached from a batch. Everything it writes goes into the output folder the user picked in a folder dialog (§1.4).

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.

Legal Production Mode (v4.2, not yet released) adds the artefacts below. All of them are written only inside the output folder the user picked in a folder dialog, and none of them leaves the device through Omitly (§1.3). Design: docs/BATCH-PRODUCTION-DESIGN-833.md (invariants B1–B8).

What a production discloses to its recipient, by design. A manifest or production log sent with a production states: the source and output folder names; the name, size, page count and SHA-256 of every input file, including those that were not produced (no occurrences, not searchable, unresolved, skipped, failed); why each one was held back, as a fixed code with a count (for example terms_in_metadata, with the number of matching strings); how many terms were searched and with which options; the naming template; start and finish times; app version and engine commit; the run id and any run it resumed; whether one-time keys were used; and each output's seal public key, which for a per-install key is the same on every output from that install. A SHA-256 of a withheld source lets anyone who already holds a candidate file confirm it was in the folder. Treat the manifest as listing everything in the source folder.

Matter profiles (Omitly 5.2, omitly#982) add the artefacts below. A matter profile is a named, saved set of search settings for one matter, reused across documents and folder runs. Design: docs/MATTER-PROFILES-DESIGN-982.md.

Profiles are read and written only by the Rust core. The webview reaches them through a fixed set of commands (list, get, save, delete, duplicate, effective, export, import) and never touches the folder. No profile command makes a network call (§1.3). Nothing in §1.3 sends a profile anywhere, and the support form sends only what the user types. (Unverified: a test that fails if a profile name or term reaches a support submission. The design note promises one; we did not find it in the code.)

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.

Legal Production Mode (folder redaction, v4.2)

Not yet in a release. What it writes is in §1.4; the design's invariants are B1–B8 of docs/BATCH-PRODUCTION-DESIGN-833.md, and the manifest's seal is SEAL-SPEC-v2 §20, approved by the owner on 2026-10-22.

Matter profiles (Omitly 5.2, omitly#982)

What a profile holds and where it lives is in §1.4. Design: docs/MATTER-PROFILES-DESIGN-982.md. A profile feeds the term list of a name-list redaction or a folder run; it does not change the engine or the seal. Its exclusions do change what the survivor check treats as a survivor (below).

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)

Boundary B5 — MCP proposal channel (bring your own AI, 2026-10)

A customer may connect their own MCP client (Claude Desktop, Cursor, Windsurf, a firm's agent) to the omitly-mcp server. While the desktop app runs with Accept proposals in Omitly on (default), a redaction the client requests is not executed: it is written as a proposal file that the app shows, and a person accepts or rejects it in the app. Acceptance runs the ordinary verified-removal core and the sealed record says human-desktop. The channel is files under the state directory, never a listener.

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. The certificate and .audit.html are renderings of the verified embedded report, titled "Omitly Release Check Certificate" for a v2 report (never "Proof-of-Destruction"; it records what was removed from this file and the checks that ran on the delivered bytes, and says nothing about originals or other copies). A legacy v1 certificate still prints "VERIFIED" for an old sealed v1 report; v1 verdicts are labelled "classical-era seal (v1)" on every surface (omitly#1588), but the v1 wording itself has not been changed.
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 PAdES signature is a different artefact from the Release Check Certificate, which is not a signature and carries no signer identity). (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 not scan it as an attachment. Since omitly#1595 Check no longer does that silently: every Check surface adds an Information finding that the file carries an Omitly report, naming the sealing key's fingerprint and the verdict the report records (fixed text and a closed verdict set only, never a string from the report). It does not change the verdict, because Check cannot tell whose key it is. The free text inside such a report's ordinary fields is not bounded or scanned (still 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: compare the named key with one the sender published.
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 compare a CID font's glyph names with its text (its .notdef rule is in, omitly#1620), nor cover 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) closed in v4.3 (omitly#1621): the stale-evidence rule now covers the print path, CLI publish (which the omitly-mcp tools call), certificate export and omitly-compare -o; encrypted export already went through the checked publish, and that is now pinned by a test; (c) the Check report-binding limit in item 10 (omitly#1595) is open.
12. Legal Production Mode (v4.2, not yet released): stated limits and open gaps. (a) The manifest's seal format (SEAL-SPEC-v2 §20) was approved by the owner on 2026-10-22. (b) Both resume gaps found by this pass are closed: omitly#1648 (a changed term count or options cannot resume, and each carried output is re-analysed for the current terms — page text, annotations, form fields, document properties, bookmarks, attachments, image-beside-text pages) and omitly#1649 (resume only from this install's own sealed manifest and outputs). Resume is deliberately stricter than Verify; a one-time-key manifest never resumes. (c) Not searched in a batch: images under 10 % of a page, images inside tiling patterns, text inside any image, and text drawn only in an annotation's appearance stream. (d) A crash can leave a hidden .omitly-<hex>.tmp staging file in the output folder, and the pre-flight does not yet list it. (e) The production log is unsigned, and no screen writes it yet (omitly#984, omitly#985).
13. Release Check Certificate (v4.3 "Certificate honesty"): stated limits, not silent gaps (omitly#1560). (a) Integrity, not identity, not time. A certificate shows the result of the checks that ran on the delivered bytes and that the file is unchanged since sealing; it does not identify who sealed it, does not prove when, and (Safe to Send is a defined term, CLAIMS-POLICY §1a) does not mean the document holds no other sensitive information. Needs Review and Cannot Verify also get a certificate; only Safe to Send reads as affirmative. (b) The webview-side delivery gates are not native (re-OCR of scanned pages, survivor checks, label tally; Audit log table, "Elevation of privilege"). They are not in the session record. (c) pass_with_operator_decisions reads as Needs Review, never Safe to Send (omitly#1701, owner decision 2026-10-27). mcp-agent is still an allowed override actor, although the owner decided it should not be (tracked separately); no flow writes a decision yet. (d) A legacy v1 certificate still prints "VERIFIED" for old sealed v1 reports. (e) Free text in a sealed report is not yet bounded beyond what the verifier shows (omitly#1595 residual); the certificate prints no producer string for that reason. (f) The session record's times and the actor field are the producer's own statements.

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 3.0 (2026-10-28). Added matter profiles (Omitly 5.2, omitly#982; omitly#1562): where they are stored and what they contain, including that they hold client and matter names in plain, unencrypted files (§1.4), and a "Matter profiles" threat table covering disclosure, the keyed fingerprints in the sealed report, tampering with a profile, resume with a different profile, and the limits of what the report can show.

Changes in 2.9 (2026-10-26). v4.3 "Certificate honesty" (omitly#1560): the v2 certificate is titled "Omitly Release Check Certificate" and prints one fixed seal-family line, and the Audit log table, §1.3 B4 and §4.2 items 1, 6 and 13 say so (omitly#275); added the type-level issuance gate (omitly#272, invariant #14), the final-delivery ordering gate (omitly#272, invariant #15) and the trust boundary with its webview limit; added attributable operator decisions bounded to detector_residual_identifier findings (omitly#274, omitly#1698); the detection profile pinned by content hash (omitly#273); and the session record signed by construction inside the sealed report (omitly#271). Added the stale-evidence rule for print, CLI publish, omitly-compare -o and certificate export (omitly#1621), the encrypted-input refusal in sign_pdf (omitly#1635) and the redaction-the-detector-can-still-find rule (omitly#1690). B4 now states what the certificate says about time: nothing, with OpenTimestamps, C2PA and B-LTA planned and unattested. No earlier claim in this document is withdrawn: it never described the certificate as proof of destruction, and the new text states the integrity/identity/time scope the certificate already prints. The open limits are item 13.

Changes in 2.8 (2026-10-26). The .notdef drawn-glyph check now covers embedded Type0/CID fonts, and no longer flags glyphs drawn in text render mode 3, which paints nothing (mode 7, clip only, stays in scope: a later fill can show its outline) (omitly#1620): the false Safe to Send row and §4.2 item 11(a).

Changes in 2.7 (2026-10-26). Check now reports an omitly-audit.json bound to the file's own seal as Information, naming the sealing key and the report's recorded verdict, instead of skipping it silently (§4.2 item 10, omitly#1595). Verify, the certificate, the engine CLI and the npm/MCP output now label a v1 seal's verdict "classical-era seal (v1)" as SEAL-SPEC-v2 §11.1 requires (omitly#1588).

Changes in 2.6 (2026-10-22). The production manifest records a keyed term-list MAC (SEAL-SPEC-v2 §20.9, omitly#1661), and resume requires it to match, so a later run with a different term list of the same length no longer carries earlier outputs forward (§1.4).

Changes in 2.5 (2026-10-22). Added Boundary B5, the MCP proposal channel (bring your own AI, omitly#1642–#1646): its row in the network-surface table and its STRIDE table.

Changes in 2.4 (2026-10-22). The manifest's seal format, SEAL-SPEC-v2 §20, is now owner-approved (§1.4, the Legal Production Mode section and §4.2 item 12(a) said "proposed").

Changes in 2.3 (2026-10-21). Added Legal Production Mode, the v4.2 folder-redaction workflow, as built and before it is released (omitly#1561): its component (§1.2); that it adds no network path and never anchors (§1.3 and the network-surface table); every file it writes, and what a production discloses to its recipient (§1.4); a STRIDE section of its own, including two open gaps in resume; and its stated limits (§4.2 item 12).

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.