Shengal Privacy Policy — English working draft DRAFT — NOT FOR PUBLICATION OR RELIANCE. This is a factual, engineering informed source draft for product, security, and counsel review. It is not a legal notice, legal advice, or a compliance representation. TODO items must be decided before publication. 1. Controller, scope, and contact TODO — counsel: identify the legal entity/controller, address, privacy contact, data protection contact, supported markets, applicable law, and the effective date/versioning method. This draft covers the Shengal application/backend behavior reviewed on 2026 10 14. Repository behavior can change; the approved published version must state what services and clients it covers. The engineering evidence for this draft is the backend source, migrations, route area documentation, lifecycle workers, and deployment readiness documents listed in shengal backend/docs/backend/data privacy and legal audit.md . Those references establish repository behavior only; they do not establish deployed configuration, provider contracts, processing locations, or a legal conclusion. 2. Information the service may process The categories below are technical inventory, not a promise that every field is collected in every flow. Account and identity User ID, email, username, first and last name, date of birth, locale, profile biography, external URL, avatar reference, lifecycle state, account standing, password hash, and Apple/Google identity provider identifiers or email when provided. Authentication, security, and sessions OTP and password reset challenge identifiers, hashed challenge values, expiry, attempt and consumption state; refresh session token hashes, expiry, timestamps, IP addresses, and user agent values; and authentication events containing action, identifier/outcome, IP/subnet, user agent, locale, VPN suspicion flag, and time. Social activity and content Privacy settings, follows, follow requests, blocks, posts, captions, comments, replies, likes, saves, stories, story views/likes, collections, live stream participation/comments/moderation events, reports, feedback, and moderation or safety takedown state. Uploaded media may include blob reference, content type, size, subtitles/duration, and feature metadata. Messages and calls Messaging devices and public keys, key packages/envelopes, thread membership, encrypted message/call payload fields, message type and timestamps, deletion and read state, share references, encrypted attachment metadata, call room/provider references, participants, key envelopes, and call events. TODO — security/product/counsel: verify and describe the deployed encryption boundary precisely. The repositories contain conflicting descriptions of server message content visibility. Do not publish an end to end encryption promise until that conflict is resolved against deployed client and server behavior. Notifications, devices, analytics, and support Notification preferences and rows, delivery state, installation/platform/ provider information, push token and token hash, invalidation state, bounded analytics events and allowlisted properties, application/device/OS/locale context in feedback, and bounded diagnostics. Community and verification Language consent timestamps, source language, assignments, prompts, contribution text/media, review state, reviewer notes, and timestamps. Community verification records may include community affiliation, region, origin, lineage, badge/field visibility, reviewer eligibility, and review timestamps. TODO — counsel/product: classify these fields, especially affiliation, origin, lineage, region, date of birth, voice/media contributions, and reviewer notes; decide whether additional notices or explicit consent are required. Language contributions, voice, and progression The reviewed backend branch also supports language contribution text, translations, transcriptions, audio recordings, validation votes and revisions, assignments, corrections, reviewer notes, consent records, progression and trust ledgers, privacy requests, retention groups, and purge work records. Related fields may include language and writing system identifiers, contribution status, text role and content, audio storage reference, duration and size, validation scores/notes, consent document version and timestamp, retention scope, request/idempotency values, and progression or trust activity references. Users may be able to withdraw language contributions and include language data in an account export. The branch documents separate text and voice choices for account deactivation or deletion, staged erasure, and export of language metadata and available voice media. The branch also documents a one time recovery key display with only an HMAC verifier stored. These statements describe reviewed backend behavior; they do not establish a legal retention period, anonymisation conclusion, client collection flow, or use of a speech or machine learning provider. Language contribution eligibility and training status The reviewed backend has consent gated candidate views for language text and voice records. Eligibility requires current lifecycle and validation conditions and a latest granted contribution document for the relevant text or voice scope. Consent records include a document key and version, scope, status, timestamps, and supersession information. The reviewed repository does not contain a training run, dataset export, model version, or source to model lineage record. It therefore cannot establish whether a particular contribution was copied into a training dataset or already incorporated into a trained model. Withdrawal and account deletion can redact or purge backend source records and configured media, but this draft makes no claim that data can be removed from an external dataset or trained model, and makes no promise of model untraining. Language audit events are append only in the reviewed database design. Account deletion can remove the actor user association, while event subjects, metadata, and timestamps may remain. The retention period and any audit retention exception require counsel, security, and product approval. When selected language text or voice is retained during account deletion, the backend can return a recovery reference and one time recovery key; only an HMAC verifier is stored. The reviewed code includes a service level verification and purge function, but no user facing recovery purge route was evidenced. The post deletion workflow and any external dataset/model handling remain unresolved. 3. How information is collected and used Information may be supplied by the user during signup, profile/content creation, reports, feedback, community activities, and account controls; received from Apple or Google when social sign in is used; generated by authentication, security, visibility, moderation, notification, messaging, call, live, export, and deletion operations; and received from device push registration flows. Technical purposes evidenced by the backend are to provide and secure the service, authenticate accounts, prevent abuse, enforce visibility and account standing, deliver notifications and email OTPs, host and deliver media, route messages/calls/live sessions, moderate/report content, operate community features, produce bounded product analytics/diagnostics, provide exports, and process deactivation/deletion. TODO — counsel: map each purpose to the applicable legal basis, consent or withdrawal mechanism, legitimate interest assessment where relevant, and any automated decision/profiling disclosure. 4. Visibility and sharing The product is authenticated by default. Public profile/content means visible to authenticated app users under the current backend contract; private profiles, audience controls, reciprocal blocks, and owner only resources restrict access. Administrators with approved staff roles can access specific operational, moderation, report, analytics, or community review surfaces. Technical provider integrations include Azure infrastructure/storage/Key Vault/ email, PostgreSQL/Redis, Cloudflare, Apple/Google identity verification, APNs/FCM, LiveKit, and Microsoft Entra for staff authentication. This is a technical dependency list, not an approved list of subprocessors or recipients. TODO — counsel/operations: confirm vendor names, legal roles, processing locations, international transfer language, contracts, support access, and the final public subprocessor list. 5. Storage, security, and encryption The code uses bcrypt password hashing, HMAC derived OTP values, hashed refresh tokens, JWT expiry/rotation, rate limits, request size limits, private media storage with short lived access URLs, managed identity/Key Vault references in staging infrastructure, and non root backend containers. Production runbooks direct operators not to log request bodies, authorization headers, message/call content, email, or user IDs. These are implementation controls, not a guarantee that no provider, backup, administrator, or compromised endpoint can access data. TODO — counsel/security: approve the final security description, incident notice process, and any certification or standards claim. No certification claim is made here. 6. Retention and deletion The backend has configurable cleanup jobs. Current defaults include 30 day raw analytics retention, 90 day auth event and closed diagnostics retention, 30 day OTP attempt/session and completed delivery retention, 90 day failed delivery/invalid push token retention, 180 day read notification retention, 24 hour unattached media grace, 30 day soft deleted media/story retention, 72 hour ready export retention, and a 15 minute export download URL. Account deactivation defaults to a 180 day deletion deadline, with 7/30/180 day choices. These values are technical defaults, not the approved legal retention schedule. Deletion removes owned blobs before user deletion and removes or scrubs most account linked records. The documented residual evidence is non identifying analytics with a null user, scrubbed report outcomes, scrubbed administrator audit action/time, and an HMAC only deleted username reservation. Backups, provider copies, legal holds, safety exceptions, and deployed overrides require separate verification. TODO — counsel/operations: approve retention by category, legal holds, backup and disaster recovery treatment, provider deletion SLAs, safety/report exceptions, and the user facing timeline. 7. Access, correction, export, and other requests The current backend provides profile editing, privacy settings, session controls, deactivation/reactivation, permanent deletion, and a bounded private account export. The export includes account/profile, content, media, interactions, community data, encrypted message metadata/share references, notification preferences, non secret push registration metadata, analytics, and sanitized security metadata; raw push tokens are excluded. On the reviewed language branch, the export also includes language contribution, translation, audio, correction, validation, progression, and trust data, plus available voice media. TODO — counsel/product: define the general privacy request intake, identity verification, correction/deletion/objection/portability workflow, exceptions, response timelines, appeals, regulator complaints, and whether additional rights are available in each market. No general legal rights workflow is inferred from the technical export endpoint. 8. Children and age information The Service is intended only for individuals age 13 or older. Individuals under 13 may not create or use an account. The backend requires date of birth and rejects signup below age 13. We do not knowingly collect personal information from children under 13. If we learn that we collected it, we will take appropriate steps to delete it. TODO — counsel/product: approve this draft wording, the final age notice, and the operational process for identifying and deleting an under 13 account. This draft does not state that parental consent is supported or make broader child law conclusions. 9. Cookies, SDKs, analytics, and transfers TODO — product/operations/counsel: inventory cookies, mobile SDKs, crash and performance telemetry, analytics identifiers, opt out controls, advertising (if any), automated profiling, cross border transfers, and provider regions. This repository audit found bounded first party analytics models but does not prove the complete client SDK or deployed network inventory. 10. Policy changes and approval record TODO — counsel: define notice of changes, effective date rules, acceptance history, withdrawal, locale precedence, and required re consent. The policy must be published only from an approved version with a recorded version, effective date, locale, last review, and counsel approval. Draft files must remain excluded from the future static site build. The backend review found no policy version or policy acceptance model in the reviewed user/auth schema; the final acceptance record and client version history therefore remain unresolved.
Shengal Privacy Policy — English working draft
1. Controller, scope, and contact
TODO — counsel: identify the legal entity/controller, address, privacy contact, data-protection contact, supported markets, applicable law, and the effective date/versioning method.
This draft covers the Shengal application/backend behavior reviewed on 2026-10-14. Repository behavior can change; the approved published version must state what services and clients it covers.
The engineering evidence for this draft is the backend source, migrations, route-area documentation, lifecycle workers, and deployment-readiness documents listed in shengal-backend/docs/backend/data-privacy-and-legal-audit.md. Those references establish repository behavior only; they do not establish deployed configuration, provider contracts, processing locations, or a legal conclusion.
2. Information the service may process
The categories below are technical inventory, not a promise that every field is collected in every flow.
Account and identity
User ID, email, username, first and last name, date of birth, locale, profile biography, external URL, avatar reference, lifecycle state, account standing, password hash, and Apple/Google identity provider identifiers or email when provided.
Authentication, security, and sessions
OTP and password-reset challenge identifiers, hashed challenge values, expiry, attempt and consumption state; refresh-session token hashes, expiry, timestamps, IP addresses, and user-agent values; and authentication events containing action, identifier/outcome, IP/subnet, user agent, locale, VPN-suspicion flag, and time.
Social activity and content
Privacy settings, follows, follow requests, blocks, posts, captions, comments, replies, likes, saves, stories, story views/likes, collections, live-stream participation/comments/moderation events, reports, feedback, and moderation or safety-takedown state. Uploaded media may include blob reference, content type, size, subtitles/duration, and feature metadata.
Messages and calls
Messaging devices and public keys, key packages/envelopes, thread membership, encrypted message/call payload fields, message type and timestamps, deletion and read state, share references, encrypted attachment metadata, call room/provider references, participants, key envelopes, and call events.
TODO — security/product/counsel: verify and describe the deployed encryption boundary precisely. The repositories contain conflicting descriptions of server message-content visibility. Do not publish an end-to-end-encryption promise until that conflict is resolved against deployed client and server behavior.
Notifications, devices, analytics, and support
Notification preferences and rows, delivery state, installation/platform/ provider information, push token and token hash, invalidation state, bounded analytics events and allowlisted properties, application/device/OS/locale context in feedback, and bounded diagnostics.
Community and verification
Language consent timestamps, source language, assignments, prompts, contribution text/media, review state, reviewer notes, and timestamps. Community verification records may include community affiliation, region, origin, lineage, badge/field visibility, reviewer eligibility, and review timestamps.
TODO — counsel/product: classify these fields, especially affiliation, origin, lineage, region, date of birth, voice/media contributions, and reviewer notes; decide whether additional notices or explicit consent are required.
Language contributions, voice, and progression
The reviewed backend branch also supports language-contribution text, translations, transcriptions, audio recordings, validation votes and revisions, assignments, corrections, reviewer notes, consent records, progression and trust ledgers, privacy requests, retention groups, and purge-work records. Related fields may include language and writing-system identifiers, contribution status, text role and content, audio storage reference, duration and size, validation scores/notes, consent document version and timestamp, retention scope, request/idempotency values, and progression or trust activity references.
Users may be able to withdraw language contributions and include language data in an account export. The branch documents separate text and voice choices for account deactivation or deletion, staged erasure, and export of language metadata and available voice media. The branch also documents a one-time recovery-key display with only an HMAC verifier stored. These statements describe reviewed backend behavior; they do not establish a legal retention period, anonymisation conclusion, client collection flow, or use of a speech or machine- learning provider.
Language contribution eligibility and training status
The reviewed backend has consent-gated candidate views for language text and voice records. Eligibility requires current lifecycle and validation conditions and a latest granted contribution document for the relevant text or voice scope. Consent records include a document key and version, scope, status, timestamps, and supersession information.
The reviewed repository does not contain a training-run, dataset-export, model-version, or source-to-model lineage record. It therefore cannot establish whether a particular contribution was copied into a training dataset or already incorporated into a trained model. Withdrawal and account deletion can redact or purge backend source records and configured media, but this draft makes no claim that data can be removed from an external dataset or trained model, and makes no promise of model untraining.
Language audit events are append-only in the reviewed database design. Account deletion can remove the actor-user association, while event subjects, metadata, and timestamps may remain. The retention period and any audit-retention exception require counsel, security, and product approval.
When selected language text or voice is retained during account deletion, the backend can return a recovery reference and one-time recovery key; only an HMAC verifier is stored. The reviewed code includes a service-level verification and purge function, but no user-facing recovery-purge route was evidenced. The post-deletion workflow and any external dataset/model handling remain unresolved.
3. How information is collected and used
Information may be supplied by the user during signup, profile/content creation, reports, feedback, community activities, and account controls; received from Apple or Google when social sign-in is used; generated by authentication, security, visibility, moderation, notification, messaging, call, live, export, and deletion operations; and received from device push-registration flows.
Technical purposes evidenced by the backend are to provide and secure the service, authenticate accounts, prevent abuse, enforce visibility and account standing, deliver notifications and email OTPs, host and deliver media, route messages/calls/live sessions, moderate/report content, operate community features, produce bounded product analytics/diagnostics, provide exports, and process deactivation/deletion.
TODO — counsel: map each purpose to the applicable legal basis, consent or withdrawal mechanism, legitimate-interest assessment where relevant, and any automated-decision/profiling disclosure.
4. Visibility and sharing
The product is authenticated by default. Public profile/content means visible to authenticated app users under the current backend contract; private profiles, audience controls, reciprocal blocks, and owner-only resources restrict access. Administrators with approved staff roles can access specific operational, moderation, report, analytics, or community-review surfaces.
Technical provider integrations include Azure infrastructure/storage/Key Vault/ email, PostgreSQL/Redis, Cloudflare, Apple/Google identity verification, APNs/FCM, LiveKit, and Microsoft Entra for staff authentication.
This is a technical dependency list, not an approved list of subprocessors or recipients. TODO — counsel/operations: confirm vendor names, legal roles, processing locations, international-transfer language, contracts, support access, and the final public subprocessor list.
5. Storage, security, and encryption
The code uses bcrypt password hashing, HMAC-derived OTP values, hashed refresh tokens, JWT expiry/rotation, rate limits, request-size limits, private media storage with short-lived access URLs, managed identity/Key Vault references in staging infrastructure, and non-root backend containers. Production runbooks direct operators not to log request bodies, authorization headers, message/call content, email, or user IDs.
These are implementation controls, not a guarantee that no provider, backup, administrator, or compromised endpoint can access data. TODO — counsel/security: approve the final security description, incident-notice process, and any certification or standards claim. No certification claim is made here.
6. Retention and deletion
The backend has configurable cleanup jobs. Current defaults include 30-day raw analytics retention, 90-day auth-event and closed-diagnostics retention, 30-day OTP-attempt/session and completed-delivery retention, 90-day failed delivery/invalid-push-token retention, 180-day read-notification retention, 24-hour unattached-media grace, 30-day soft-deleted-media/story retention, 72-hour ready-export retention, and a 15-minute export download URL. Account deactivation defaults to a 180-day deletion deadline, with 7/30/180-day choices.
These values are technical defaults, not the approved legal retention schedule. Deletion removes owned blobs before user deletion and removes or scrubs most account-linked records. The documented residual evidence is non-identifying analytics with a null user, scrubbed report outcomes, scrubbed administrator audit action/time, and an HMAC-only deleted-username reservation. Backups, provider copies, legal holds, safety exceptions, and deployed overrides require separate verification.
TODO — counsel/operations: approve retention by category, legal holds, backup and disaster-recovery treatment, provider deletion SLAs, safety/report exceptions, and the user-facing timeline.
7. Access, correction, export, and other requests
The current backend provides profile editing, privacy settings, session controls, deactivation/reactivation, permanent deletion, and a bounded private account export. The export includes account/profile, content, media, interactions, community data, encrypted-message metadata/share references, notification preferences, non-secret push-registration metadata, analytics, and sanitized security metadata; raw push tokens are excluded. On the reviewed language branch, the export also includes language contribution, translation, audio, correction, validation, progression, and trust data, plus available voice media.
TODO — counsel/product: define the general privacy-request intake, identity verification, correction/deletion/objection/portability workflow, exceptions, response timelines, appeals, regulator complaints, and whether additional rights are available in each market. No general legal-rights workflow is inferred from the technical export endpoint.
8. Children and age information
The Service is intended only for individuals age 13 or older. Individuals under 13 may not create or use an account. The backend requires date of birth and rejects signup below age 13. We do not knowingly collect personal information from children under 13. If we learn that we collected it, we will take appropriate steps to delete it.
TODO — counsel/product: approve this draft wording, the final age notice, and the operational process for identifying and deleting an under-13 account. This draft does not state that parental consent is supported or make broader child-law conclusions.
9. Cookies, SDKs, analytics, and transfers
TODO — product/operations/counsel: inventory cookies, mobile SDKs, crash and performance telemetry, analytics identifiers, opt-out controls, advertising (if any), automated profiling, cross-border transfers, and provider regions. This repository audit found bounded first-party analytics models but does not prove the complete client SDK or deployed network inventory.
10. Policy changes and approval record
TODO — counsel: define notice of changes, effective-date rules, acceptance history, withdrawal, locale precedence, and required re-consent. The policy must be published only from an approved version with a recorded version, effective date, locale, last review, and counsel approval. Draft files must remain excluded from the future static-site build. The backend review found no policy-version or policy-acceptance model in the reviewed user/auth schema; the final acceptance record and client-version history therefore remain unresolved.