Privacy Policy

Optional website analytics and device storage

Essential browser and device storage supports authentication, encryption, security and your settings. The website also offers optional Google Analytics, disabled until you enable it using Privacy & cookies. Google Analytics can store _ga cookies and receive technical connection information. Our analytics configuration does not intentionally send account identifiers, file names, folder paths, query strings or URL fragments, and advertising personalization is disabled.

Your optional analytics choice is stored on this browser for 180 days. You can accept, reject or customize it, and withdraw it later using Privacy & cookies. Withdrawal disables collection and removes accessible Google Analytics cookies on this site; it does not erase information already received by Google. This optional website integration does not add a Google Analytics SDK to native desktop or mobile apps. Optional website marketing-source measurement and its session storage follow this same consent choice. Essential service and security processing is separate.

1. Scope and Controller

This Privacy Policy applies to RonikCloud accounts, apps, websites, billing, storage, backups, support, diagnostics, and security operations. The data controller is Tomáš Názler, 24. dubna 145, Zeleice 664 43, Czech Republic.

2. Data We Process

• Account data: Firebase Authentication processes the email address, display name, Firebase user ID, sign-in state, and security settings needed to authenticate the account. New general workspace-profile documents do not duplicate the email or display name. A bounded migration removes older duplicated names and removes older duplicated emails after any legacy email-derived storage identity has moved to an opaque identifier.
• Billing data: subscription tier, billing interval, Stripe customer and subscription IDs, app-store transaction identifiers, invoice or transaction metadata, payment status, and limited masked payment information that a provider may make available for billing support. RonikCloud never receives or stores a full card number or card security code. Stripe or the applicable app store handles payment credentials.
• Storage metadata: opaque object identifiers, encrypted file and folder labels for protected records, account-keyed backup integrity tags, file size, upload timestamps, opaque folder and parent references, access relationships, a coarse storage-lifecycle boundary shared by each UTC week, storage usage, and provisioning state. A successful open, preview, download, restore, or share sends only the opaque file ID; RonikCloud does not retain the action kind or a precise per-file access time. File records do not receive preview classifiers or mirrored password-share state, counts, or exact last-share times. Legacy precise access fields and those legacy mirrors are removed in bounded maintenance cycles. When a canonical encrypted label and matching recovery metadata are already present, bounded maintenance also removes redundant readable names and paths; a missing encrypted replacement must first be created by an authorized device. Business company/group records also hold bounded required and completed reconciliation counters so trusted devices can notice unfinished encrypted access changes; these counters contain no member, file, label, reason, or task details. Older records may retain legacy folder metadata or public content fingerprints until they are migrated or uploaded again.
• Password-share operational data: a random link token, owner and source-file identifiers needed for authorization, expiry and revocation state, encrypted-payload request budget and counter, one-bit first-access, near-budget, and blocked-proof alert states, and for new links a password-derived verifier that is not returned by the public metadata API. Short-lived failed-proof throttles use salted token and token/network hashes rather than raw link or network identifiers. Exact per-link access times are not retained. Filename and content type remain inside client-encrypted metadata. File-card badges are derived on the authorized device from the signed-in account’s own canonical links; another Business member does not receive that badge. Share account events have an operational event time but are generic and contain no recipient, filename, token, or source-file identifier. Older links may retain a readable private label until their policy is edited or they are revoked; bounded maintenance removes legacy precise access fields and file-level share mirrors.
• Password-share source authorization and lifecycle privacy: every public metadata or download request rechecks that the source is active and, for Business files, that the creator still has active membership, source access, and share plus download permission. New expiry boundaries are rounded up to the next UTC hour, and new links retain no exact creation, revocation, update, or access timestamp. Current owner actions and bounded maintenance delete those timestamp fields from compatible older links. The encrypted derivative uses the creator's opaque Personal storage prefix so its object key does not encode company scope; server-only authorization still retains the creator and source identifiers required for those checks.
• File-request operational data: the owner relationship, random request and object identifiers, expiry, size and upload limits, counts, encrypted payload sizes, status, and timestamps needed to authorize and deliver submissions. New request titles and submitted filename/content-type metadata are client-encrypted. The public metadata API omits the owner identity and storage references, and direct public request-document reads are denied. Older readable request titles are replaced with a fixed generic value and older submitted content-type fields are removed in bounded maintenance cycles.
• Device and local data: encrypted offline vault objects, backup folder mappings, interrupted-transfer checkpoints, preferences, search settings, theme settings, and encryption salt. Backup mappings and fingerprints, transfer checkpoints, multipart upload IDs, and offline object/directory mappings are stored in an authenticated account-scoped encrypted cache using a key held by the operating system credential store. Offline file contents use chunked authenticated encryption bound to the environment, account, object, and file key; older readable offline copies are upgraded when their file key is available. Opening or sharing through another app creates a temporary decrypted copy that the operating system or receiving app may retain.
• Technical data: app version, platform, security and operational logs, user agent, referrer, IP-related security data, and support messages. Manual workspace reports remove common emails, paths, filenames, tokens, and secret-like values before sending, use an opaque Support code instead of copying the account email or raw user ID, and never attach a file, key, log, or automatic diagnostic. The remaining report text is readable by RonikCloud support. Automatic client diagnostics are off by default and are sent only after you enable Share minimal diagnostics in the Data safety center. New diagnostic reports contain only fixed error, reason, and library codes, platform, build mode, and fatal state; stored reports have no account ID or Support code and exclude exception messages and stacks, filenames, paths, workspace labels, URLs, and provider object references.
• Deleted-account suppression data: the long-lived server-only suppression record contains a one-way SHA-256 hash of the Firebase user ID, deletion state, and start/completion timestamps. Separately, a minimal profile tombstone and server-only rule-enforcement block remain at Firebase-user-ID-addressed document paths so already-issued sign-in tokens cannot recreate account data. Those enforcement records contain only deletion state, privacy version, timestamps, and expiry. Neither type contains an email, name, card detail, or file identifier; the long-lived record contains no raw user ID.
• Closure processing uses a separate server-only operation record with the account identifier, authenticated-request authorization version, phase, retry and lease state, and minimum verified provider references needed to resume safely. Optional manual approvals use hashed operator identifiers and approval times. It contains no file contents, passwords or encryption keys. After cleanup, provider references are removed and only a verified email may remain while completion notification is retried. The remaining operation is assigned a 90-day expiry even if notification fails. Unverified addresses use the private status receipt instead of email. Pending cleanup remains recorded until safely resolved.
• Account-closure request data: the authenticated in-app request queue is server-only and uses a SHA-256 hash of the Firebase user ID as its document key. Its minimal record contains the Firebase user ID needed for support operations, request status, privacy version, request/update timestamps, an internal response target, a hash of a private receipt token, fixed support-notification delivery status and code, notification timestamps and attempt count, and—after resolution—resolution timestamps and expiry. It contains no email copy, free-text reason, card detail, billing identifier, or file identifier.

