Implement legal terms, Android client compatibility and more

.cursor/commands/security-audit.md

@@ -1,90 +1,51 @@
 # Security Audit Command
 
-Perform a comprehensive security audit of the FromChat application codebase.
+Perform a comprehensive security audit of the FromChat **Android application** only.
 
 ## Project Context
 
-**FromChat** is a 100% open source secure messaging application with:
+**FromChat Android** is a 100% open source secure messaging mobile application built with:
 
-- React/TypeScript frontend
-- Python FastAPI backend
-- Caddy reverse proxy with security headers
+- Kotlin Multiplatform (KMP) shared code
+- Jetpack Compose UI framework
+- End-to-End Encryption (NaCl, AES-GCM)
 - WebSocket support for real-time features
-- Electron support for desktop app
+- LiveKit integration for calls
+- Local database storage (SQLite)
+
+## Scope: Android Only
+
+**OUT OF SCOPE:**
+
+- Web backend (Python FastAPI, Caddy infrastructure)
+- React/TypeScript frontend
+
+**IN SCOPE:**
+
+- Android app code (`app/android`, `app/shared/src/androidMain`)
+- Shared cross-platform code (`app/shared/src/commonMain`)
+- Local encryption implementation (NaCl, AES-GCM)
+- Secure storage (Android Keystore, encrypted SharedPreferences)
+- WebSocket client security
+- Permission usage and handling
+- Call security (LiveKit integration)
+- Memory safety and injection attacks
+- Backend
 
 ## Important Design Decisions (NOT Vulnerabilities)
 
 When auditing, remember these are **intentional design choices**:
 
-1. **Public messages endpoint** - Open forum accessible without authentication (by design)
-  - The public chat is meant to be an open forum
-  - Private DMs are properly E2E encrypted and require authentication
-2. **Public user list** - All users visible in DMs tab (by design)
-  - Users can see all registered accounts
-  - This is intentional for a community-based chat app
-3. **XSS protection** - Multi-layer defense already implemented:
-  - React auto-escaping
-  - DOMPurify for sanitization
-  - Caddy CSP headers
-  - Do NOT flag localStorage key storage as critical (already well-protected)
-4. **File upload security** - Docker isolation in place:
-  - Server runs in Docker without executable flags
-  - Files cannot execute on server
-  - PIL re-encodes images
-  - Do NOT flag Content-Type validation as critical
-5. **CSRF protection** - Not needed:
-  - No cookies used
-  - JWT tokens in Authorization headers only
-  - CSRF attacks don't apply to this auth model
-6. **Beta domain CSP** - 'unsafe-inline' is required:
-  - Beta domain (beta.fromchat.ru) points to development machine
-  - Vite dev server requires 'unsafe-inline' to function
-  - Production domain has strict CSP
-7. **Security logging** - Already implemented:
-  - All events are logged including security-related activity
-  - Do NOT flag as missing
-8. **100% Open Source** - This is a security strength:
-  - Full transparency
-  - Community review capability
-  - No hidden backdoors
-
-## Android App
-
-**EXCLUDE from all audits** - Android app is not production-ready and out of scope.
-
-## Infrastructure (Caddy)
-
-The application runs behind Caddy reverse proxy with comprehensive security controls:
-
-### Key Infrastructure Protections
-
-- ✅ **HTTPS enforcement** - Automatic SSL/TLS with Caddy
-- ✅ **HSTS** - Strict-Transport-Security with preload
-- ✅ **CSP** - Content Security Policy (strict on production, 'unsafe-inline' for scripts on beta for Vite)
-- ✅ **Rate limiting** - 500 events/min (production), 1000 events/min (beta)
-- ✅ **X-Frame-Options: DENY** - Prevents clickjacking
-- ✅ **X-Content-Type-Options: nosniff** - Prevents MIME sniffing
-- ✅ **X-XSS-Protection: 1; mode=block** - XSS protection
-- ✅ **Permissions-Policy** - Restricts geolocation, allows camera/mic for calls
-
-**Important:** These protections are already in place at the infrastructure level. Don't flag missing security headers or rate limiting in the application code.
-
-## Audit Process
-
-1. **Read the Caddyfile first** to understand infrastructure protections
-2. **Check backend code** for authentication, authorization, input validation
-3. **Review frontend code** for XSS protections, crypto implementation
-4. **Verify E2E encryption** implementation (NaCl for DMs, AES-GCM for calls)
-5. **Test CORS configuration** in backend/app.py
-6. **Review password policies** in backend/validation.py
-7. **Check file upload handling** in backend/routes/messaging.py and profile.py
-
-## Rating Guidelines
-
-- **Infrastructure (Caddy):** Should be 9/10 or higher (excellent security headers)
-- **Cryptography:** Should be 8-9/10 (uses industry-standard libraries)
-- **Frontend Security:** Should be 7-8/10 (multi-layer XSS protection)
-- **Backend API:** Focus on CORS, password policies, rate limiting
+1. **Local message caching** - Messages downloaded and stored locally (by design)
+  - Messages are end-to-end encrypted at rest in local DB
+  - Public DMs are not encrypted (messages are public)
+  - Private DMs use NaCl encryption
+  - Cache persists across app restarts for offline access
+2. **Local key storage** - Encryption keys stored on device (by design)
+  - Keys protected by Android Keystore (hardware-backed when available)
+  - Encrypted with device-specific secrets
+  - User data never leaves device in plaintext
+  - Do NOT flag key storage as critical (Keystore is production-ready)
 
 ## Output Format
 
