chore(scaffold): initial SilverMetal program scaffold

Cross-platform privacy-hardening program. Two-layer product: - SilverLABS Application Stack (cross-platform spine) - Platform Hardening Profiles (per-OS, tier-honest) Platforms: Linux (Debian/Kicksecure), Android (Pixel/Samsung/Moto/generic), Windows (LTSC IoT), macOS (profile), iOS (MDM profile). Each flavour has both a preflashed hardware SKU path and a self-apply "harden your existing device" path. Includes umbrella docs (README + threat-model, design-principles, platform-matrix, roadmap, trust-model), per-platform and per-stack- component README stubs, .gitignore, LICENSE. Linux v1 ships first; Stack v1 = Browser + VPN + Sync. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-25 03:11:48 +01:00
commit 7d5f9cc246
23 changed files with 1381 additions and 0 deletions
--- a/docs/design-principles.md
+++ b/docs/design-principles.md
@@ -0,0 +1,98 @@
+# Design Principles
+
+The non-negotiables behind every SilverMetal decision. When something is unclear, return to this list.
+
+## 1. Privacy by default, not as an option
+
+Every SilverMetal device ships with maximum privacy settings *out of the box*. The user does not have to know what to turn off. The advanced toggles allow loosening for specific needs; the defaults are tight.
+
+## 2. Honesty over marketing
+
+We never claim a hardening tier we cannot deliver. The Windows profile is labelled "config-layer hardening." The iOS profile is labelled "profile-layer only — weakest tier in the family." Where competitors claim "uncrackable," we describe the actual threat model and limitations.
+
+If we cannot defend against a class of adversary, we say so. See [`threat-model.md`](threat-model.md).
+
+## 3. Two buyer modes, every platform
+
+Every platform must serve both:
+- The buyer choosing a new device — we sell a preflashed SilverMetal SKU
+- The buyer hardening an existing device — we ship a free self-apply track (installer / ROM / profile + Stack)
+
+No platform is premium-only. No platform is DIY-only.
+
+## 4. Verifiable, not just open
+
+Open source is necessary but not sufficient. Every SilverMetal release ships with:
+- **Reproducible builds** — two clean builds of the same commit produce identical artefacts
+- **Signed releases** — our key, key ceremony documented, key offline
+- **SBOM published** — every dependency, every version
+- **Build attestation** — signed proof the published artefact came from the published source
+
+A user who doesn't trust us can verify what we ship.
+
+## 5. Minimum data architecture
+
+SilverLABS itself collects the minimum data required to operate. Specifically:
+
+- **Account numbers, not emails** — Mullvad-style anonymous identifiers
+- **No analytics, no telemetry** — including in our own apps
+- **No log retention** beyond what's operationally required (typically <24h, never longer than necessary for abuse mitigation)
+- **Client-side encryption** for SilverSync content — server cannot read user data
+- **Payment isolation** — payments processed via SilverDotPay (cryptocurrency option) or stripe-like processor with no link back to account number
+
+When a subpoena lands on us, the answer to most questions is "we don't have it."
+
+## 6. Self-hostable where it matters
+
+The SilverLABS Stack server components (SilverSync, SilverChat homeserver, SilverVPN nodes) are open-source and self-hostable. A user who doesn't trust SilverLABS infrastructure can run their own. The hosted offering is the convenient default, not the only option.
+
+## 7. The Stack is the spine, not the OS
+
+Most privacy value lives in *what apps you use*, not *what kernel you run*. The SilverLABS Application Stack (Browser, VPN, Sync, Chat, Duress, Keys) ships across every platform. OS-level hardening is the delivery vehicle; the Stack is the durable product.
+
+## 8. No telemetry, ever, in our own code
+
+SilverLABS does not add analytics, crash reporters that phone home, or "anonymous usage statistics" to anything we ship. Bug reports are user-initiated and explicit. This is non-negotiable for our brand.
+
+## 9. Sane interoperability
+
+We don't reinvent protocols where good ones exist:
+- WireGuard for VPN, not a proprietary tunnel
+- Matrix or Signal Protocol for messaging, not a proprietary protocol
+- CardDAV / CalDAV / WebDAV for sync, not a proprietary API
+- Standard formats (OpenPGP, age) for encryption
+
+A user who outgrows SilverLABS can take their data and protocols with them.
+
+## 10. Conservative cryptography
+
+- Argon2id for password hashing (KDF parameters tuned per-platform)
+- AES-256-GCM or ChaCha20-Poly1305 for symmetric
+- X25519 / Ed25519 for asymmetric
+- TLS 1.3 minimum for transport
+- Post-quantum readiness tracked but not yet defaulted (revisit when standards mature)
+
+We don't roll our own.
+
+## 11. Distrust the network
+
+Every SilverLABS app assumes the network is hostile:
+- Encrypted DNS (DoT/DoH) by default
+- Certificate pinning where deployable
+- No plaintext fallbacks
+- Kill-switch behaviour: if VPN drops, traffic stops, never leaks
+
+## 12. Distrust the platform
+
+Our Stack apps treat the host OS as semi-trusted, even when we ship the OS:
+- Client-side encryption before disk write
+- Memory hygiene (zero secrets after use, hardened_malloc where available)
+- No reliance on platform keychains for our most sensitive secrets
+
+## 13. Update or die
+
+Unpatched software is the single largest privacy/security risk in practice. Every SilverMetal flavour must have working, signed, automatic updates with rollback. A SilverMetal device that cannot update is a SilverMetal device that has reached end-of-life.
+
+## 14. Boring is good
+
+We use proven components (Debian, GrapheneOS, WireGuard, Nextcloud, Matrix, Bitwarden) and add value at the integration and configuration layer. We are not a research project; we are a product. Novel cryptography, novel protocols, novel kernels are out of scope.
--- a/docs/platform-matrix.md
+++ b/docs/platform-matrix.md
@@ -0,0 +1,208 @@
+# Platform Matrix
+
+The honest per-platform capability and pros/cons table. This is what a buyer sees on each product page so they can choose based on their actual constraint.
+
+## Hardening tiers
+
+| Tier | What it means |
+|---|---|
+| **A — Fully controllable** | We own the kernel, boot chain, MAC framework, and update infrastructure |
+| **B — Firmware-controllable** | We replace the OS stack but not every firmware blob |
+| **C — Config-controllable** | Proprietary kernel; we harden at config + app layer |
+| **D — Policy-controllable** | Closed platform; we ship profiles + curated apps + setup only |
+
+## Capability summary
+
+| Platform | Tier | Deliverable | Stack support |
+|---|---|---|---|
+| SilverMetal Linux | A | Custom Debian/Kicksecure-based ISO | Full, native |
+| SilverMetal Droid (Pixel) | B | GrapheneOS-fork ROM | Full, native |
+| SilverMetal Droid (Samsung) | C | LineageOS-fork ROM where bootloader unlocks; profile + Stack elsewhere | Full where ROM, Stack-only otherwise |
+| SilverMetal Droid (Motorola) | C | DivestOS/LineageOS-fork ROM on supported models | Full where supported |
+| SilverMetal Droid (generic) | D | "Harden any Android" — Stack + work-profile config | Stack + config only |
+| SilverMetal Windows | C | LTSC IoT installer + hardening + Stack | Full (Stack apps run native) |
+| SilverMetal macOS | C-D | Signed config profile + setup script + Stack | Full (Stack apps run native) |
+| SilverMetal iOS | D | MDM profile + Stack from App Store | Full (Stack apps via App Store) |
+
+## Per-platform pros / cons
+
+### SilverMetal Linux (Tier A)
+**Reference setup. The strongest possible SilverMetal device.**
+
+**Pros**
+- Full kernel-level hardening (KSPP, linux-hardened, hardened_malloc)
+- Verified boot we control end-to-end (Secure Boot with our shim/MOK, TPM2 PCR-bound LUKS2)
+- AppArmor strict profiles for every networked surface
+- Reproducible builds; we publish SBOMs and build attestations
+- Zero upstream telemetry — every Microsoft/Google/Mozilla/Canonical phone-home removed
+- Full SilverLABS Stack runs natively
+- Update channel and signing keys are ours
+
+**Cons**
+- Learning curve for users coming from Windows/Mac
+- Some commercial software does not run natively (Adobe CC, MS Office native — though web/Office365 work, native MS Office does not)
+- Some games, particularly anti-cheat-protected titles, will not run
+- Hardware compatibility needs checking before purchase (Coreboot SKUs are best-supported)
+
+**Best for**: users whose work is browser + email + office docs + dev + comms; anyone who would otherwise install Linux themselves; the maximum-privacy buyer.
+
+---
+
+### SilverMetal Droid — Pixel flagship (Tier B)
+**The secure-phone flagship. GrapheneOS-tier engineering.**
+
+**Pros**
+- Verified boot we control via Pixel's relockable bootloader
+- Hardened Android kernel (GrapheneOS patches)
+- App-level sandbox enforced; sandboxed Google Play *optional*, not required
+- Per-app network/sensor/storage permissions
+- Duress wipe (v1.1)
+- Daily-driveable as a phone
+
+**Cons**
+- Pixel hardware only (4a 5G and newer — others EOL)
+- Some banking apps and corporate apps refuse to run on non-Play-Integrity devices (workaround: sandboxed Play, but breaks the airtight model)
+- Not all carriers support all Pixel models cleanly
+
+**Best for**: the "secure phone" buyer, journalists, activists, anyone who would otherwise buy an Encrochat-style rebadged phone but wants real engineering.
+
+---
+
+### SilverMetal Droid — Samsung (Tier C)
+**For users on Samsung hardware. Variable depending on model and region.**
+
+**Pros**
+- Wide hardware availability and price range
+- LineageOS / DivestOS fork for unlocked-bootloader regions gives most of the benefit
+- Knox security layer is genuinely capable on locked models
+- Full SilverLABS Stack supported either way
+
+**Cons**
+- Many Samsung models — especially US-carrier models — have permanently locked bootloaders; we cannot replace the OS
+- Even on unlocked bootloader, we lose verified boot rooting back to our key
+- Knox tripped flag is permanent; some Samsung features (Samsung Pay, Knox-protected work apps) may stop working
+
+**Best for**: existing Samsung owners; buyers wanting a non-Pixel Android with strong-enough hardening.
+
+---
+
+### SilverMetal Droid — Motorola (Tier C)
+**For users on Motorola hardware. Best Android option after Pixel for unlocked-bootloader hardening.**
+
+**Pros**
+- Many Moto models support bootloader unlock cleanly
+- DivestOS / LineageOS support is good for popular models
+- More affordable than Pixel
+- Full SilverLABS Stack supported
+
+**Cons**
+- Verified boot weaker than Pixel — no relockable bootloader on most models
+- Hardware longevity / update support varies by model
+- Driver / firmware blob situation messier than Pixel
+
+**Best for**: budget-conscious buyer wanting custom-ROM-tier hardening without Pixel pricing.
+
+---
+
+### SilverMetal Droid — Generic / "harden my existing Android" (Tier D)
+**For users who already own an Android and won't / can't replace the ROM.**
+
+**Pros**
+- Works on virtually any Android 13+ device
+- Full SilverLABS Stack runs (Browser, VPN, Sync, etc.)
+- Work-profile-based isolation contains tracking apps in a managed sandbox
+- No bootloader unlock required; no warranty void
+
+**Cons**
+- We do not control the OS — Google + your OEM still do
+- Verified boot is your OEM's, not ours
+- Telemetry from OS-level Google services cannot be fully blocked without a ROM swap
+- Honest tier label: D, weakest Android tier
+
+**Best for**: existing Android owners who want privacy improvements without buying new hardware or unlocking their bootloader.
+
+---
+
+### SilverMetal Windows (Tier C)
+**For users locked into Windows-only software.**
+
+**Pros**
+- Keeps full compatibility with Windows-native software, including Adobe CC, MS Office native, Windows-only line-of-business apps, anti-cheat-protected games
+- Removes ~90% of Microsoft telemetry (Group Policy + hosts + service disabling, verified)
+- Enforces BitLocker (TPM-bound), Defender ASR rules at maximum, AppLocker allow-listing
+- LTSC IoT base = no Cortana, no Store, no Edge baked in, supportable for ~10 years
+- Full SilverLABS Stack runs native
+- Edge / Chrome replaced with SilverBrowser
+
+**Cons**
+- We do not control the kernel, the boot chain, or Windows Update
+- Microsoft can change things in updates we cannot prevent
+- Some telemetry channels Microsoft does not expose for disabling
+- Honest tier label: C, config-layer only — *we say this in marketing*
+- Requires LTSC IoT licensing for the strongest variant; standard Win 11 Pro is supported but weaker
+
+**Best for**: business users and creatives who can't leave Windows but want every privacy dial turned to maximum.
+
+---
+
+### SilverMetal macOS (Tier C-D)
+**For Mac-committed users.**
+
+**Pros**
+- Apple hardware quality is excellent; Secure Enclave + FileVault are genuinely strong when configured
+- Lockdown Mode dramatically reduces remote-attack surface
+- Apple's app sandboxing is robust at the kernel layer
+- Full SilverLABS Stack runs native (universal binaries)
+- Safari replaced with SilverBrowser by default
+- Telemetry / Siri / analytics all disabled by our profile
+
+**Cons**
+- We cannot modify macOS itself
+- Apple still receives device-linked metadata we cannot fully stop (App Store auth, OS update checks, Apple ID)
+- iCloud is required for some OS features; we scope it to absolute minimum
+- Honest positioning: "hardened Mac," not "anonymous Mac"
+
+**Best for**: Mac-committed users (creative professionals, developers on Apple Silicon) who want maximum-feasible hardening on hardware they're keeping.
+
+---
+
+### SilverMetal iOS (Tier D)
+**For iPhone users.**
+
+**Pros**
+- iOS sandbox + Secure Enclave + Lockdown Mode are genuinely strong against remote attack, in some respects stronger than any other consumer platform
+- Full SilverLABS Stack available via App Store (Browser, VPN, Sync, Keys, Chat once approved)
+- Hardware-key 2FA (YubiKey/Lightning) supported and recommended in our setup guide
+- "Disposable Apple ID" guidance reduces account-graph exposure
+
+**Cons**
+- The most restrictive platform — Apple ID is unavoidable for App Store
+- Cannot replace many default services (Mail.app, FaceTime, iMessage) — only complement them
+- App-level replacements only via App Store (no sideloading in most regions yet)
+- Configuration profile + MDM applies; cannot modify iOS itself
+- Honest tier label: D, weakest tier in the family — *we say this in marketing*
+
+**Best for**: users whose threat model is commercial surveillance (not state-actor targeting) and who need to stay on iPhone for personal/work reasons.
+
+## Decision flowchart
+
+```
+Does the user need maximum privacy and is software-flexible?
+  → SilverMetal Linux
+
+Does the user need a phone, primarily?
+  → Pixel? → SilverMetal Droid Flagship
+  → Samsung/Motorola with unlocked bootloader? → matching ROM tier
+  → iPhone or locked Android? → corresponding profile tier
+
+Does the user need Windows-only software?
+  → SilverMetal Windows
+
+Is the user Mac-committed?
+  → SilverMetal macOS
+
+Does the user already own a device they're keeping?
+  → The corresponding "profile" or "harden existing" tier
+```
+
+We do not push users between tiers. We tell them what each can deliver and let them choose.
--- a/docs/roadmap.md
+++ b/docs/roadmap.md
@@ -0,0 +1,124 @@
+# Roadmap
+
+Milestone-driven, no calendar dates (those slip; milestone gates don't). Each milestone has a definition of done. We don't move on until the previous milestone is met.
+
+## Phase 0 — Foundation (current)
+
+**Goal**: get the architecture, threat model, and product principles documented and reviewed before writing OS code.
+
+| # | Milestone | Done when |
+|---|---|---|
+| 0.1 | Repo scaffold | Directory tree + per-platform stubs + per-stack stubs in place |
+| 0.2 | Umbrella docs | `README.md` + `docs/{threat-model,design-principles,platform-matrix,roadmap,trust-model}.md` complete and reviewed |
+| 0.3 | Gitea repo created and pushed | `SilverLABS/SilverMetal` exists on `git.silverlabs.uk` with this scaffold |
+
+**Status**: in progress (this commit completes 0.1–0.3).
+
+---
+
+## Phase 1 — SilverMetal Linux v1 (the MVP)
+
+**Goal**: ship a public alpha ISO that passes our own hardening verification. This is the reference implementation; the patterns established here flow to other platforms.
+
+| # | Milestone | Done when |
+|---|---|---|
+| 1.1 | Kicksecure fork builds reproducibly | `live-build` produces identical SHA256 across two clean builds |
+| 1.2 | Hardening overlay applied | KSPP audit passes; Lynis ≥ 90 in CI; AppArmor strict profiles loaded |
+| 1.3 | hardened_malloc integrated as system allocator | Verified active for user sessions; no regressions |
+| 1.4 | Telemetry-leak test green | tcpdump on fresh-install idle for 30 min — zero packets to MS/Google/Apple/Mozilla/Canonical/Debian/analytics endpoints |
+| 1.5 | LUKS2 + TPM2 PCR-bound install via Calamares | End-to-end: install → reboot → TPM unlock → desktop. Tamper test correctly falls back to passphrase |
+| 1.6 | SilverBrowser v1 integrated (ungoogled-chromium rebrand) | Default browser, no Google services, fingerprint defences validated |
+| 1.7 | SilverVPN v1 integrated (WireGuard backbone) | Always-on default; kill-switch verified; account-number signup flow works |
+| 1.8 | SilverSync v1 integrated (Nextcloud backbone, client-side encryption) | Contacts/calendar/files sync end-to-end; server cannot read content |
+| 1.9 | Update server + signing ceremony complete | First signed update delivered through alpha channel; rollback verified |
+| 1.10 | Public alpha ISO + SBOM + build attestation published | Download page live; reproducible-build instructions documented |
+| 1.11 | External privacy-engineering review | One independent reviewer (Kicksecure / Whonix community) signs off on threat-model fidelity |
+| 1.12 | Hardware SKU pilot batch | 10 preflashed Coreboot-supported laptops shipped and validated |
+
+**Exit criteria for Phase 1**: alpha is publicly downloadable, all verification gates green, hardware SKU available for purchase.
+
+---
+
+## Phase 1.1 — Stack expansion
+
+**Goal**: complete the SilverLABS Application Stack so v1.1 ships with the full suite.
+
+| # | Milestone | Done when |
+|---|---|---|
+| 1.1.1 | SilverChat v1 (Matrix-based) | Homeserver running; iOS/Android/Linux/Windows/Mac clients functional; account-number onboarding |
+| 1.1.2 | SilverDuress v1 | Linux PAM module + Android duress PIN + iOS Shortcuts/MDM trigger + Windows Group Policy + macOS profile — all verified |
+| 1.1.3 | SilverKeys v1 | Bitwarden-derived client + SilverSync backend; per-platform clients |
+| 1.1.4 | Atomic root experiment | ostree-based variant builds; v1.2 candidate if successful |
+
+---
+
+## Phase 2 — SilverMetal Droid
+
+**Goal**: ship Android coverage across all four tiers (Pixel flagship, Samsung, Motorola, generic profile).
+
+| # | Milestone | Done when |
+|---|---|---|
+| 2.1 | Pixel flagship ROM (GrapheneOS-fork) | Builds, signs, OTA-updates from our infrastructure; Stack preinstalled; verified boot rooted in our key |
+| 2.2 | Samsung tier (LineageOS-fork on unlocked-bootloader models) | Supported model list published; ROM + Stack overlay |
+| 2.3 | Motorola tier (DivestOS/LineageOS) | Supported model list published; ROM + Stack overlay |
+| 2.4 | Generic Android profile | "Harden my Android" installer: Stack apps + work-profile hardening config; works on Android 13+ |
+| 2.5 | Android hardware SKU pilot | Pixel preflashed batch (10 units) + Moto preflashed batch (10 units) |
+
+---
+
+## Phase 3 — SilverMetal Windows
+
+**Goal**: ship the Windows hardening installer for users locked into Windows.
+
+| # | Milestone | Done when |
+|---|---|---|
+| 3.1 | LTSC IoT base evaluated and licensed for our use | License path documented; base image acquired |
+| 3.2 | Hardening installer (PowerShell/EXE) | Applies Group Policy, AppLocker, Defender ASR, removes Edge/Cortana/Store, blocks telemetry hosts |
+| 3.3 | Stack ports for Windows | SilverBrowser/VPN/Sync/etc. native Windows builds, signed with our cert |
+| 3.4 | BitLocker + TPM enforcement automated | Installer ensures BitLocker enabled with TPM-bound recovery |
+| 3.5 | Windows hardware SKU pilot | Preflashed Coreboot-laptop variant with Windows + SilverMetal hardening (10 units) |
+| 3.6 | Telemetry-leak test for Windows | 30-min idle on hardened install — minimal Microsoft contact, documented (we cannot reach zero on Windows; we publish what remains) |
+
+---
+
+## Phase 4 — Apple platforms (macOS + iOS profiles)
+
+**Goal**: ship signed configuration profiles, setup scripts, curated app guidance, and Stack ports for Apple platforms.
+
+| # | Milestone | Done when |
+|---|---|---|
+| 4.1 | macOS configuration profile | Signed `.mobileconfig` enforces FileVault, disables analytics/Siri, configures firewall |
+| 4.2 | macOS setup script | Idempotent script applies non-MDM hardening (default app changes, etc.) |
+| 4.3 | Stack ports for macOS | Universal binaries, notarised, signed with our Apple Developer cert |
+| 4.4 | iOS MDM profile | Signed `.mobileconfig` for users with personal MDM (or via free Apple Configurator) |
+| 4.5 | Stack ports for iOS | App Store releases (Browser may face Apple review constraints — fall back to webkit-based with our defaults) |
+| 4.6 | Apple setup guide | Step-by-step published guide complementing the profiles |
+
+---
+
+## Phase 5 — Hardening / immutability / Tor sibling
+
+**Goal**: post-MVP improvements; not blocking earlier phases.
+
+- Atomic / immutable Linux variant (ostree)
+- dm-verity-protected `/`
+- Tor-by-default sibling product (SilverMetal Onion or similar)
+- ARM64 / Apple Silicon Linux variant
+- Coreboot tooling improvements / additional reference hardware
+
+---
+
+## Cross-cutting workstreams (always-on)
+
+These run in parallel with phases:
+
+- **Security advisories** — vulnerability response process from Phase 1.10 onward; signed advisories
+- **External audits** — annual or per-major-release third-party security review
+- **Documentation** — every phase's gate includes documentation update
+- **Community / support** — issue tracker, support channels, response SLOs
+
+## Phase entry/exit philosophy
+
+- We do not start a phase until the previous one's exit criteria are met
+- We *can* run cross-cutting workstreams in parallel
+- A failing verification gate blocks the phase, full stop — no shipping with known regressions
--- a/docs/threat-model.md
+++ b/docs/threat-model.md
@@ -0,0 +1,67 @@
+# Threat Model
+
+This document defines what SilverMetal defends against, what it does not, and how those choices flow through the rest of our design. We state this honestly so users can judge whether SilverMetal fits their situation.
+
+## Who we defend
+
+The primary user we design for is someone whose threat surface includes **one or more** of:
+
+- **Pervasive commercial surveillance** — telemetry, advertising graphs, data brokers, behavioural tracking
+- **Targeted commercial spyware** — stalkerware, off-the-shelf monitoring tools, opportunistic malware
+- **Capable adversaries with lawful access** — search warrants, border seizures, civil discovery
+- **Capable adversaries without lawful access (within reason)** — sophisticated criminal operations, opportunistic state-actor campaigns, supply-chain compromise
+- **Coercion / duress** — physical compromise of the user (border crossing, mugging, kidnap)
+
+We **do not** claim to defend against:
+
+- A **dedicated, well-resourced state actor** specifically targeting one user (this is essentially undefendable on commodity hardware; if that's your threat model, talk to a specialist directly)
+- **Endpoint compromise the user invites** — installing arbitrary software, sharing passwords, social engineering
+- **Hardware implants installed before the user takes possession** — we mitigate via reproducible builds and hardware verification but cannot eliminate
+
+## Adversary capabilities we assume
+
+| Capability | Assumed? | Mitigation |
+|---|---|---|
+| Network observation (ISP, transit, Wi-Fi sniffing) | Yes | TLS everywhere; SilverVPN default-on; encrypted DNS |
+| Subpoena to an upstream service (Google, Apple, ISP) | Yes | We don't depend on those services for sync, comms, or identity |
+| Subpoena to SilverLABS itself | Yes | Minimum-data architecture: account numbers not emails; client-side encryption; no log retention beyond what's operationally required |
+| Physical seizure of device, powered off | Yes | LUKS2 + Argon2id, TPM2-bound, BitLocker enforced, FileVault enforced |
+| Physical seizure of device, powered on / unlocked | Partial | Lockdown Mode (Apple), screen lock policies, SilverDuress (v1.1) |
+| Coerced unlock at border / by adversary | Partial | SilverDuress (v1.1) provides duress password / panic-wipe; iOS limited to OS primitives |
+| Sophisticated remote exploitation (NSO-class) | No (honest) | Lockdown Mode where available, hardened kernels where we control them, but commodity-platform exploit chains exist for every OS |
+| Supply-chain compromise of upstream packages | Partial | Reproducible builds, signed packages, SBOM published; cannot fully eliminate |
+| Hardware implant / interdiction | Partial | Coreboot on supported laptops, sealed packaging, TPM measured boot; not a solved problem |
+
+## What "hardened" means per platform
+
+We ship the strongest hardening each platform physically allows. This varies and we are honest about it:
+
+- **Linux**: full kernel-level hardening (KSPP, hardened_malloc, AppArmor strict, verified boot we control)
+- **Android (Pixel)**: GrapheneOS-tier hardening (verified boot, hardened kernel, full app sandboxing)
+- **Android (other)**: variable — see [`platform-matrix.md`](platform-matrix.md)
+- **Windows**: configuration-layer hardening only — closed kernel, no developer-controlled verified boot, no extensible MAC framework. We turn every dial Microsoft exposes; we cannot turn dials they don't expose
+- **macOS**: configuration-layer hardening + Lockdown Mode + FileVault enforcement; we cannot modify XNU
+- **iOS**: profile-layer only; weakest tier in the family, labelled as such
+
+The buyer-facing pros/cons table in [`platform-matrix.md`](platform-matrix.md) makes this explicit so users choose with eyes open.
+
+## Trust roots
+
+A SilverMetal user trusts:
+
+1. **SilverLABS** — to ship what we say we ship. Mitigated by reproducible builds, published signing keys, open source clients, and SBOMs
+2. **The platform vendor** of any closed platform (Microsoft / Apple) — we cannot escape this on Windows / macOS / iOS, and we say so
+3. **Their hardware** — Coreboot SKUs reduce this; commodity hardware does not eliminate it
+4. **Themselves** — to not negate the protections (installing arbitrary software, disabling SilverVPN, sharing devices)
+
+If you cannot trust SilverLABS, our open source code + reproducible builds let you verify what we ship matches what we publish.
+
+## Out-of-scope by design
+
+- **Anonymity** is not the default goal — that's a Tor / Whonix-class product. SilverMetal targets *privacy*, *integrity*, and *confidentiality*. A Tor-by-default sibling product may follow.
+- **Disposable / amnesic-by-default** is not the v1 default — Linux v1 has an optional amnesic session mode, but the product assumes a persistent device.
+- **Offline-only / air-gapped operation** is not a target — SilverSync and SilverVPN both depend on network connectivity, with graceful offline degradation.
+
+## Living document
+
+This threat model is updated when the product scope changes or when new attacker capabilities become broadly relevant. Version history lives in git; substantive changes are called out in release notes.
--- a/docs/trust-model.md
+++ b/docs/trust-model.md
@@ -0,0 +1,101 @@
+# Trust Model
+
+How users (and we) verify what SilverMetal ships. Trust is earned through verifiability, not asserted in marketing.
+
+## What a SilverMetal user trusts
+
+In rough order of decreasing necessity:
+
+1. **The hardware** — at minimum, the CPU and TPM. Coreboot-supported SKUs reduce firmware-level trust requirements. Commodity SKUs do not eliminate them.
+2. **SilverLABS' release signing keys** — to verify a downloaded image is genuine.
+3. **SilverLABS' build process** — to trust the published artefact came from the published source. Reproducible builds let users *verify* this rather than just trust it.
+4. **The platform vendor** — for Windows / macOS / iOS, we cannot eliminate trust in Microsoft / Apple. We say so explicitly.
+5. **SilverLABS' server infrastructure** — for hosted SilverVPN nodes, SilverSync, SilverChat. Self-hosting alternatives are documented.
+6. **Themselves** — to not negate the protections.
+
+## Reproducible builds
+
+Every SilverMetal release artefact is built reproducibly:
+
+- Pinned toolchain versions
+- Pinned dependency hashes
+- Stripped of build-environment metadata (timestamps, paths, host info)
+- CI re-builds from a clean checkout and verifies identical output
+
+The reproducibility procedure is published per-component. Anyone can:
+1. Clone the repo at the release tag
+2. Run the documented build command
+3. Compare SHA256 of their artefact to the published one
+
+Mismatch = supply chain anomaly. Report channel: `security@silverlabs.uk`.
+
+## Signing keys
+
+| Key | Purpose | Storage | Rotation |
+|---|---|---|---|
+| **SilverMetal Release** | Signs ISO/ROM/installer artefacts | Offline (HSM, ceremony-only access) | Major-version |
+| **SilverMetal Update Channel** | Signs OTA / apt updates | Online but isolated; sub-key model | Yearly or on compromise |
+| **SilverMetal Code Signing — Linux** | Signs `.deb`, kernel modules | Offline | Major-version |
+| **SilverMetal Code Signing — Windows** | Authenticode cert for `.exe`/`.msi` | HSM or signing service | Per-cert lifetime |
+| **SilverMetal Code Signing — macOS/iOS** | Apple Developer ID cert | Apple-managed | Per-cert lifetime |
+| **SilverMetal MOK (Linux Secure Boot)** | Our Machine Owner Key for Secure Boot | Offline | Major-version |
+| **SilverMetal AVB (Android verified boot)** | Android verified-boot key | Offline | Per-device-generation |
+
+Key fingerprints are published in `shared/signing/KEYS.md` (to be populated at first key generation).
+
+### Key ceremony policy
+- All offline keys generated in air-gapped environment
+- Multi-party control where feasible (M-of-N for the most critical keys)
+- Rotation procedure documented before keys are first used
+- Compromise procedure documented before keys are first used
+
+## SBOM (Software Bill of Materials)
+
+Every release publishes a complete SBOM in CycloneDX format:
+
+- All packages with version, source, license, hash
+- Build-time vs. runtime dependencies distinguished
+- Reproducible-build attestation linked
+
+SBOMs live in the release-page's `sbom/` directory.
+
+## Vulnerability response
+
+| Severity | Triage | Fix | Disclosure |
+|---|---|---|---|
+| Critical (active exploitation) | < 24h | Out-of-band release | Coordinated, then public |
+| High | < 72h | Next scheduled release | Coordinated, then public |
+| Medium | < 2 weeks | Next scheduled release | With release notes |
+| Low | Best-effort | Backlog | With release notes |
+
+Reports: `security@silverlabs.uk`, GPG key in `shared/signing/`.
+
+## What we publish (transparency)
+
+- **All source code** for our own components — open repos on `git.silverlabs.uk`
+- **Threat model** — `docs/threat-model.md`, updated when scope changes
+- **Reproducibility procedure** per-component
+- **SBOMs** per release
+- **Signing key fingerprints** and ceremony summaries
+- **Security advisories** — signed, dated, public archive
+- **Subpoena / law enforcement transparency report** — annual; we publish counts and what we had/didn't have
+- **Audit reports** — third-party audits published in full when commissioned
+
+## What we do *not* publish (and why)
+
+- **Active investigation details** — until coordinated disclosure window closes
+- **Per-user data** — we do not have most of it (minimum-data architecture); what we do have, we do not publish
+- **Server-side credential material** — for obvious reasons
+
+## Governance
+
+- This is a SilverLABS project; final calls rest with SilverLABS leadership
+- Security-critical decisions are documented (ADR-style) in `docs/decisions/` (to be created when first decision is needed)
+- Community contributions accepted via standard PR review with security-sensitive changes requiring a second reviewer
+
+## Honest acknowledgements
+
+- We are a small organisation. We will not match the auditor count of a Fortune-500 vendor
+- We use external upstream code (Kicksecure, GrapheneOS, Chromium, etc.) and inherit their trust assumptions
+- We cannot defend against every adversary; see [`threat-model.md`](threat-model.md) for what we do and do not target
+- Trust grows with track record; we expect to be audited and judged over time