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>
99 lines
4.8 KiB
Markdown
99 lines
4.8 KiB
Markdown
# 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.
|