cesnimda
2b6a0ea3f0
World-class discovery specification (design phase, no code): - Executive summary, architecture review, competitor + user research - UX/UI redesign + design system + themes, flagship search redesign - AI strategy (local Ollama, RTX 3080) + feature catalogue - Technical architecture, roadmap (MVP->v3), git plan, risks - Multi-provider platform: IEmailProvider abstraction, OAuth-as-login, unified DB schema, settings + feature flags, admin/RBAC, security model, 6-phase implementation plan, migration guide Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
3.3 KiB
3.3 KiB
11 — Risk Analysis
Risks specific to the multi-provider + multi-user + admin evolution (the blueprint-wide risks are in ../11). L/I = Likelihood/Impact (H/M/L).
| # | Risk | L | I | Mitigation |
|---|---|---|---|---|
| M1 | Account-linking hijack (attach someone's mailbox to your user) | L | H | Must authenticate as the target user; unique (provider, sub); explicit "already owned" block; audited (02) |
| M2 | Cross-user data leakage (multi-user IDOR) | M | H | EF global query filters on user_id/account_id; policy-based authz; no admin route reads user mail; tests for isolation |
| M3 | OAuth token theft / exposure | L | H | Encrypted at rest (Data Protection); never logged or sent to browser; rotation; bytea ciphertext |
| M4 | Provider quirks break sync (Graph delta resets, IMAP UIDVALIDITY change, Gmail history gaps) |
M | M | Per-provider cursor handling with full-resync fallback; idempotent upserts; capability flags; account flips to needs-attention, never crashes |
| M5 | Migration corrupts existing Gmail data | L | H | Additive-only schema; backfill is idempotent; maintenance window; tested on a staging copy; reversible (12) |
| M6 | RBAC bug grants Member admin powers | L | H | Server-side policies (not UI); admin-only role changes audited + force session refresh; can't demote last Admin; authz tests |
| M7 | Feature-flag misconfiguration (AI/provider on when not ready) | M | M | Flags default off/fail-closed; land dark; enable in staging first; audited toggles; rollout by role |
| M8 | AI gate bypass (feature runs when disabled) | L | M | Single IAiGate chokepoint before any AI call; Null providers; capability checks; no direct provider refs in core |
| M9 | Session/CSRF weaknesses across new surfaces | M | M | Server-side sessions, id rotation, SameSite + CSRF token, revoke-all, short idle expiry |
| M10 | Admin abuse / mistake (mass suspend, wrong flag) | M | M | Step-up confirm + rate-limit + full audit trail + reversible flags |
| M11 | Scaling: millions of msgs × multiple accounts | M | M | Denormalised user_id, keyset pagination, GIN/trgm/HNSW indexes, optional account_id partitioning, per-account sync throttling |
| M12 | Provider OAuth app setup burden (separate Google + Microsoft app registrations, redirect URIs, verification) | M | L | Documented setup per provider; providers flag-gated so an unconfigured one is simply hidden |
| M13 | Scope/verification friction (Google restricted scopes, MS admin consent) | M | M | Least-privilege scopes; document the consent/verification path; self-host uses the operator's own OAuth apps |
Top watch-items
- M2 (isolation) and M6 (RBAC) — the two ways multi-user can go wrong; both mitigated by server-side authz + query filters + isolation tests as a release gate.
- M4 (provider sync quirks) — the most likely operational pain; the full-resync fallback and per-account isolation contain it.
Overall
The flag-gated, additive, isolated design makes this evolution low-blast-radius: each provider and the AI layer land dark and roll back by flag, migrations are additive, and the security model closes the new multi-user gaps. Proceed phase by phase behind flags.