Commit c61c46
2026-08-07 11:36:21 admin: init| /dev/null .. security, privacy, and compliance.md | |
| @@ 0,0 1,104 @@ | |
| + | --- |
| + | title: Security, Privacy, and Compliance |
| + | aliases: [Security Audit, FERPA COPPA] |
| + | tags: [3netra/wiki, security, privacy, compliance] |
| + | product: 3netra Meta Android App |
| + | source_repository: 3Netra-ai/3n_meta_android |
| + | source_ref: origin/prod |
| + | source_revision: b48aada8fd5427b5db0c02945569963c4ae543c8 |
| + | last_verified: 2026-08-06 |
| + | up: "[[Home]]" |
| + | --- |
| + | |
| + | # Security, Privacy, and Compliance |
| + | |
| + | ## Data classification |
| + | |
| + | | Data | Sensitivity | Current handling | Required control | |
| + | |---|---|---|---| |
| + | | Account/session tokens | High | Supabase client session | Secure SDK storage, revocation, short-lived tokens | |
| + | | Student profile and academic level | High | Supabase plus local preferences | Student consent, least privilege, deletion | |
| + | | Camera images/video | Very high | Encoded and sent to backend for assistance | Notice, minimization, no implicit retention | |
| + | | Voice/audio/transcripts | Very high | Android/Sarvam/backend paths | Vendor disclosure and retention policy | |
| + | | Face embeddings | Biometric/critical | CSV in Supabase active flow | Explicit consent, encryption, RLS, deletion, audit | |
| + | | Classmate/instructor identity | High | Supabase face records | Enrollment authority and subject rights | |
| + | | Emergency/location data | Critical | Incomplete flow | Accuracy, availability, escalation, retention | |
| + | | Activity/session history | High | Memory and Supabase concepts | Purpose limitation and role-based access | |
| + | |
| + | ## Trust boundaries |
| + | |
| + | ```mermaid |
| + | flowchart LR |
| + | Student[Student/user] -->|consent and actions| Device[Android trust boundary] |
| + | Device -->|public client credentials| Supabase[Supabase trust boundary] |
| + | Device -->|media and prompts| Edge[Supabase Edge Function trust boundary] |
| + | Backend --> Model[AI vendor trust boundary] |
| + | Device --> Sarvam[Sarvam trust boundary] |
| + | Staff[Faculty/Disability Specialist] -->|enrollment authority| Device |
| + | ``` |
| + | |
| + | ## Verified controls |
| + | |
| + | - Supabase manages authentication instead of a custom password store. |
| + | - Teacher/Admin PIN values are BCrypt-hashed before local storage. |
| + | - An AES-backed encrypted local face-storage utility includes a 90-day retention concept, but no active call site uses it. |
| + | - The Android app invokes a Supabase Edge Function for AI. Its returned model text is discarded in the current client; this is not evidence of a secure or working AI boundary. |
| + | - Runtime permission rationale screens explain camera, microphone, location, Bluetooth, and notifications. |
| + | |
| + | ## Critical gaps |
| + | |
| + | 1. **Biometric path mismatch:** active face enrollment stores CSV embeddings in Supabase; the encrypted local store is unused. |
| + | 2. **No repository proof of RLS:** schemas, migrations, policies, grants, and RLS tests were not found in the reviewed app. Client checks are not authorization. |
| + | 3. **Consent not operational:** a default-false consent field and fabricated age do not constitute student/guardian verification. |
| + | 4. **Misleading privacy copy risk:** UI claims about on-device recognition or FERPA compliance exceed verified controls. |
| + | 5. **Face model fail-open:** model-load failure can yield random embeddings rather than disabling recognition. |
| + | 6. **Sensitive logging:** device/session identifiers, similarity values, and embedding samples may enter Android logs. |
| + | 7. **Client configuration:** API values compiled into the app are extractable. Only public/publishable values belong there. |
| + | 8. **Signing assets:** a release keystore is tracked in the secondary Android project; release signing ownership and secret handling need remediation. |
| + | 9. **Emergency reliability:** incomplete GPS/wiring makes the SOS capability unsafe to represent as operational. |
| + | 10. **Credential exposure and server boundary:** secret-like configuration is compiled into the app or committed as fallback source configuration; the AWS prototype also contains a provider-authorization implementation. Do not reproduce values in docs; rotate/revoke exposed material and move all provider secrets to managed server/Edge-function secret stores. |
| + | 11. **Undemonstrated retention:** active face records are cloud rows; no repository code invokes the local 90-day cleanup, and the SAM bucket has no lifecycle configuration. |
| + | |
| + | ## Supabase security requirements |
| + | |
| + | - Enable RLS on every table exposed through the Data API. |
| + | - Use ownership/relationship predicates; `TO authenticated` alone is not object-level authorization. |
| + | - Give update policies both `USING` and `WITH CHECK`, and ensure required select policies exist. |
| + | - Keep authorization roles in app metadata or relational tables, never user-editable metadata. |
| + | - Never ship a `service_role` or secret key in the Android app. |
| + | - Confirm whether tables are exposed to Data API roles; exposure grants and RLS solve different problems. |
| + | - Test student, instructor, and unauthorized cross-tenant access as separate identities. |
| + | |
| + | ## Minimum biometric lifecycle |
| + | |
| + | ```mermaid |
| + | stateDiagram-v2 |
| + | [*] --> Notice |
| + | Notice --> StudentConsent: student approves |
| + | StudentConsent --> Enroll: named subject and purpose recorded |
| + | Enroll --> Active: encrypted embedding stored |
| + | Active --> Accessed: recognition request authorized |
| + | Accessed --> Active: audited |
| + | Active --> Deleted: withdrawal, retention expiry, account deletion |
| + | StudentConsent --> Denied: declined |
| + | Denied --> [*] |
| + | Deleted --> [*] |
| + | ``` |
| + | |
| + | ## Compliance interpretation |
| + | |
| + | FERPA and India's DPDPA are product/legal obligations, not SDK features. Current documents express alignment goals, but the repository does not prove compliance. Before production use with students, obtain legal review and produce: |
| + | |
| + | - authoritative age/audience policy; |
| + | - student consent and revocation workflow; |
| + | - biometric consent and retention policy; |
| + | - role and institution-tenant authorization matrix; |
| + | - RLS schema and automated policy tests; |
| + | - vendor/subprocessor and cross-border data inventory; |
| + | - deletion/export workflow and audit evidence; |
| + | - incident response and child-safety review. |
| + | |
| + | --- |
| + | |
| + | > [!tip] Navigation |
| + | > ⬅️ [[10-Engineering-Ops|Engineering Ops]] · 🏠 [[Home]] · ➡️ [[12-Risks-Decisions|Risks & Decisions]] |