42 — Threat Model

A consolidated, attacker-perspective view of Locara’s security posture. Threat modeling that’s scattered across many docs is hard to review; this is the one artifact a security researcher reads first.

Format: STRIDE-aligned + attacker narratives. Each threat → mitigations → residual risk.

Assets being protected

What Locara needs to defend:

1. User data on the user’s device (transcripts, documents, prompts, models — everything in app containers).
2. The trust property of “fully local” (the registry’s claim that an app cannot phone home).
3. Locara’s signing identity (Apple Developer ID + CI signing keys + Sigstore identity).
4. The registry’s integrity (manifest data, app artifacts, revocation list).
5. The framework’s source code integrity (the canonical Locara repos).
6. Publisher accounts (their identity, ability to update their apps).
7. The Locara website (locara.app — discovery + downloads).

Trust boundaries

[User] ←→ [User's Mac (apps + macOS)] ←→ [Locara registry + CDN]
                  ↑                              ↑
                  │                              │
            [Apple Gatekeeper]            [Sigstore log]
                  ↑                              ↑
                  │                              │
            [Apple notarization]          [CI infrastructure]
                                                  ↑
                                                  │
                                            [Source repo]
                                                  ↑
                                                  │
                                          [Trust group]
                                                  ↑
                                                  │
                                          [Project lead]

Each ↑ is a trust boundary where compromise has different blast radius.

Threats by category (STRIDE)

S — Spoofing

Threat	Mitigation	Residual risk
Attacker registers similar publisher name (typosquat)	Verified publisher accounts via GitHub OAuth + DNS verification; clear publisher display in app cards	Low — typosquats stand out next to verified publishers
Attacker impersonates a publisher to push a malicious update	Mandatory 2FA on publisher accounts + hardware-key signing for high-value publishers	Low — account-takeover requires beating 2FA + hardware key
Attacker creates fake Locara website at typosquat domain	Cert pinning in installed apps; clear branding; defensive domain registrations	Low-medium — typosquat phishing is always a risk
Attacker signs a fake “Locara” cert and ships malware	Apple Gatekeeper checks cert against Locara’s actual Apple Developer ID; mismatch denies install	Very low — Apple’s signing infrastructure is the floor
Compromised dev machine produces a malicious build	Apps are built by Locara CI from source by commit hash, not uploaded by developers	Eliminated for app artifacts; remains a risk for source code if the dev’s repo is compromised

T — Tampering

Threat	Mitigation	Residual risk
Modified .app bundle in transit	TLS for all downloads; SHA-256 manifest verification; Sigstore provenance attestation	Very low
Modified manifest after submission	Manifests are signed at submission; CI rebuilds from the original source commit	Very low
Tampered model files	Content-addressed cache: every model verified by SHA-256 hash declared in app manifest	Very low
Compromised Sigstore log	Sigstore is operated by Linux Foundation; multiple replicas; transparency log is append-only	Low — would require compromising LF infrastructure
Attacker modifies an installed app on disk	macOS code-signing + Gatekeeper detect tampering on launch	Very low
Attacker modifies app’s SQLite database directly	macOS App Sandbox prevents other apps from accessing the container	Low — requires an attacker with shell access already

R — Repudiation

Threat	Mitigation	Residual risk
Publisher denies authoring a malicious app	All submissions tied to authenticated publisher accounts + signed publisher tokens; commit history in source repo	Low
Locara denies signing a malicious build	Sigstore attestations are public + transparency-logged; all signed builds are publicly verifiable	Very low
Maintainer claims they didn’t make a contentious decision	All decisions go through PRs / RFCs / ADRs in public repo	Low

I — Information Disclosure

Threat	Mitigation	Residual risk
Malicious app exfiltrates user data	App Sandbox + capability declarations: net: false apps cannot reach network; fs.user-selected apps see only files user picked	Very low — kernel + runtime + static analysis enforce
Malicious app reads other apps’ data	Per-app sandboxed containers; cross-app IPC requires explicit reciprocal declaration	Very low
User exports data to a malicious app via shared folder	Both apps must mutually declare the shared folder; user sees this at install	Low — user-visible attack surface
Compromised CI leaks build artifacts before review	Artifacts go through review queue before public availability	Low; if a malicious artifact slips through, kill-switch + revocation
Locara registry leaks publisher data	Minimal data collected (see 26-compliance.md); standard at-rest encryption	Low
Side-channel attacks on inference (timing, cache)	Out of scope for v1; theoretical risk; no known practical exploits in this domain	Acknowledged
Browsing patterns at locara.app reveal user interests	No analytics; only Cloudflare access logs (IPs, retained 30 days)	Low

D — Denial of Service

Threat	Mitigation	Residual risk
Registry / CDN outage blocks new installs	Existing installed apps continue running offline; aggressive caching + CDN	Medium — outages happen; users without network can’t install new apps
Apple Developer Program access revoked	All-new-publishes blocked; existing installs continue running. Backup procedures + Apple appeals	Medium — single point of failure
Sigstore unavailable	Existing installed apps continue (already-verified attestations cached); new installs may fail provenance check	Medium
Malicious app exhausts user resources (memory, disk, CPU)	Per-app resource limits enforced by macOS + Locara runtime; user can force-quit	Low
App crash via malformed input	Property-based tests + fuzz tests on capability enforcer; runtime crash is isolated to one app	Low
Domain hijacking	Registrar 2FA + hardware key + DNS pinning; domain lock	Low

E — Elevation of Privilege

Threat	Mitigation	Residual risk
App escapes sandbox via Tauri IPC quirks	Capability checks at every IPC boundary; macOS App Sandbox is the kernel-level floor	Very low
App escapes sandbox via Wasmtime tool	Wasmtime is mature + audited; tools declare exact WASI imports; sandbox is capability-based	Very low
App uses dynamic code loading to evade static analysis	Static analyzer flags eval, Function(string), dynamic remote imports as hard errors; runtime denies	Very low
App declares minimal capabilities, uses native macOS APIs to escape	Locara apps run in macOS App Sandbox container — no access to APIs requiring entitlements not declared in the bundle	Low — kernel enforces
App inherits unintended permissions from parent process	Locara apps are launched fresh from Launch Services; no privileged parent	Very low

Attacker narratives

Higher-leverage view: walk through what an attacker actually wants and how they’d attempt it.

Narrative 1: “I want to exfiltrate sensitive data from a Locara user”

Attacker writes an app that looks legitimate (e.g., “Daily Journal — privacy-first journaling”) and tries to ship malware that exfiltrates the user’s journal entries.

Path 1: declare net: true. Loses “fully local” badge; users see “uses network” prominently; far fewer installs. Self-defeating.

Path 2: declare net: false, hide network call. Static analyzer catches fetch / XMLHttpRequest / WebSocket / dynamic imports → hard error at submission. Even if it slipped past static analysis, macOS App Sandbox kernel-blocks the call. Even if it slipped past the kernel (vanishing chance), no destination would receive the data.

Path 3: dump data to user-selected file, hope user uploads it. Requires the user to actively upload. Out of scope for our threat model.

Path 4: write to a shared folder partner, hope the partner has net: true. Both apps must declare the shared folder mutually; the user sees this at install. Combined-capability surface visible up front.

Net: the architecture makes this attack genuinely hard. Locara’s value prop is that Path 2 specifically is structurally impossible.

Narrative 2: “I want to push a malicious update to an existing popular Locara app”

Attacker compromises Publisher X’s GitHub OAuth + 2FA + signing key. They push a malicious update.

Path 1: change capabilities to add net: true. Triggers 7-day cool-down + user re-consent before activation. Legitimate publisher (or community) has 7 days to notice + raise alarm + revoke.

Path 2: keep capabilities the same, add malicious code. Static analyzer checks that the source matches the declared capabilities. If the update only does what the manifest allows, the harm surface is limited to that capability surface.

Path 3: account-takeover + push update during a quiet period. Mandatory 2FA + hardware key for high-impact publishers; sustained breach detection (anomalous publish patterns).

Net: account-takeover is the most realistic vector. The cool-down + community-watching mitigates blast radius.

Narrative 3: “I want to compromise Locara’s signing infrastructure”

Attacker targets Locara CI’s Apple Developer ID + CI signing key. If they get either, they can sign arbitrary apps as Locara.

Mitigation per 40-operational-security.md:

• Hardware-security-key-protected.
• CI Secret with restricted access.
• Annual rotation + immediate rotation on incident.
• Multi-person trust group reviews any cert-touching change.
• Sigstore log makes any unauthorized signing detectable post-hoc.

If compromised: the Crisis Runbook Scenario B walks through revocation + key rotation + notification.

Narrative 4: “I’m a regulator / nation-state asking Locara to install backdoors”

Locara has no centralized data store of user activity. There’s nothing to compel.

The question becomes: can Locara be compelled to ship a backdoored framework version that captures user data?

Mitigations:

• Open-source code: any backdoor would be visible in commits.
• Reproducible builds: third parties can verify the binary matches the source.
• Sigstore provenance log: tampering with build artifacts is detectable.
• Community + maintainer ladder: a single compelled maintainer can’t push code without review.
• Public commit access via ADR 0003 — restricted but the change history is public.
• Forks: if Locara is compromised, the community can fork the last-clean version.

Residual risk: secret legal compulsion (gag-ordered) is theoretically possible but visible: the project’s commits + signing patterns would need to deviate noticeably. A warrant canary (open question) would help.

Narrative 5: “I want to fingerprint Locara users for tracking”

Trying to identify which user installed a particular app, or what set of apps a particular user has installed.

Mitigations:

• The Locara website doesn’t require login to download.
• Update checks are framework-level, not per-user-tracked.
• Aggregate install counts come from anonymized version-check pings; no user identifier.
• IP addresses logged at the CDN are retained 30 days max + minimized.
• No third-party trackers, scripts, or pixels.

Residual risk: Cloudflare logs IPs; sufficiently sophisticated correlation across IPs + timing could fingerprint heavy users. Mitigations are partial; full anonymity requires Tor-class infrastructure which is out of scope.

What’s explicitly out of scope

• User installs malware they were warned about. A user who clicks past consent for an app declaring net: true, fs.read: ['/'] and runs it is responsible for that decision. We can warn loudly; we can’t prevent informed self-harm.
• Hardware compromise. Firmware-level malware, evil maid attacks, supply-chain attacks on the user’s hardware are out of scope. macOS + Apple Silicon’s hardware security is the floor we sit on.
• Cryptographic side channels. Timing attacks on inference, cache attacks. Theoretical; no known practical exploits relevant to local-AI workloads.
• Compromised macOS itself. If macOS is compromised, no application-layer security helps. Apple’s responsibility.

Defenses by layer (cheat sheet)

┌────────────────────────────────────────────────────────────────┐
│  Layer                      │ What it defends against          │
├────────────────────────────────────────────────────────────────┤
│  Macos App Sandbox (kernel) │ Capability escapes at OS level   │
│  Tauri IPC capability check │ Frontend → backend boundary      │
│  Locara runtime check       │ App-internal capability claims   │
│  Wasmtime tool sandbox      │ Tool execution containment       │
│  Static analyzer            │ Source-level capability mismatches│
│  Sigstore provenance        │ Build-pipeline tampering         │
│  Apple notarization         │ Apple-known malware patterns      │
│  Apple code signing         │ Identity verification at install │
│  Capability cool-down       │ Account-takeover update attacks  │
│  Kill-switch                │ Post-hoc malicious-app removal   │
│  Operational security       │ Trust group credential security  │
│  Restricted commit access   │ Source-code-level integrity      │
│  No telemetry               │ Information leakage at framework │
└────────────────────────────────────────────────────────────────┘

Each layer is independent. An attacker compromising one is contained by the next. Defense in depth.

Threat-model review cadence

This document is reviewed and updated:

• Annually as a baseline.
• After any security incident (with new threats added to the model).
• Whenever a major architectural change ships (new layer, new capability category, etc.).
• During phase transitions.

A red-team / penetration test is conducted at least once per year (phase 4+ when budget allows; phase 1-3 done by project lead + maintainers).

Cross-references

• 13-security-privacy.md — user-facing security posture
• 14-trust-safety.md — registry-side trust mechanics
• 27-crisis-runbook.md — incident response procedures
• 31-capability-analyzer.md — static analysis defense
• 40-operational-security.md — credential custody
• 41-telemetry-zero.md — no-telemetry guarantee