Third Party Services Policy
How external identity, database, storage, realtime, notification, model, and device services fit into Kronop's app flows.
The application source contains integrations with several external services, but code presence alone does not establish that a provider is enabled in a production release. This page separates implemented paths from deployment-dependent integrations and identifies disclosures that require operator verification.
What counts as a third-party service
A third-party service is a provider outside Kronop that supplies authentication, database, media storage, live communication, notifications, model delivery, device-level speech, or another feature dependency.
The application source includes service clients and configuration hooks. A dependency, environment variable, or unused integration does not prove that a specific provider receives user data in the production build.
- Some services receive data only when a user activates a related feature.
- The active provider and its configuration can differ by release or deployment.
- Provider terms and privacy practices are separate from Kronop's own policy commitments.
Authentication and database services
Supabase Auth is used by the shared sign-in client for email code, password, and Google OAuth flows. Session state is persisted on native devices in AsyncStorage and in browser local storage for web builds.
The app also uses Supabase database and realtime APIs for profile, social, chat, settings, notification, and content-related operations. A separate server code path uses MongoDB-backed routes, so the production routing and database-of-record for each feature must be confirmed.
- Sign-in data is sent to the authentication service selected by the deployment.
- Database services may receive account identifiers, user-submitted content, interactions, and settings needed for a feature.
- No complete deployment-specific processor list, region map, or retention schedule is present in the app code.
Media storage and delivery
Media upload code requests a signed URL from a Kronop storage-signing API and then sends media to a Cloudflare R2-compatible object-storage endpoint. The signing flow limits upload keys to the authenticated user's identifier and configured buckets in the server code.
The exact object access model varies by bucket and feature. Some code constructs a public URL for uploaded media; other access uses signed read URLs. The operator must verify bucket permissions, CDN behavior, deletion, backups, and production domains before describing media as private or public.
- Photos, videos, audio, profile images, group media, listing images, and report evidence can be stored through media flows.
- Signed URLs are temporary access capabilities and should not be shared publicly unless the content is intended to be public.
- A database deletion does not necessarily delete the associated object-storage file.
Live sessions and realtime communication
The live feature requests a session and participant token through a configured Kronop API and includes Cloudflare RealtimeKit and WebRTC dependencies for audio/video communication. Live requests may include a title, category, audience setting, and optional location.
The code does not establish the complete recording, relay, geographic routing, retention, or provider-side deletion behavior of a live session. The deployed service contract and provider settings must be reviewed before final publication.
- Camera and microphone permissions are required for relevant capture or live actions.
- Participants should not assume a live stream is recorded or not recorded unless the current UI clearly says so.
- Do not broadcast another person's image or voice without appropriate consent.
Push notifications
The application has an in-app notification list and API routes for registering push tokens or OneSignal player identifiers. Notification records can include a title, body, type, status, route, content identifier, data, and timestamp.
The code contains a mock send path and OneSignal-related provider configuration. Whether OneSignal or an operating-system push gateway is active, and which notification data is sent externally, depends on production deployment settings.
- A push token or player identifier can identify a device for notification delivery.
- Notification content may be visible on a lock screen according to device settings.
- Use in-app and system controls to disable notifications or message previews where available.
Google, Apple, and identity providers
A Google OAuth sign-in path is implemented through Supabase Auth and an external browser flow. When used, Google may process sign-in requests and identity data according to its own terms.
An Apple-branded login screen is present, but the reviewed app service does not establish a complete Apple identity-provider exchange. Do not describe Apple as an active provider until the release flow is verified.
- External sign-in is optional where the current build provides another supported method.
- The identity provider can return an identifier and basic profile attributes needed for sign-in.
- Manage provider account settings directly with that provider.
On-device AI and model hosting
The AI assistant currently calls a local model runtime for response generation. The model file is downloaded from a Hugging Face model-hosting URL and stored in app document storage. Conversation text in the reviewed AI service is passed to the local model rather than a Kronop AI API.
A model host can receive ordinary network connection information when the file is downloaded. No model-hosting agreement, retention details, or release verification has been established by the app code.
- Model download is separate from sending an AI prompt to a remote inference service.
- Voice recognition and text-to-speech can use operating-system services whose data practices depend on device configuration.
- Avoid including sensitive information in AI prompts or voice input.
Services present only as dependencies or configuration
The project dependency set includes libraries for Stripe, Firebase, analytics-adjacent platform capabilities, and other services. The reviewed code search did not identify Stripe payment calls or Firebase Analytics/Crashlytics event calls. Dependency presence alone is not evidence that Kronop currently charges users or sends analytics to those services.
Before launch, the operator should review native manifests, build plugins, remote configuration, server environment variables, and generated release binaries for integrations that may run without an obvious application call.
- This policy does not claim that a provider is active merely because its package is installed.
- If payments, analytics, crash reporting, or ads are enabled later, update the relevant disclosures first.
- Keep public privacy statements aligned with the actual release artifact and server configuration.
Provider instructions and data rights
External services process information under their own contracts and policies while providing functions to Kronop. The app repository does not provide a full list of sub-processors, legal transfer mechanisms, service locations, or provider deletion timelines.
Requests about Kronop's use of data should go to the verified privacy contact. Requests that concern an external provider account may also need to be sent directly to that provider.
- A request to delete a Kronop account does not automatically establish provider-side erasure.
- Kronop should relay deletion or access instructions to providers where required by its contracts and applicable law.
- Users should avoid sharing provider credentials with Kronop support.
Security and international processing
Third-party routing can involve data processing outside a user's country. Exact hosting regions, transfers, contractual safeguards, and provider access controls depend on production configuration and are not established by the client source.
Kronop should assess provider security, access management, incident notification, retention, and data-subject request support before enabling an integration for general use.
- Do not interpret a signed URL as proof of a complete security or privacy guarantee.
- Provider access should be limited to the task the service performs.
- Publish verified transfer and hosting details where required by applicable law.
Changes to integrations
Kronop may change providers or add a service when a feature, release, or operational need changes. Material changes to personal-data processing require updated disclosures and any notice or consent required by law.
This policy is a code-based draft. The production owner must confirm each active provider, purpose, data category, region, retention period, and deletion path against release and infrastructure settings.
- Review the policy before adding an SDK or enabling a server integration.
- Record a provider inventory and owner for each integration.
- Do not rely on this page as a statement of a provider's independent terms.
What you can do
- Review the service categories used by features you choose to access.
- Check the provider's own privacy terms when you use an external sign-in or device service.
- Contact Kronop through a verified route about production providers or data handling.
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.