Privacy Policy
What information Kronop's app features use, how it moves through the service, and which privacy details still require production verification.
This product-specific draft is based on the current application source. It describes observed account, profile, content, chat, report, permission, notification, and AI flows without treating code presence as proof of a production deployment, retention period, or complete deletion outcome.
Who this policy covers
This policy describes personal information processed through Kronop's mobile application and associated services. It applies when you create an account, complete a profile, upload or view content, message another user, submit a report, enable notifications, or use other app features.
The app source contains more than one server and data-service path. BALYX must verify which paths and providers are active for each released app before making this a final production statement.
- The product includes social profiles, media, chat, live, groups, marketplace, and AI features.
- Some data is provided by you, some is generated by your use, and some is read from device permissions.
- A screen or code path is not proof that a field is successfully stored in every deployment.
Account and sign-in information
The application includes email one-time-code and password sign-in flows through the configured authentication client. It also contains a Google OAuth path. An Apple-branded sign-in screen exists, but the complete Apple provider exchange is not established by the reviewed service code.
Account records can include an authentication identifier and email address. Authentication sessions are persisted by the client in native AsyncStorage or browser local storage, depending on platform.
- Do not share passwords, one-time codes, tokens, or recovery links with anyone.
- Identity-provider data is processed according to the sign-in option you choose.
- The exact session lifetime and storage protection must be verified against production settings.
Profile and onboarding information
Profile features use identifiers, username, display name, biography, profile image, cover image, optional social links, and profile counts such as posts, supporters, or supporting. The app also has an onboarding form for phone number, date of birth, gender, address, country, and a profile image.
The onboarding code attempts to send these details to a profile endpoint. Its request path does not establish that every value is successfully authenticated and stored in production. A date-of-birth field is present, but an age-eligibility check is not established by the reviewed implementation.
- Provide only information you are comfortable associating with your profile.
- Review a profile's visibility before adding identifying or sensitive details.
- The operator must confirm which fields are required and how they are used.
Content, media, and location labels
Kronop includes user-created photos, videos, Reels, Stories, live streams, music or audio, notes, questions and answers, group content, and marketplace listings. Depending on the feature, an item can include text, media, a title, category, tags, author identifier, media URL, thumbnail, location label, timestamps, and interaction counts.
Uploads request time-limited storage URLs from a configured service and send media to object storage. Some flows construct public media URLs; not every bucket's access configuration is visible in the app code. Treat content visibility as dependent on the selected feature and current audience controls.
- Content may reveal faces, voices, surroundings, or information about other people.
- Some upload forms accept a location entered by the user.
- Stories include expiry metadata in the reviewed implementation, but metadata does not prove every file copy is erased.
Interactions and social graph
App features record or query relationships and actions such as support/follow relationships, likes, comments, shares, saves or stars, views, and other content interactions. These records can associate your account identifier with another account or a specific item.
Profiles and feeds use these records to show counts, engagement, and interaction state. The app repository does not provide a complete analytics inventory or a verified retention schedule for interaction records.
- A relationship can reveal which accounts you interact with or support.
- Counts may be calculated from underlying relationship or content records.
- Removing an action in the app does not establish deletion from backups or derived systems.
Direct messages and chat settings
Direct messaging supports text and message types including image, video, audio, and file. The chat service writes sender and recipient identifiers, message content and type, delivery state, creation time, and read time to the configured database and subscribes to realtime updates.
Chat settings include online status, last-seen visibility, read receipts, typing indicators, notification previews, auto-delete, screenshot alerts, and ghost mode. The code does not demonstrate end-to-end encryption or prove that every preference is enforced across all surfaces.
- The reviewed client sends message content to a service database.
- An auto-delete preference exists, but a complete scheduled erasure mechanism is not established.
- Recipients may retain copies, screenshots, or notification previews outside Kronop.
Device permissions and location
The permission screen checks camera, microphone, photo/media library, foreground location, and notification access. For a signed-in account, it writes boolean permission status values to a device-permissions record.
Onboarding can request foreground location, obtain coordinates, reverse-geocode an address, and place address and country into a form. The reviewed app does not establish continuous background location tracking. Device permission declarations in native project files do not alone prove runtime collection.
- Camera and microphone support capture and live functions where enabled.
- Photo access supports selecting media to upload.
- Revoke access in operating-system settings; the app may refresh its recorded status when reopened.
Reports and moderation records
The report flow can create a record containing the reporter and reported account identifiers, report type, content type and URL, reason, description, status, and timestamps. The client service counts reports by month and can limit submissions.
A report may include up to two screenshot uploads to a configured report bucket. The record begins with a pending status. The implementation includes helpers to retrieve and update moderation records but does not define who reviews them, how long evidence is retained, or an appeal deadline.
- Report text and screenshots can contain sensitive information about multiple people.
- Include only relevant evidence and do not send passwords or access tokens.
- Do not infer a particular moderation outcome or response time from submission.
Notifications and device identifiers
In-app notifications can contain a title, body, type, status, route or content identifier, data, and creation timestamp. The code includes registration paths for push tokens and OneSignal player identifiers tied to an account.
The repository also contains a mocked notification send route and provider configuration. The active production provider and exact fields sent to it must be verified for each release.
- Push identifiers can be used to address a device for delivery.
- Notification previews can reveal message content on a device lock screen.
- Use operating-system and app settings to control notification access and previews.
AI assistant and voice
The reviewed AI service generates text responses with a local model runtime on the device. It downloads a model file from a model-hosting endpoint and stores the file in app document storage. The service passes a limited recent conversation history to local generation and does not call a Kronop AI inference API in the reviewed path.
Voice input can invoke operating-system speech recognition, and spoken answers can use the device speech API. The operating-system provider's processing of voice data depends on device settings and is outside what the app source can establish.
- Avoid entering sensitive or confidential information in prompts or voice input.
- A model download can expose ordinary connection metadata to the model host.
- The reviewed AI chat state is maintained in client memory rather than shown as a saved server conversation.
Purposes and feature operation
The code uses account and profile information to authenticate users and display profiles; content and interaction data to create feeds and social functions; chat data to deliver messages; permission status to display device access choices; and report data to submit and review safety or rights concerns.
Other purposes, legal bases, recommendation systems, advertising, analytics, personalization, fraud detection, or product measurement must be verified against production configuration. A package dependency is not sufficient evidence that a purpose is active.
- Information should be limited to what is needed for a requested feature and legitimate service operation.
- Do not use information for an undisclosed purpose without an appropriate legal basis and notice.
- Update this section whenever a new processing purpose is enabled.
Service providers and disclosures
The app source shows Supabase authentication, database, and realtime use; Cloudflare R2-compatible signed media storage; a Cloudflare RealtimeKit/WebRTC live path; MongoDB-backed server routes; OneSignal-related notification configuration; Google OAuth; a model-hosting download; and device speech services.
These are observed code paths or configuration hooks, not a confirmed list of production processors. The service owner must identify which providers are active, what data each receives, where it is processed, and how contractual and regional obligations are met.
- Providers may process information under their own service terms.
- The app repository does not establish the complete subprocessor list or hosting regions.
- See the Third Party Services Policy for provider-specific implementation notes.
Retention and account deletion
The account-deletion function verifies the signed-in Supabase user and deletes that authentication identity. It does not visibly remove profile rows, chat messages, reports, media objects, notifications, separate database records, backups, or other provider copies.
A 24-hour expiry field appears in some Story upload paths, but a full object deletion job is not established. Retention periods for other content and records cannot be reliably stated from the reviewed source.
- Use the Account Deletion Policy for the limitations of the present in-app flow.
- Uninstalling the app is not an account deletion request.
- BALYX must publish verified retention schedules and data cleanup behavior before promising complete erasure.
Your privacy choices and requests
Available controls include profile editing, private-account and block controls, chat settings, device permissions, notification settings, report forms, and an in-app account-deletion action. The availability and effect of each control may vary by build.
The reviewed website and app source do not establish a complete web-based access, correction, export, objection, or deletion request workflow. A verified privacy contact and region-specific rights instructions must be published by BALYX.
- Use the in-app setting that corresponds to the choice you want to make.
- For a privacy request, use only the contact route verified on the official Trust Center.
- Do not send passwords, codes, or authentication tokens as identity proof.
Children, regions, and policy administration
The app collects a date-of-birth value in onboarding, but the reviewed code does not establish an age-gate, parental-consent workflow, or child-safety enforcement process. The applicable minimum age and treatment of minors must be determined from product design and governing law before release.
The responsible legal entity, governing jurisdiction, processing locations, international transfer mechanisms, policy contact, effective date, and region-specific rights cannot be inferred from client code. BALYX must insert verified details and obtain qualified legal review before publication.
- Do not provide a false age or another person's identifying information.
- Contact the verified support route if you believe a child has supplied data inappropriately.
- Material privacy changes should be disclosed before they take effect where required.
What you can do
- Review the data categories associated with features you choose to use.
- Use in-app privacy controls and grant device permissions only when needed.
- Use the verified privacy contact for access, correction, or deletion 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.