3. Why We Process Data

• To create accounts, authenticate users, and provide encrypted file storage.
• To process subscriptions, enforce plan limits, and provide billing support.
• To protect accounts, investigate abuse, debug failures, and maintain service reliability.
• To match routine support and operational events using an opaque Support code instead of displaying a Firebase user ID or account email.
• To send service, security, billing, and product communications when permitted.

4. Providers and Transfers

RonikCloud uses providers including Firebase/Google Cloud, Wasabi, Stripe, Resend for permitted product updates and necessary service, privacy, security, or support operational notifications, GitHub for release operations, and infrastructure providers needed to host or secure the service.

Our production Firestore database is located in the United States multi-region (nam5), verified on 10 September 2026. Running Cloud Functions in Europe does not mean all account and file metadata stays in Europe. Ask support@ronikcloud.com for information about applicable transfer safeguards and how to obtain a copy. We do not promise EU-only storage.

Providers may process data in more than one country. Stripe documentation requires merchants to disclose that payment data may be transferred, processed, and stored outside a customer location where applicable.

Legal Bases and Your Choices

• Providing the contracted service: account authentication, encrypted storage, requested sharing, subscription administration and support needed to perform our agreement with you (GDPR Article 6(1)(b)). Necessary account and service data is required to provide those functions. A real recovery email is optional in username-only registration; choosing not to provide one limits email recovery and email contact.
• Legal obligations: records and disclosures necessary to comply with applicable accounting, tax and other legal requirements (Article 6(1)(c)). This does not justify keeping unrelated files or all account records indefinitely.
• Legitimate interests: proportionate security, fraud prevention, abuse handling, service reliability and establishing or defending legal claims (Article 6(1)(f)). You may object on grounds relating to your situation; processing must stop unless the applicable legal test for continuing is met.
• Consent: optional website analytics, optional client diagnostics and optional product-update communications (Article 6(1)(a), and applicable rules on device storage and electronic communications). You can withdraw using Privacy & cookies, the diagnostics setting, product-update preferences or an unsubscribe link, as applicable. Withdrawal does not affect earlier lawful processing or access to the core service.
• Where a Business customer determines the purposes of processing personal data in its workspace, it is responsible for that controller role. RonikCloud processes that customer content on documented instructions under the applicable data-processing agreement; our own account, billing and security responsibilities remain separate.

5. Your Rights

Depending on your location, you may have rights to access, correct, delete, export, restrict, or object to processing of personal data. Where GDPR applies, we respond without undue delay and within one month of receiving a request. If its complexity or number permits an extension, we notify you within the first month with the reasons; the extension cannot exceed two further months. Requests are normally free of charge.

Send privacy requests to support@ronikcloud.com. We may need to verify your identity before acting on a request.

You can complain to a data-protection supervisory authority, particularly in your country of habitual residence, place of work or the alleged infringement. In the Czech Republic, contact the Úřad pro ochranu osobních údajů at https://uoou.gov.cz/. You do not have to complain to us first, and judicial remedies remain available.

You may object to direct marketing at any time, free of charge. Where consent is the legal basis, you may withdraw it at any time. If a request is refused, we explain the reason and your complaint and judicial-remedy options within the applicable deadline.

6. Retention and Deletion

Retention rules are described in the Data Retention Policy. A pending account-closure request remains until automated processing or support resolves it; it has no automatic expiry because deleting an unhandled request could defeat the user's request. After audited resolution, the request record is assigned an expiry 90 days after resolution. Scheduled maintenance may remove it after that expiry time. Completing account closure requests deletion of linked Stripe customer profiles and their reusable payment details. App-store payment credentials remain controlled by the store account. Some transaction records, logs, invoices, fraud records, provider backups, organization-owned workspace data, or records required for accounting, security, dispute resolution, or legal compliance may remain for a limited period after account deletion. After deletion succeeds, the pseudonymous long-lived deletion guard is assigned an expiry 400 days after completion solely to suppress delayed billing activity. The minimal Firebase-user-ID-addressed profile and rule-enforcement tombstones are assigned a 48-hour expiry. If closure is incomplete and authentication remains, closing-state deletion and enforcement records remain until the user retries or support safely resolves the deletion; removing them sooner could allow already-issued sign-in tokens to recreate data. Scheduled maintenance removes completed-deletion records after expiry, and a delayed maintenance run may complete removal after the expiry time.

7. Contact

Privacy questions or requests can be sent to support@ronikcloud.com or by post to Tomáš Názler, 24. dubna 145, Zeleice 664 43, Czech Republic.