@@ -94,8 +55,8 @@ Provide a **clean, concise report** with:
 2. **Security Status** - Critical issues (if any) and recommendations
 3. **Security Strengths** - What's done well
 4. **Component Ratings** - Table format for quick reference
-5. **Design Decisions** - Clarify what's intentional vs vulnerable
-6. **Threat Analysis** - Current realistic threats only
+5. **Architecture Review** - Data flow, encryption boundaries
+6. **Threat Analysis** - Current realistic threats (e.g., rooted device, malicious APK)
 7. **Recommendations** - Prioritized with time estimates
 8. **Conclusion** - Clear production readiness statement
 
@@ -105,44 +66,7 @@ Provide a **clean, concise report** with:
 
 ❌ **DO NOT FLAG THESE AS ISSUES:**
 
-- Public messages endpoint (intentional)
-- Username enumeration (users list is public by design)
-- Keys in localStorage (XSS is well-protected)
-- Content-Type validation (Docker isolation prevents execution)
-- CSRF protection (not applicable - no cookies)
-- Beta CSP 'unsafe-inline' (required for Vite)
-- Security logging (already implemented)
-- Android app security (out of scope)
-
-## Key Security Features to Verify
-
-✅ **MUST CHECK:**
-
-- CORS configuration in backend/app.py
-- Password validation in backend/validation.py
-- JWT token generation and validation
-- Encryption implementation (NaCl, AES-GCM)
-- File upload sanitization
-- Authorization checks on sensitive endpoints
-- Rate limiting configuration
-- Security headers in Caddyfile
-
-## Example Good Finding Format
-
-```markdown
-### Password Policy (HIGH PRIORITY - Non-blocking)
-**Current:** 5 character minimum
-**Recommended:** 12+ characters with complexity requirements
-**Risk:** Brute force attacks (mitigated by rate limiting)
-**Estimated Fix:** 4-6 hours
-**Code Location:** backend/validation.py:11-16
-```
-
-## Notes from Developer
-
-- Application is production-ready after CORS fix
-- Focus on practical, actionable improvements
-- Don't overthink things that are already well-protected
-- Open source is a feature, not a concern
-- Community can audit the code themselves
+- Local message caching (intentional for offline access)
+- Public message viewing without auth (intentional design)
+- Debuggable APK (only relevant if signed/released)