Add Part 8 (Compliance) and Part 9 (Localization) with user feedback
- F30/F31: Added FIPS 140-3, CGO avoidance, compiler optimizations (Cardinal Rule #3.5) - F32: Differentiated audit retention: 7 years (paying) vs 90 days (non-paying) - F33: Noted Zurich central addresses cross-border compliance - F34: RTL explicitly not a priority - F35: Form field detection kept unaddressed as core evolving feature - F36: Already agreed on LLM methodology
This commit is contained in:
parent
724f64bda5
commit
199495cdd8
|
|
@ -294,6 +294,24 @@ and `P3` should appear almost nowhere in the codebase. If you find yourself
|
|||
using them, stop. These are browser-only concepts. Their presence outside
|
||||
`auth.js`, `crypto.js`, or the C CLI is a sign of architectural drift.
|
||||
|
||||
### Cardinal rule #3.5 — Cryptographic hygiene
|
||||
|
||||
**FIPS 140-3 compliance:** All cryptographic operations must be FIPS 140-3
|
||||
validated or in the process of validation. This means:
|
||||
- Use standard library crypto (Go: `crypto/` packages, C: OpenSSL FIPS module)
|
||||
- No custom cryptographic primitives
|
||||
- No home-grown key derivation or random number generation
|
||||
|
||||
**Avoid CGO where possible:** CGO (Go's C interoperability) creates build
|
||||
complexity, deployment friction, and audit surface. Prefer:
|
||||
- Pure Go implementations for new code
|
||||
- CGO only when FIPS mandates it (e.g., specific HSM integrations)
|
||||
- The C CLI (`clavis-cli`) is the only CGO-heavy component by design
|
||||
|
||||
**Compiler optimizations:** Standard `memset` or `clear()` may be optimized
|
||||
away. Use `runtime.memclrNoHeapPointers` (Go) or `memset_explicit` (C11) to
|
||||
ensure key material is actually cleared from memory.
|
||||
|
||||
### Cardinal rule #4 — Three threats, no others
|
||||
|
||||
The owner is not a threat — they paid for the vault, they hold the keys,
|
||||
|
|
@ -1109,4 +1127,57 @@ When a stolen agent token is used from an unauthorized IP:
|
|||
|
||||
---
|
||||
|
||||
## Part 8 — Compliance & Data Governance
|
||||
|
||||
### Data retention by customer tier
|
||||
|
||||
| Data type | Paying customers | Non-paying (community) | Rationale |
|
||||
|-----------|------------------|------------------------|-----------|
|
||||
| Vault content | Until deletion + 30 days | Until deletion + 7 days | Business continuity vs storage costs |
|
||||
| Audit logs | 7 years (SOC 2/SOX) | 90 days | Regulatory requirement vs convenience |
|
||||
| Failed auth | 90 days | 30 days | Threat analysis window |
|
||||
| Backups | 30 days rolling | 7 days rolling | Disaster recovery needs |
|
||||
| Telemetry | 90 days | None | Commercial optimization only |
|
||||
|
||||
Non-paying users accept reduced retention as a trade-off for free service.
|
||||
Upgrade to commercial = full compliance coverage.
|
||||
|
||||
### Cross-border transfers
|
||||
|
||||
**Zurich central as anchor:** Our central infrastructure is in Zurich, Switzerland.
|
||||
This addresses most compliance concerns:
|
||||
- Swiss data protection (adequate under EU GDPR)
|
||||
- POPs are data processing extensions, not independent controllers
|
||||
- No EU→US transfer issues for European customers
|
||||
- Asian customers: POPs hold encrypted WL3 only (no PII), minimal exposure
|
||||
|
||||
Standard Contractual Clauses (SCCs) in place for enterprise customers who require
|
||||
them. Default terms cover most use cases without additional paperwork.
|
||||
|
||||
---
|
||||
|
||||
## Part 9 — Localization (i18n/l10n)
|
||||
|
||||
### Status: English-first, limited localization
|
||||
|
||||
**Current priority:**
|
||||
- ✅ Error message codes (ERR-12345) — universal, no translation needed
|
||||
- ✅ CLI output — English only (dev/ops audience)
|
||||
- ✅ Web UI — English only (for now)
|
||||
- ❌ RTL (Arabic/Hebrew) — not a priority for initial markets
|
||||
- ❌ Full UI translation — future phase, post-product-market-fit
|
||||
|
||||
### Form field detection — core feature
|
||||
|
||||
Browser extension form detection is **intentionally unaddressed in this document**.
|
||||
It is a core product feature that will evolve through:
|
||||
- W3C `autocomplete` attribute support (universal)
|
||||
- ML-based field classification (language-agnostic)
|
||||
- Community contribution for locale-specific heuristics
|
||||
|
||||
We do not mandate specific implementation here because rapid iteration is required.
|
||||
The feature will mature separately from these architectural principles.
|
||||
|
||||
---
|
||||
|
||||
*Foundation First. No mediocrity. Ever.*
|
||||
|
|
|
|||
Loading…
Reference in New Issue