Data Safety Policy
A practical account of the data paths and safeguards represented in the Kronop app, without implying controls the code does not prove.
This draft maps visible data handling to app features and distinguishes implemented safeguards from security, retention, and incident-response claims that require production verification. It should be checked against the released app, databases, storage, provider contracts, and operating procedures.
Purpose and safety scope
This policy explains how account, profile, content, chat, report, permission, notification, and media-storage data appears to move through Kronop's current app implementation.
A source review is not a security audit of production infrastructure. The policy does not claim encryption at rest, end-to-end encryption, a certification, a retention schedule, or an incident-response service unless those facts are verified by the service owner.
- Data safety depends on both application behavior and provider configuration.
- A security setting in the interface is not proof of an underlying technical control.
- Production claims must match the actual database policies, deployment, and release build.
Data categories represented in the app
The code handles authentication identifiers, email, profile fields, user-submitted media and text, social interactions, chat messages, reports and screenshots, permission states, notification records, push identifiers, and selected feature metadata.
Onboarding requests username, phone number, date of birth, gender, address, country, and a profile image. A request in client code does not prove successful persistence in the production backend.
- Limit information to what the selected feature needs.
- Do not place passwords, one-time codes, recovery links, or private keys in ordinary content.
- Refer to the User Data Policy for the feature-by-feature inventory.
Authentication and session handling
The shared client uses Supabase Auth for email code, password, and Google OAuth flows. Session persistence uses AsyncStorage on native platforms and local storage on web.
The exact token lifetime, device encryption, identity-provider settings, and access-control policies are configuration-dependent. The app source alone does not establish whether sessions are protected by platform secure storage.
- Use a secure device lock and keep the operating system updated.
- Do not sign in on devices you do not trust.
- Sign out after using a shared device and report suspicious sessions using the verified contact.
Data transmission and backend services
The client communicates with authentication, database, realtime, media-signing, and live-session services. The codebase includes Supabase, MongoDB-backed API routes, and a Python storage-signing API, indicating more than one backend path.
The production service topology, network termination, API logging, access review, encryption configuration, and data residency must be verified. This policy does not infer those controls from the presence of an HTTPS URL or a provider library.
- Keep server-only credentials out of mobile builds and public client configuration.
- Restrict production access to authenticated and authorized roles.
- Document the service that is authoritative for each account and content record.
Media storage and signed access
Upload code obtains time-limited signed URLs through an authenticated storage-signing endpoint. The signing service validates configured bucket names and scopes upload object keys to the authenticated user identifier.
Some feature flows return or construct public media URLs. A signed URL, user-scoped key, or configured bucket is a security measure in a code path, not a guarantee that all media is private or that storage is correctly configured in production.
- Do not share a signed URL as though it were a permanent access-controlled link.
- Review whether the content should be public before uploading it.
- Test access revocation, object deletion, and bucket policy independently of database deletion.
Chat and message safety
The chat service stores message content and media type alongside sender, recipient, status, and timestamps in the configured database and supports realtime message subscriptions.
The reviewed client service does not show an end-to-end encryption protocol. A dependency related to signal protocols or an encrypted column type is not proof that all messages are encrypted before leaving a device or that keys are managed securely.
- Do not treat direct messages as secret or legally privileged communications.
- Avoid sending credentials, financial account numbers, or other highly sensitive secrets.
- Recipients may save or capture messages outside Kronop's control.
Device permissions and privacy choices
Kronop's permission screen checks camera, microphone, photos/media, foreground location, and notifications. It stores permission status as boolean fields for signed-in users. Device settings remain the source of the operating-system permission grant.
Onboarding can use current coordinates to reverse-geocode an address. The reviewed code does not establish continuous background location tracking. Native manifests may declare additional permissions that are not shown as actively requested in the reviewed screens.
- Deny permissions that are not needed for a feature you want to use.
- Revoke a permission in system settings if your choice changes.
- Review content and location labels before publishing them.
Reports and evidence handling
A report can contain account identifiers, reason, description, a content URL, timestamps, status, and up to two screenshot references. Screenshots are uploaded to a configured report storage bucket through a signed media flow.
The application initializes report status as pending and contains client helpers to list reports and update status. The code does not establish moderation staffing, authorization boundaries for administrative actions, review deadlines, evidence retention, or appeal procedures.
- Include only the evidence needed to explain the concern.
- Do not upload unrelated private conversations or another person's credentials.
- The operator should audit access to report records and evidence in production.
AI model and speech processing
The AI assistant runs local inference using a downloaded model file stored in app document storage. Conversation text in the reviewed response path is supplied to the on-device model and is not sent to a Kronop inference endpoint by that service.
The model file is fetched from a model-hosting URL. Voice input may use operating-system speech recognition and spoken output can use the platform speech API, whose network behavior depends on device configuration.
- Do not enter high-risk personal data into voice or AI features.
- Users can delete app data or uninstall the app to remove app-local files, subject to operating-system behavior.
- The code does not establish the host's connection-log retention or the platform speech provider's processing.
Third parties and provider controls
The code includes Supabase, Cloudflare R2 and RealtimeKit/WebRTC, MongoDB-backed routes, OneSignal-related notification configuration, Google OAuth, and model-hosting flows. Some other provider libraries are dependencies without an observed runtime use in the reviewed source.
The actual production provider list, processing regions, security terms, subprocessors, and incident-notice commitments must be recorded by the operator. Users should consult the Third Party Services Policy for the distinction between code presence and active deployment.
- Do not publish a provider as active based only on package installation.
- Review provider access, retention, deletion, and breach-notification clauses.
- Update the Trust Center whenever a provider or purpose is enabled or removed.
Deletion, expiry, and retention
The account-deletion function removes the authenticated Supabase user identity but does not visibly clean all associated content, messages, reports, storage objects, separate database records, or backups. A Story upload includes a 24-hour expiry field, but an expiry field is not a verified deletion job.
The chat settings table includes an auto-delete preference, but the reviewed service does not establish a reliable scheduled purge. Retention and backup periods for other data are unknown from the app source.
- Do not promise complete erasure or fixed timeframes without production verification.
- Document deletion behavior for every database, storage provider, cache, and backup.
- Use the Account Deletion Policy for the current user-facing limitations.
Incident reporting and response
The security page should provide an operational route for reporting suspected account compromise or technical vulnerabilities. The app code does not establish a formal security disclosure program, incident hotline, response deadline, or breach-notification procedure.
BALYX must set an incident owner, escalation criteria, evidence handling rules, regulator/user notification procedures, and provider coordination before making public response commitments.
- Report suspected unauthorized access promptly through the verified support route.
- Do not test a suspected vulnerability against another person's account or data.
- Preserve relevant facts without publishing credentials or exploitable details publicly.
Publication and assurance limits
This policy is a detailed product-based draft, not an independent audit, penetration test, certification, or guarantee that all data is encrypted or deleted.
Before final publication, confirm production access controls, logs, backup schedules, encryption in transit and at rest, data centers, staff access, secrets handling, app-store declarations, and the exact incident and deletion processes.
- Only make security claims that have current evidence and an accountable owner.
- Re-review after significant releases or changes to the backend or provider set.
- Use a verified contact for security reports and formal privacy requests.
What you can do
- Use device permissions only for features you choose to access.
- Protect your credentials and avoid sharing sensitive information in public content.
- Report suspected account compromise through a verified Kronop support route.
Need help?
If this page does not answer your question, visit the Help Center or contact Support. For a safety concern, use the reporting route that best matches the issue.