Cookie Policy
How Kronop app sessions and similar local technologies are represented in the current implementation, and what still needs production verification.
The reviewed mobile app persists authentication sessions in native AsyncStorage, while a web client uses browser local storage. These mechanisms are not browser cookies. No app analytics or advertising-cookie runtime was established in the reviewed source; the final release and any associated website must be checked separately.
Scope and terminology
This policy concerns cookies and similar technologies associated with Kronop app access. Cookies are small values stored by a browser and sent with requests; mobile app storage mechanisms such as AsyncStorage are not cookies, even when they preserve a session.
The app repository contains a native client and web-compatible authentication storage. Production websites, embedded browsers, identity-provider redirects, and third-party SDK behavior may differ by release and domain.
- Do not treat all local storage as a browser cookie.
- A third-party service may use its own cookies on a provider page.
- The website operator must inventory each first- and third-party technology on the deployed domain.
Session storage in the app
The shared authentication client stores native session state using AsyncStorage and uses browser local storage for web builds. This supports persistence of authentication between app visits.
The reviewed implementation does not use a dedicated secure-storage adapter for the shared native auth session. The exact exposure, encryption, access protections, and session lifetime depend on the operating system and configuration and must be assessed before security claims are made.
- Signing out should end the current session where the service accepts the request.
- Removing app data or uninstalling may clear local session material according to platform behavior.
- Do not use a shared or unlocked device for a sensitive account.
Preferences and app-local state
The app also uses local storage for selected interface or settings state. An example settings screen writes preference toggles to AsyncStorage. Local preferences can be different from records stored in a service database.
The app uses a browser local-storage path for web authentication and may rely on platform storage for other modules. The source review does not identify a complete list of every key, cache, or embedded web view.
- Local preference values may remain on a device until the app or user removes them.
- A local setting is not automatically synchronized across devices unless a service flow does so.
- Review platform privacy settings before granting device access.
Cookies and analytics findings
The reviewed app source does not establish a conventional app cookie banner or a production web-cookie inventory. Code search did not identify runtime analytics event calls or an advertising pixel in the reviewed app paths.
These are limits of a source inspection, not a guarantee that the final release, server, store wrapper, operating system, or production website uses no cookies or analytics. The deployed app and domain must be tested with network inspection and provider configuration.
- A library dependency alone is not proof that a cookie or tracking event is active.
- Do not tell users that tracking is absent until production behavior is confirmed.
- If optional analytics or ads are enabled, identify the purpose and obtain choices where required.
Identity and external provider pages
Google OAuth can open an external browser-based sign-in flow. The identity provider may use cookies or similar storage on its own domain to authenticate a user and protect the login.
Kronop does not control the provider's cookies on the provider's own domain. Users should review the provider's own privacy and cookie information when completing external sign-in.
- External sign-in is initiated only when a user chooses that option.
- The app receives identity/session information needed to complete sign-in.
- An Apple-branded screen is present, but an active Apple provider flow requires verification.
Third-party feature SDKs
The app code includes modules for authentication, database, object storage, realtime live media, notifications, device speech, and model download. Each provider may maintain local identifiers, web storage, network logs, or other technologies according to its implementation.
The active production provider set and tracking behavior are not determined solely by source dependencies. The operator should test a released build, inspect web domains, and review provider SDK documentation and privacy settings.
- See the Third Party Services Policy for provider categories and deployment caveats.
- Keep the provider inventory tied to actual release versions.
- Do not enable optional tracking before disclosures and consent controls are ready.
Advertising and consent
No ad-network tracking or advertising SDK use was established in the reviewed Kronop mobile app source. The separate policy website has its own advertising configuration and disclosures; those must not be confused with app behavior.
If Kronop later enables app advertising, measurement, or personalization, it must identify identifiers and technologies used, explain choices, implement legally required consent, and update store disclosures before release.
- Do not assume that a mock ad preview is a live advertisement.
- A permission grant is not equivalent to consent for unrelated tracking.
- Allow users to change optional consent choices where required.
Managing stored data
Users can sign out, revoke operating-system permissions, clear app storage or browser storage, and remove the app. These actions affect local device state and do not necessarily delete server-side account or content records.
The app's account deletion function currently demonstrates deletion of an authentication identity but not full cleanup of all remote records. See the Account Deletion Policy for details.
- Use in-app account deletion to initiate the account action.
- Use browser settings to clear local storage for an applicable web origin.
- Do not mistake clearing local storage for deleting a server account.
Retention and changes
Local storage duration is controlled by app behavior and device or browser settings. The source does not provide a complete expiration schedule for session keys, preferences, caches, or provider-side cookie values.
This page must be revisited when a cookie banner, analytics system, advertising SDK, embedded browser, or web property is added or changed.
- Publish a cookie table when technologies are confirmed in production.
- Include the provider, purpose, category, duration, and opt-out mechanism for each item.
- Update the effective date and communicate material changes appropriately.
Questions and review items
The app code cannot identify every production cookie, vendor domain, or retention period. The final policy owner should maintain a domain and SDK inventory and confirm it against production traffic.
The responsible legal entity, privacy contact, hosting region, consent rules, and any regional exemptions require confirmation from BALYX and qualified privacy counsel.
- Use the verified privacy contact for questions about technologies.
- Review the deployed application as well as the repository before publication.
- Do not represent this code-based draft as a complete cookie scan.
How consent and essential storage should be handled
Authentication storage is necessary for a user to remain signed in, but that does not make every storage technology automatically essential in every jurisdiction. The operator should classify each technology by purpose and apply applicable consent rules.
Where a website uses optional analytics or advertising cookies, it should provide a clear choice before non-essential tracking begins when required by law. A settings control should remain accessible so users can revisit that choice.
- Do not bundle optional measurement with essential authentication storage.
- Store consent choices in a way that can be audited and changed.
- Honor applicable browser privacy signals and regional requirements.
What you can do
- Use device or browser controls to manage stored app data and sessions.
- Sign out on shared devices and avoid sharing authentication links.
- Review this policy if a web app, analytics SDK, or advertising technology is enabled.
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.