Security Policy
Security practices and limitations grounded in Kronop's reviewed app flows, with production controls clearly identified for verification.
Kronop uses authenticated service calls and signed media-upload paths in the reviewed implementation. This policy does not claim end-to-end encryption, certified controls, or guaranteed deletion. Production access controls, encryption, monitoring, response ownership, and retention must be verified before making stronger promises.
What this policy covers
This page describes security-relevant behavior visible in the Kronop application and the controls expected to protect accounts and user information.
Source-code inspection does not establish the security posture of a production environment. Infrastructure configuration, database authorization, access operations, provider agreements, release signing, incident response, and independent testing require separate evidence.
- Security is a continuing process, not a feature or a guarantee.
- Controls can change as services, app releases, and providers change.
- Claims must be limited to controls the operator has verified.
Account and authentication
The app supports email code and password authentication and a Google OAuth path through Supabase Auth. Authentication tokens are persisted by the shared client using native AsyncStorage or browser local storage.
The reviewed code does not establish password complexity or reuse enforcement, multifactor authentication, a user-visible device/session inventory, session revocation behavior, or use of operating-system secure credential storage.
- Keep account credentials and one-time codes private.
- Use a unique password and secure the email account used to sign in.
- Sign out of devices you no longer control.
Authorization and service boundaries
The application accesses Supabase Auth, database, and realtime services and includes server routes backed by MongoDB and a storage-signing API. Server endpoints must validate identity and enforce authorization independently of client-side interface restrictions.
A user-scoped object key is constructed for signed uploads, and the signing service validates configured bucket names. This does not prove every database row policy, administrator endpoint, or deployed bucket setting is correct.
- Keep privileged credentials on trusted servers, not in app bundles.
- Apply least privilege to database, bucket, service, and administrator roles.
- Test that users cannot access other accounts' private records or uploads.
Transport and stored-data protection
The code communicates with configured service endpoints and uses signed URLs for selected media uploads. The exact TLS enforcement, certificate behavior, encryption at rest, key management, backup encryption, and database storage configuration are not proven by the client code.
Do not interpret an HTTPS URL or a cloud provider's general capabilities as proof that all Kronop data is encrypted in every place and form.
- The operator should verify transport enforcement for every API and media domain.
- Confirm encryption settings and key access for databases, storage, logs, and backups.
- Use a documented process for credential rotation and secret revocation.
Chat, live, and user content
Chat records include content and sender/recipient/status/timing fields in a configured backend. The reviewed client does not demonstrate end-to-end encryption or user-held message keys.
Live features use a Cloudflare RealtimeKit/WebRTC path in the source. Live sessions and user content may pass through infrastructure or become available to participants and service operators as configured. Exact media routing, recording, and retention behavior require production confirmation.
- Do not use chat as a channel for highly sensitive secrets.
- Assume that recipients can copy, record, or share material.
- Do not claim live sessions are never recorded without verifying app and provider settings.
Media upload and access
Selected upload flows request a signed URL through a server endpoint. The upload path can set metadata such as content type, cache control, and an object key associated with the authenticated account.
Other flows may use public URLs or feature-specific storage rules. Users should consider whether an image, video, story, report screenshot, or profile image is intended to be visible before upload.
- Review audience and destination before publishing.
- Do not assume deleting a post removes every copy or cache.
- The operator should audit access policies and object-lifecycle rules.
AI and model handling
The reviewed assistant path performs text inference locally using a downloaded model file stored in app document storage. The AI inference service in that path does not transmit conversation prompts to a Kronop model endpoint.
The model is obtained from a model-hosting endpoint. Voice recognition and speech output may use operating-system services. Device backups, diagnostics, or OS speech settings may affect data handling outside Kronop's direct control.
- Do not enter passwords, payment secrets, or highly sensitive personal information into the assistant.
- Review model download origin and integrity controls before release.
- Explain platform speech processing in the relevant device and third-party disclosures.
Permissions and privacy controls
The app requests or checks camera, microphone, media-library, foreground location, and notification permissions in selected feature paths. Permission state is also represented in a user-linked record.
A permission is intended to support its associated feature. Native manifest declarations can include additional capabilities, and the final runtime prompts and access must be validated in release builds on supported operating systems.
- Grant permissions only when you want the related feature.
- Revoke access in system settings when it is no longer needed.
- A device-level permission does not make content automatically public or private.
Monitoring and abuse prevention
The client supports user-submitted reports with a reason, description, content reference, optional screenshots, and a pending status. Moderation-related helpers are present.
The source does not establish production monitoring coverage, alerting, moderation staffing, investigation timelines, rate limits, security event logging, or a formal vulnerability disclosure program.
- Use the in-app reporting feature for harmful content or abusive conduct.
- Do not attempt to access, alter, or disrupt another user's account.
- The operator should restrict report access and audit administrative actions.
Retention and account deletion
The reviewed deletion function removes the authenticated Supabase user but does not visibly clean all related profile, content, chat, report, storage, notification, secondary database, or backup data.
A chat auto-delete preference and Story expiry value appear in the app, but the source does not establish a reliable server-side cleanup schedule. No general retention period should be inferred.
- Do not promise complete deletion until every system is tested.
- See the Account Deletion Policy for the currently observed deletion limitation.
- The operator should document backup expiration and legal holds.
Security incident response
If you suspect unauthorized access, secure the email account used for Kronop, change credentials where possible, revoke connected sessions if the service exposes that control, and contact Kronop through a verified channel.
The repository does not define an incident-response owner, public security contact, notification deadlines, or a responsible-disclosure safe-harbor. Those operational commitments must be established by the service operator before publication.
- Describe the issue, affected account or feature, and approximate time.
- Do not include passwords, one-time codes, private keys, or unnecessary personal data.
- Avoid publicly disclosing exploitable details before a coordinated response.
Responsible vulnerability reporting
Use the verified security or support contact shown on the official website to report suspected security weaknesses. No unverified email address or response-time guarantee should be relied upon.
Limit research to accounts and systems you own or have explicit permission to test. Do not access, download, alter, or expose another person's data, and stop if testing could affect service availability.
- Provide reproducible steps and non-sensitive evidence.
- Allow the operator a reasonable opportunity to assess the issue.
- Do not demand payment or threaten disclosure in exchange for withholding findings.
Verification and policy updates
Before this policy is treated as a final operational statement, BALYX should verify production access policies, encryption, secrets management, logging, provider terms, incident response, deletion coverage, and release permissions.
Security controls can change as the product evolves. Material changes should be reflected in this policy and the related Privacy, Data Safety, User Data, Third Party Services, and Account Deletion pages.
- Review after substantial app, backend, or provider changes.
- Keep evidence and an owner for each public security statement.
- Use the official Trust Center for the current policy version.
What you can do
- Choose a unique password and never share one-time codes.
- Limit permissions and avoid sending secrets in posts, AI prompts, or chat.
- Report suspected account compromise or vulnerabilities through the verified support contact.
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.