Account Deletion Policy
What the current in-app account deletion flow does, what it cannot yet confirm, and how deletion requests should be handled.
Kronop's app includes an authenticated account deletion action. The reviewed implementation deletes the authentication user through a Supabase function, but does not demonstrate a complete purge of associated profile, content, chat, reports, or stored media. This page states that limitation rather than promising unverified deletion.
Purpose and scope
This policy explains the account deletion flow visible in the Kronop application and separates the operation shown in code from the wider erasure outcome a person may reasonably expect.
Deletion is different from logging out, uninstalling Kronop, making a profile private, blocking another account, or removing an individual post. Those actions do not, by themselves, delete the account or all data associated with it.
- Account deletion is intended to stop the account from being used after the operation succeeds.
- The in-app screen presents the action as permanent and asks the user to confirm.
- A successful authentication-user deletion is not evidence that every copy or related record is erased.
Where to start in the app
The app presents a Delete Account screen from its account menu. The screen identifies the signed-in account and asks the user to confirm before invoking deletion.
The implementation obtains the current Supabase session, invokes an authenticated deletion function with the session user identifier, and signs the user out after that function reports success. Menu labels and navigation may change by release; consult the current app UI.
- Confirm that you are signed in to the account you intend to delete.
- Do not share your password, one-time code, session token, or account recovery link.
- If the app cannot complete the request, preserve the error message and contact the verified support channel.
What the current code demonstrably deletes
The deletion function validates the bearer session with Supabase Auth and calls the Supabase administrative delete-user operation for the authenticated user identifier. The client then attempts to log out.
That function does not visibly delete rows from the profile, chat, report, content, settings, notification, or relationship tables, and it does not visibly remove objects from the configured media storage. It also does not prove cleanup from any separate legacy server database or backups.
- The reviewed function is an authentication-account deletion path.
- Associated data removal, cascade behavior, and provider-side propagation remain unverified.
- The success message in the app should not be read as proof of complete erasure across all systems.
Information that may remain associated
Depending on the production schema and service configuration, account-linked information may include profile fields, social relationships, posts and media, comments, chat records, reports, report evidence, permission settings, notifications, push identifiers, and operational logs.
This list is a map of implemented feature data paths, not a claim that every listed record remains after deletion. BALYX must inspect live database foreign keys, deletion triggers, object storage, provider APIs, backups, and server logs to determine the actual outcome.
- Public content may remain visible until its separate removal is confirmed.
- A report or safety record may have separate retention needs, but no verified schedule is available here.
- Recipients may have independently saved messages, media, notifications, or screenshots.
Before submitting a request
Download or save any information you are entitled to keep before deletion. The reviewed code does not establish an account export feature, so do not assume that an export is available.
If you need an individual post removed, a report reviewed, or a privacy request handled without deleting the account, use the relevant in-app control or contact route rather than treating account deletion as a substitute.
- Check whether you need records for your own files, reports, or ongoing conversations.
- Resolve any important access that depends on the account before confirming.
- Read the confirmation screen in the current build; it controls the immediate app flow.
Verification and protection against unauthorized requests
The app deletion function requires an authenticated bearer session and verifies the session user before deleting that user. A supplied user identifier that does not match the authenticated identity is rejected.
If an external request route is later provided, BALYX should verify request authority using a proportionate process and must not ask people to disclose passwords or one-time codes. The reviewed website content does not currently provide a verified external deletion form.
- Submit requests only through an official Kronop in-app flow or verified contact route.
- Never send full payment details or authentication secrets to prove account ownership.
- If you cannot access the account, use the official recovery route before asking for deletion.
Timing, reversibility, and confirmation
The reviewed deletion function returns success or an error but does not define a grace period, cancellation window, processing service-level agreement, or completion notice for associated data.
Because the app describes the action as irreversible, treat confirmation as final for the authentication account. A user should not be promised that the account can be restored unless the production service owner verifies that capability.
- The code does not state a full data-erasure completion deadline.
- A request that fails should be retried only after checking whether the account remains accessible.
- A separate response should confirm what was deleted and identify any data retained under a verified exception.
Data retained for legal, safety, or technical reasons
Applicable law may require limited records to be kept, and security or abuse investigations may require narrowly scoped evidence. The app repository does not establish the legal basis, category, duration, access rules, or jurisdictions for any such retention.
Before making this policy final, BALYX must publish the actual exceptions, retention limits, backup lifecycle, and whether retained material is isolated from ordinary product use.
- Retention exceptions should be limited to a documented purpose and period.
- Data kept for a legal obligation should not be treated as available for unrelated product use.
- A user should be told when a verified legal exception prevents full deletion, where law permits.
Third-party and device copies
Authentication, database, realtime, notification, object-storage, and operating-system providers may process or retain data according to their service roles and settings. The exact production providers and deletion propagation behavior must be confirmed.
Uninstalling the app removes the app from a device but does not submit an account deletion request. Local caches or downloaded AI model files may require device-level removal, and recipient-held copies are outside Kronop's direct control.
- Sign out and uninstalling are not substitutes for using Delete Account.
- A downloaded local AI model is stored in app document storage; the reviewed code does not link its removal to account deletion.
- Provider-side and backup deletion timing must be verified before publication.
If you need help
The website should expose a working privacy contact for deletion failures, requests involving records not removed by the app, and questions about data scope. A generic policy page is not itself a submission channel.
When requesting help, provide the account username or a verified contact identifier and the approximate date of the request. Do not include authentication secrets, unrelated sensitive material, or another person's private data.
- Use the verified support or privacy contact linked from the Trust Center.
- Keep any case reference so you can follow up.
- Escalate a failed in-app request through the official channel rather than sending credentials by email.
Publication checks required
This page intentionally describes what the client and deletion function show without claiming full deletion. Before publication as a final commitment, the service owner must test deletion in production-like systems and document the outcome for every account-linked store.
The legal entity, privacy contact, jurisdiction-specific rights, verification standard, completion targets, retained-data exceptions, and appeal route are not supplied by the app code and must be approved by qualified reviewers.
- Verify profile, content, comments, chat, reports, permissions, notifications, and storage-object cleanup.
- Verify any separate database, logs, caches, backups, and third-party deletion requests.
- Make the website request path and in-app deletion behavior match before promising complete erasure.
What you can do
- Use the in-app Delete Account control only after reviewing the consequences.
- Save information you need before confirming an irreversible action.
- Request confirmation about related data and records through the verified privacy 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.