3.7 KiB
Chanora Security, Privacy, and Legal Guideline
Document status: DV meeting baseline candidate
Date: 2026-05-29
Scope: Release-gate expectations for security, privacy, diagnostics, legal wording, and OSS review
1. Purpose
This guideline defines the minimum security, privacy, and legal checks that must be satisfied before Chanora moves beyond internal validation. It supports DV review by making gate ownership and evidence expectations explicit.
2. Gate Summary
| Gate | Requirement source | Required evidence | Current DV status |
|---|---|---|---|
| Secure storage | SysRS-237, SysRS-256, SRS-090 through SRS-095, SRS-126, SRS-137 | Platform audit for secret storage and fallback behavior | Partial; Android DEK waiver active |
| Diagnostic redaction | SysRS-238, SysRS-257, SRS-093 through SRS-102, SRS-126 | Redaction tests and export review | Evidence must be attached before external tester enablement |
| No automatic telemetry/upload | SysRS-295 and related SysDes/SRS privacy clauses | Inspection of runtime behavior and privacy wording | Baseline policy: no automatic upload in MVP |
| Dependency and OSS review | DEC-012, CI supply-chain jobs | Cargo deny/about, Flutter license inventory, legal sign-off | CI checks defined; DEC-012 remains open |
| Trademark/non-affiliation wording | SysRS-006, SysRS-240 | Legal/trademark review and UI/release wording inspection | Blocks public release until signed off |
| Privacy policy | Privacy and release readiness requirements | Published or approved privacy text | Baseline candidate exists; owner/legal review required |
3. Secure Storage Expectations
Sensitive data includes server passwords, identity/private-key material, tokens, diagnostic known secrets, and any credential-equivalent values. The application must use platform secure storage where available and must not silently advertise stronger protection than the active backend provides.
Required release evidence:
| Platform | Required evidence |
|---|---|
| Android | Key storage and DEK behavior review; Android Keystore-backed DEK gap is a release limitation until closed |
| iOS | Keychain behavior review on device |
| macOS | Keychain behavior review |
| Windows | Credential Manager behavior review |
| Linux | Secret Service behavior review and fallback limitation disclosure |
4. Diagnostic Redaction Expectations
Diagnostics must be user-initiated. Logs and export bundles must redact credentials, tokens, private paths when sensitive, host/IP/email where configured, and known secrets registered by runtime code.
Diagnostic evidence must include:
| Evidence | Required result |
|---|---|
| Redaction tests | Known secret classes are removed or replaced before export |
| Export demo | User can create a diagnostic bundle without automatic upload |
| Manual inspection | Exported JSON does not contain sample secrets used during the test |
| Privacy wording | User-facing policy explains what diagnostics contain and how sharing occurs |
5. Legal and OSS Expectations
Before public/store release, DEC-012 must close with approval covering:
| Topic | Required result |
|---|---|
| TeamSpeak compatibility wording | Wording states compatibility without implying official affiliation |
| App name and metadata | Store, README, About dialog, and release notes avoid prohibited claims |
| OSS license inventory | Rust and Flutter dependencies have reviewed license inventory |
| NOTICE and attribution | Notices are complete for bundled or linked third-party software |
| Vulnerability/advisory review | Known critical issues are resolved, waived, or documented by owner approval |
6. DV Conclusion
Security, privacy, and legal gates are sufficiently documented for DV discussion. They are not sufficiently closed for public/store release.