The classic security triad. Most solo devs default-care about C ("don't leak"), occasionally think about A ("don't crash"), and almost never explicitly think about I ("nobody silently changed my data"). Naming all three keeps your reasoning honest.
| Letter | Property | Solo-dev failure | Defense |
|---|---|---|---|
| Confidentiality | Only authorized eyes see data | Open admin; logs in /static; .env in repo | Auth, HTTPS, file permissions, secret managers |
| Integrity | Data isn't tampered with | HTTP (no S) + coffee shop = injected JS; SQL injection | HTTPS, parameterized queries, signed cookies, hashes |
| Availability | You can use the service when you need it | Open Ollama port = anyone can DOS your VRAM | Rate limits, queue caps, backups, monitoring |
The trade-offs are real
You can't max all three for free; each costs the others to some extent.
- More C costs A — Stricter auth means more friction, occasional lockouts (you locking yourself out is an availability failure).
- More A costs C — "Always logged in everywhere" maximizes uptime perception but is a confidentiality nightmare on a lost device.
- More I costs A — Strong audit logging slows writes; integrity checks slow reads.
The hidden letter: Auditability
Some practitioners extend CIA to CIAA — the second A is auditability, the ability to know what happened. For solo work, this is the difference between "I notice my phone is missing" and "I can prove which sessions and IPs were active when." Track 8's admin dashboard is the auditability layer.