Quta Data Handling & Retention Notice

1. Data minimisation

Quta should collect only data that is reasonably necessary for the feature being used. Optional permissions such as location and device contacts should be requested at the point of need rather than at initial installation or registration.

2. Main data categories

• Account/profile: username, display name, avatar, bio, phone, email and account identifiers.
• Location: precise coordinates may be processed internally for Nearby; ordinary users should receive only distance/proximity output.
• Contacts: Quta-internal contacts and, where enabled by the user, limited device-contact data for matching.
• Messaging: message/reply content, sender, receiver, timestamps, read state and conversation origin.
• Social content: statuses, media, comments, likes and views where enabled.
• Safety: blocks, reports, moderation decisions and relevant evidence.
• Technical: authentication, login, device, network and security logs.

3. Access control

• RLS should remain enabled on production tables containing user data.
• Raw location data must not be directly exposed to ordinary users; proximity should be returned through controlled queries/RPCs.
• Private messages should be readable only by authorised participants and authorised moderators where necessary.
• Reports and moderation records should be restricted to authorised personnel.
• Service-role credentials and administrative secrets must never be embedded in the mobile client.

4. Location handling

When Nearby location sharing is enabled, Quta may store precise location as a geographic point for calculation. The app should return privacy-preserving proximity information to other users. When the user turns Nearby location sharing off, Quta should stop active location processing for that feature and clear or invalidate current location information where technically implemented.

5. Contact handling

If device-contact matching is enabled, access should be optional and purpose-limited. Quta should avoid uploading unnecessary address-book fields and should not expose a user’s private contacts to other users.

6. Authentication and OTP

Development-only authentication shortcuts, test OTP tables or bypass mechanisms must not be used in production. Production verification should use an approved SMS/authentication provider and appropriate rate limiting, expiry and abuse controls.

7. Data consistency

Where phone or email data is intentionally duplicated between authentication and profile records for performance, update and deletion flows should keep the copies synchronised and avoid stale or conflicting personal data.

8. Retention and deletion

Active-account data is retained while needed to provide Quta. On deletion, personal data should be removed or anonymised except where lawful retention is required for security, fraud prevention, dispute resolution or legal compliance. Backup copies may persist for up to 90 days.

The public deletion resource should explain how users initiate deletion and what limited information, if any, may remain temporarily or be retained lawfully.

9. International hosting

Quta’s production database is currently hosted in Singapore through Supabase infrastructure. Quta should maintain documentation of cross-border data flows, service providers, safeguards and any Tanzanian regulatory permissions required for international transfer.

10. Incident response

• Identify and contain suspected data incidents promptly.
• Preserve logs and evidence necessary for investigation.
• Limit internal access to people who need it.
• Assess whether users, regulators or law enforcement must be notified under applicable law.
• Document corrective actions and prevent recurrence.

11. Accountability

Quta should maintain an appointed privacy/DPO contact, a current data inventory, documented retention periods, a list of key processors/service providers and a change log for material updates to privacy practices.

Privacy / DPO contact: privacy@quta.app

Legal contact: legal@quta.app

Website: www.Quta.app