User Data Policy
A feature-by-feature guide to the account, profile, content, interaction, and device information used by Kronop.
This inventory describes data visible in Kronop's current application code and explains the distinction between an implemented data path and a production retention or deletion commitment. It complements the Privacy Policy and must be checked against live services before publication.
How to read this inventory
The categories below are based on fields and data operations present in the Kronop application source. A field appearing in a screen, request, or database query does not by itself prove that a production server successfully stores it, how long a provider keeps it, or whether every release uses that code path.
The privacy contact, applicable legal entity, processing locations, retention schedules, and regional rights workflow have not been established by the reviewed application implementation. BALYX must verify these facts against the deployed service configuration before treating this inventory as final.
- “Collected” means a feature asks for, creates, or transmits the information in a code path.
- “Stored” means the code writes to a local store, database, or object-storage flow; it does not prove a production retention period.
- Optional features can involve additional information only when a person uses or grants access to them.
Account, sign-in, and recovery data
The sign-in implementation supports email-based one-time-code flows and password authentication through the configured authentication service. The code also includes a Google OAuth path. The app presents an Apple-branded sign-in screen, but a complete Apple identity-provider exchange is not established by the reviewed sign-in service.
Authentication sessions are persisted by the shared client using device AsyncStorage on native platforms and browser local storage on web. The exact token lifetime, refresh policy, device-level protection, and production identity-provider configuration must be verified with the service operator.
- Sign-in identifiers can include an email address and the account's authentication identifier.
- Password and one-time-code handling is performed through authentication flows; never send credentials to support.
- Google identity information may be received when the Google sign-in flow is enabled and used.
Profile and onboarding information
Profile screens and services use a username, display name, biography, avatar or profile image, cover image, optional social links, and profile identifiers. Profile views may also show supporter, supporting, and post counts.
The onboarding screen asks for a username, phone number, date of birth, gender selection, address, country, and profile image. It can request foreground location to fill an address. Its request path does not establish successful authenticated persistence in every deployment, so the production fields and required/optional status must be confirmed.
- Do not assume that a date of birth entry is an age check; a minimum-age gate is not established by this code review.
- A profile image selected from the photo library is used as profile media if the upload flow completes.
- The user controls what profile details they choose to provide, subject to the app's current required-field validation.
Content and media
Kronop includes creation or display paths for photos, videos, Reels, Stories, live streams, music or audio, notes, questions and answers, group material, and marketplace listings. A content item can be associated with its author, media URL, thumbnail, title or caption, category, tags, timestamps, and interaction counts, depending on the feature.
Uploads use signed storage requests and separate media buckets for content types. The storage service receives an authenticated request for a time-limited URL; the media bytes then travel to the configured object-storage endpoint. Public media URLs are also constructed by some feature flows. The public/private status and access rules for every bucket require deployment verification.
- A photo or video can contain people, voices, locations, or other personal information supplied by the creator.
- Some upload forms accept a location label; this is user-entered content and is distinct from device GPS.
- Stories include an expiry timestamp in the upload and query paths, including a 24-hour value in the reviewed upload implementation; actual object deletion is not proven by metadata alone.
Interactions and social relationships
The application records social actions such as follows or support relationships, likes, comments, shares, saves or stars, views, and content interactions. These records can identify the acting account, the affected account or content, the action, and a time or counter.
Content feeds and profile pages query these records to show interaction state and aggregate counts. The exact event logging, analytics use, and retention of each interaction are not fully described in the client implementation.
- A supporter relationship can reveal an association between two account identifiers.
- Views and engagement counts are used by the app's visible content and profile functions.
- Removing an interaction in the interface does not by itself establish deletion from backups or derived counts.
Messages and chat settings
Direct chat supports text and message types including image, video, audio, and file. Message records include sender and recipient identifiers, content, type, status, creation time, and read time; conversations use realtime subscriptions.
Chat settings are written to a Supabase table and include online/last-seen visibility, read receipts, typing indicators, notification previews, auto-delete, screenshot alerts, and ghost mode. The setting names and UI do not prove end-to-end encryption, screenshot prevention, or automatic deletion of every message.
- The client sends message content to the configured chat database; the reviewed code does not demonstrate end-to-end encryption.
- An “auto-delete” preference exists, but a complete scheduled message-erasure process and its retention period are not established.
- Chat participants may retain copies, screenshots, or notifications outside Kronop's control.
Reports and safety information
A signed-in person can submit a user or content report. A report record can include reporter and reported account identifiers, report type, content type and URL, reason, description, status, and timestamps. The application limits submissions by a monthly count in the report service.
The report flow can upload up to two screenshots to the configured report storage bucket and store their URLs with the report. Report records begin with a pending status. The code exposes moderation query and status-update helpers, but does not establish staffing, review deadlines, final outcomes, or retention.
- Report descriptions and screenshots can include sensitive information about the reporter or other people.
- Use the report form only for genuine safety, rights, or policy concerns.
- Do not include passwords, payment credentials, or unrelated private records in evidence.
Device permission status and location
The device-permissions screen checks camera, microphone, photo-library, foreground-location, and notification permission status. For a signed-in user, it writes boolean permission states to a device-permissions record associated with the account.
The onboarding location action requests foreground location, obtains coordinates, reverse-geocodes an address, and places address and country values in the profile form. Marketplace and other content forms may also accept a location label. A stored permission status is not the same as a history of precise location coordinates.
- Camera and microphone are presented for media capture and live features.
- Photo access is presented for selecting media to upload.
- Location is optional in the reviewed onboarding and permission interface; turn it off in system settings to revoke access.
Notifications and device identifiers
The application has an in-app notification list with title, body, type, status, route or content identifier, data, and creation time. The notification service queries a notifications table and can mark an item as read.
Backend routes accept a push token or a OneSignal player identifier and associate it with an account. The project contains both a mock notification-sending path and OneSignal-related configuration; which delivery provider is live must be confirmed for the production build.
- A push token or provider identifier can be used to address a device for notifications.
- Notification text and routing data may reveal information on a lock screen if previews are enabled.
- The app includes a message-preview preference; device operating-system notification settings also apply.
AI, voice, and locally stored model data
The AI assistant's reviewed service passes the current conversation text to a local model runtime on the device. The model file is downloaded from a model-hosting service and stored in the app's document directory; the local completion code retains a short, in-memory conversation window for generation.
Voice input can use the device speech-recognition module, and spoken responses use the device speech API. The operating-system provider's handling of voice data depends on device and platform settings and is not documented by the app source.
- The reviewed AI response path does not send conversation text to a Kronop AI server.
- Model download requests are made to the configured model-hosting URL; the host may process ordinary connection metadata.
- The app's local chat state is not shown being persisted as a server conversation in this AI path.
Storage systems and service providers
The codebase contains Supabase Auth, database, and realtime use; Cloudflare R2 signed media-storage flows; and a Cloudflare RealtimeKit/WebRTC live-video integration. It also contains MongoDB-backed server routes and notification-related provider configuration. This mixed implementation does not prove which services or database paths are active in a release.
Google sign-in is implemented through an OAuth path. OneSignal registration is represented in the API; live delivery and exact provider settings are deployment-dependent. Local AI model delivery uses a model-hosting endpoint. See the Third Party Services Policy for the verified scope and open review items.
- A service name in source code or a package manifest is not by itself proof that a release transmits data to that service.
- The operator must publish the actual production processors, service locations, and transfer safeguards.
- No complete processor list or data-processing agreement inventory is present in the reviewed app code.
Retention, access, and deletion
The application source shows an account-deletion action that calls a Supabase function to delete the authenticated Supabase user. The function does not visibly enumerate profile rows, messages, reports, content records, object-storage files, MongoDB records, notification tokens, backups, or analytics records for cleanup.
Only an explicit expiry field is visible for some Stories. A configured auto-delete chat preference is not proof of a working purge. Outside those limited code paths, the reviewed implementation does not establish retention periods or deletion completion times.
- Do not interpret account deletion as a verified complete erasure of every related record.
- Retention exceptions for legal claims, security, backups, or provider records need an operator-approved schedule.
- Access, export, correction, and deletion request handling must be confirmed and connected to a working privacy contact.
Review and publication requirements
This policy is an implementation-based inventory, not a substitute for a production data map. Before publication, the service owner should compare every item with live API configuration, database schemas and policies, provider contracts, production SDKs, logs, backups, and release-specific permission behavior.
The final version should identify the responsible legal entity, contact route, effective date, countries or regions served, retention periods, user-rights process, and any data processed about children. Those facts cannot safely be inferred from the client repository.
- Review this inventory whenever a new SDK, permission, content type, or backend provider is enabled.
- Keep store disclosures consistent with the actual release and this policy.
- Route questions through the verified Privacy contact once BALYX publishes that channel.
What you can do
- Review the data categories associated with the features you use.
- Use in-app controls or the verified privacy contact to make a request.
- Do not include passwords, access tokens, or private credentials in support requests.
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.