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

| 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 |

- 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.

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.

- 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.

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.

---