Archived Privacy Policy
This is the notice published on August 23, 2026 for earlier test builds. It does not describe the current version. Read the current Privacy Policy.
1. Operator
Cubaster is provided by Капуста ("we", "us"). For privacy questions, contact cubaster@proton.me.
This Privacy Policy applies to the Cubaster Android App with package name com.cubaster.
2. Summary
The App does not use advertising SDKs, cross-app tracking, or third-party analytics SDKs that profile users for marketing.
The App connects to game servers selected by the user. Those third-party servers may process the player's IP address, username, chat, and gameplay traffic under their own policies. When you open the Recommended tab, the App also sends a standard status ping to each recommended server to show live online count and latency. This happens before you choose to connect, and the recommended server receives your IP address as part of that ping.
The App fetches a static address-only recommended-server catalog from cubaster.com. It does not send recommended-server analytics, reports, account identifiers, advertising identifiers, Android ID, device ID, chat content, gameplay content, contact lists, or device files to the catalog host.
Minimal crash diagnostics upload is enabled by default and can be disabled at any time in the App. The App may send crash reports and technical diagnostics to Cubaster servers so we can diagnose crashes, ANRs, native failures, compatibility problems, and performance regressions. Before default collection is activated for the first time, the App establishes a local collection boundary and removes older pending bundles so crash sources from before that boundary are not uploaded later. These reports are designed to be compact, redacted, and privacy-minimized.
If registration cannot complete after the App receives a signed first-party challenge, it automatically sends or queues a separate minimal secure-startup report. A release-scoped diagnostic build may also queue a compatibility observation, including a zero mask that records that the former local policy found no mismatch. These essential records contain numeric failure and compatibility fields, random report and process-session values, and the short-lived signed challenge used only as delivery proof. They do not contain a crash log, stack trace, device model, advertising or hardware device identifier, attestation certificate chain, key, username, chat, world, or player file.
Protected releases may contact Cubaster's first-party key service during startup. This uses a random release-scoped installation identifier and Android hardware-key attestation to decide whether a hardware-wrapped protected-content key may be issued. It does not use Advertising ID, Android ID, IMEI, MAC address, or attested device identifiers.
When the App connects to a first-party Cubaster multiplayer server, it automatically performs a limited local runtime security check in response to that server's request. Only a compact technical result is returned to the first-party server and associated with the existing multiplayer connection. The check is used to protect multiplayer sessions from tampering and abuse; it is not used for advertising, cross-app tracking, or marketing.
If the App is distributed through Google Play, Google may process technical data required to deliver the app and asset packs under Google's own policies.
3. What We Do Not Do
We do not use Firebase Analytics, AdMob, AppsFlyer, Adjust, Mixpanel, Amplitude, Sentry, Crashlytics, or similar advertising or marketing SDKs to profile users.
We do not sell user data and do not share user data with data brokers.
We do not provide our own developer-run account system inside the App. We do not collect contacts, address books, photos, precise location, or payment card data through the App.
We do not collect full system logcat, screenshots, world saves, chat content, account credentials, access tokens, Advertising ID, Android ID, IMEI, MAC address, or contact lists in automatic crash reports.
However, the App does perform limited network operations described below. For the current version of the App, a blanket statement such as "we do not process any data at all" would be inaccurate.
4. What Data We Process and Why
4.1. Connections to third-party game servers. When you connect to a game server, the App creates a direct connection to that server. That server may process the player's IP address, username, chat, gameplay traffic, and other session data under that server operator's own policies. We do not control and are not responsible for the privacy practices of third-party game servers.
4.1a. Status pings to recommended servers. When you open the Recommended tab in Multiplayer, the App sends a standard Minecraft status ping to each recommended server. This happens before you choose to connect. The purpose is to show live online player count and connection latency. This ping is a direct network contact with the recommended server operator. The recommended server receives your IP address as part of the standard network connection. We do not receive or store data from these pings. The recommended server operator's own privacy policy governs how they handle connection data.
4.2. Recommended server catalog. The App fetches the static address-only catalog at https://cubaster.com/catalog/v2/recommended-servers.json. The response contains no server names, MOTD copies, icons, per-user selection, telemetry, or reporting fields. GitHub Pages and its network providers necessarily process the connection IP address and ordinary HTTP metadata to deliver this file. The request is not forwarded to the Cubaster application backend and Cubaster does not store a catalog-request database record.
4.3. Optional crash reports and diagnostics. Crash diagnostics upload is enabled by default and can be disabled in the App's diagnostics settings. While enabled, the App may send encrypted crash reports and technical diagnostics to Cubaster crash collector servers. Reports may include crash logs, stack traces, normalized crash fingerprints, app-private Mojang crash text files, Java uncaught exception information, Android ApplicationExitInfo for this app, ANR text traces, native tombstone bytes when Android exposes them for this app, short app-private diagnostic ring logs, app version, runtime version, build metadata, Android SDK version, device manufacturer/model, ABI, memory bucket, graphics backend, GPU/vendor/renderer information when available, native runtime library identity, report IDs, and a resettable pseudonymous Diagnostic ID derived from an app installation identifier. We use these reports only to group crashes, investigate technical failures, improve compatibility and performance, prevent regressions, and respond to support requests.
The underlying game runtime may create an app-private crash text file when a crash occurs even while upload is disabled. Before the App activates default-on collection for the first time, and whenever the user changes the upload policy, it establishes a durable collection cutoff and removes older pending upload bundles and diagnostic ring logs. Crash sources at or before that cutoff are not transmitted later merely because upload is active. While upload is disabled, Cubaster's automatic diagnostics collector does not create upload bundles or diagnostic ring logs. Local crash files can be deleted in the App's diagnostics settings.
Automatic crash reports do not include full system logcat, screenshots, world saves, chat content, account credentials, access tokens, Advertising ID, Android ID, IMEI, MAC address, contact lists, photos, videos, or arbitrary device files. Crash diagnostics upload can be disabled or re-enabled in the App's diagnostics settings, and an explicit stored choice remains in effect across updates. The App remains usable without upload.
4.3a. Essential secure-startup diagnostics. Protected releases automatically create a separate minimal report when registration cannot complete after the App has received a signed registration challenge, or when the former client-side compatibility policy would have rejected registration-key metadata that is now decided by the server-side attestation verifier. Diagnostic version 44 also creates a release-scoped compatibility observation when that mask is zero, providing an affirmative clean observation if it is delivered; a missing server row alone is not treated as proof of a clean result. The report contains a random report ID, a random value shared only by attempts in the current App process, numeric outcome, startup stage, reason, support code, elapsed time, attempt number, a bounded compatibility bit mask, and an Android Keystore numeric error code when Android exposes one. It also carries the exact short-lived signed challenge as bearer admission proof so the collector can bind the report to the App version and release identity. The collector verifies and discards that bearer proof; it stores only normalized numeric fields, domain-separated hashes of the proof and process-session value, and a domain-separated full-report binding used only for idempotence. The proof does not make the client-supplied numeric fields a hardware-authenticated security decision.
This channel is essential to diagnose devices that cannot reach the game runtime, so it is independent of the optional crash-report setting. It is best effort, its network delivery is asynchronous, and it cannot grant or deny protected-content access. The report does not include the attestation certificate chain, public or private keys, exception text, stack trace, crash log, device manufacturer/model, username, account identifier, install identifier, Advertising ID, Android ID, IMEI, MAC address, IP address in the report database, or player data. The App keeps at most 16 pending reports in Android's private no-backup storage and removes reports older than 24 hours when the local clock can establish their age; the 16-record limit still applies when it cannot. A local ledger keeps at most 16 secure-startup Report IDs for up to seven days so a user can copy them or request deletion even after delivery. The App exposes when delivery is paused because another component installed a process-global cookie handler.
Before a signed challenge is available, the App does not send an anonymous diagnostic report. For the current failed registration attempt, it includes the random 128-bit registration-challenge request ID in copied failure diagnostics; it does not maintain a separate persistent correlation file. The protected-content authority retains that same request ID in bounded challenge-response state together with a request digest, a committed-or-abandoned outcome, and retention timestamps. Registration outcomes remain for no longer than 72 hours; recurring lease tombstones remain for no longer than 24 hours. Support can perform an exact read-only lookup without adding a diagnostic write to challenge delivery. A committed result means the server durably created the signed challenge; it does not prove that the App received or verified the HTTP response. The value changes with each fresh challenge and is not a permanent device or installation identifier.
4.4. Protected-payload access. A protected release may send Cubaster's first-party key service a random release-scoped Protected Install ID, two Android hardware-key attestation certificate chains, the bound Android SDK version, exact app/release identity, and cryptographic challenge/response values. This processing is used only to verify hardware-key properties, prevent unauthorized offline access to protected payloads, issue a hardware-wrapped content key, prevent replay and abuse, and support revocation or deletion of that installation record. The App does not request Android ID, Advertising ID, IMEI, MAC address, an attestation unique ID, or KeyMint device-identifier fields for this purpose. Raw attestation certificate bodies are verified in memory and are not retained. For a rejected registration, the verifier may retain for up to seven days only the app/release identity, a domain-separated digest of the signed challenge, the first and latest separate numeric reason/detail results for the wrapping and proof-of-possession keys, and a bounded count of changed results for that challenge. Exact retries of the latest result do not increase this count. This rejection record contains no raw certificate, key, IP address, device identifier, model, exception text, or stack trace. For accepted registrations, certificate hashes, revocation-relevant serials, normalized security claims, bounded decisions, and the random installation record may be retained as described below.
4.5. First-party multiplayer runtime security check. When the App connects to a first-party Cubaster multiplayer server, that server automatically requests a limited local check for broad signs that the App runtime or device security environment may have been modified, or that the check could not be completed. The App returns only a compact result covering completion and availability, broad security findings, and minimal compatibility and freshness metadata. The first-party server associates this result with the player's existing connection and username. The App does not transmit raw inspected content, memory contents, device files, a list of installed apps, Advertising ID, Android ID, IMEI, or MAC address as part of this check. The result is sent to the first-party multiplayer server over the existing game connection and is used only for service security, abuse prevention, and investigation. It is not sent to Google, advertising providers, or third-party analytics services; infrastructure providers may process it only as service providers described in Section 9. This check is separate from protected-content access and optional crash diagnostics.
4.6. Google Play. If the App is distributed through Google Play, Google may process technical data needed for publishing, app download, asset pack delivery, and store infrastructure. Google's processing is governed by Google's own policies.
5. Legal Bases
We process data to the extent necessary to operate the App's network features, display the recommended-server catalog, prevent abuse, and respond to support requests.
For optional crash diagnostics, we rely on our legitimate interest in maintaining App reliability, diagnosing failures, and improving compatibility. We limit this processing through data minimization, application-layer encryption, short retention, local deletion controls, and the user's ability to disable collection or object to the processing. Essential secure-startup diagnostics are processed as necessary to operate and support protected startup and for our legitimate interest in identifying compatibility failures that otherwise prevent use of the App. For the other operations described above, the basis is operation of the service and our legitimate interests in support, security, abuse prevention, and moderation.
6. Retention
Local on-device crash diagnostics: kept only in app-private storage until the user deletes them, app storage is cleared, or app cleanup removes old pending reports.
Raw encrypted crash reports and diagnostics: up to 30 days from receipt.
Decoded crash attachments: up to 30 days from receipt.
Crash triage metadata: up to 30 days from receipt. This metadata may include Diagnostic ID, report ID, app version, device model, Android SDK version, and build identifiers needed for private triage and symbolication.
Aggregate crash fingerprints and alerts: maintained only from crash reports received during the preceding 30 days and retained for no longer than 30 days. They do not contain Diagnostic ID or report ID and are shown only when the aggregate count is at least 3.
Crash-diagnostics deletion-request records: retained for no longer than 30 days after the request is completed.
Essential secure-startup diagnostics: pending reports are capped at 16 records and are removed after 24 hours when the local clock can establish their age. The local Report-ID ledger is capped at 16 entries and retained for no longer than 7 days. The local diagnostic-data deletion control removes the report queue, receipt ledger, and last startup-failure record; clearing all App storage also removes any pending protected-startup protocol state. Accepted normalized server rows are retained for no longer than 7 days from receipt. The signed challenge is verified in memory and is not stored in the report database.
Rejected hardware-attestation diagnostics: the minimal server-side rejection record described in Section 4.4 is retained for no longer than 7 days from the rejected registration attempt.
Protected installation challenge and retry data: challenge payloads and ordinary retry data are retained for no longer than 20 minutes. A minimal response-intent tombstone may contain only the challenge kind, random request ID, a domain-separated request hash, whether the signed challenge was committed or abandoned before commit, and retention timestamps. Registration tombstones remain for no longer than 72 hours; recurring lease tombstones remain for no longer than 24 hours. These records make exact retries and support correlation deterministic. The random release-scoped installation record may be retained while active and is deleted no later than 90 days after expiry, revocation, or inactivity, or earlier after an authenticated deletion request. Identified protected-access security audit events are retained for up to 30 days; identifier-free aggregate abuse metrics for up to 180 days.
First-party multiplayer runtime security checks: the current result is used in connection state while the player is connected. A compact outcome may also be written to first-party security records or ordinary server logs together with the player's username and timestamp for abuse prevention, security review, and operational diagnosis. These records are retained only for as long as reasonably necessary for those purposes and are not used for advertising, marketing, or cross-app tracking.
Email and support requests: for as long as reasonably necessary to respond, follow up, and comply with legal obligations.
When retention is no longer necessary for the stated purposes, the data is deleted or no longer kept in the active application data path.
7. Your Rights
You may request access, correction, deletion, or restriction of data that we actually control. You may also object to processing based on legitimate interests and change the crash diagnostics setting in the App.
To make a request, email cubaster@proton.me and describe the data and action involved. For already-uploaded optional crash diagnostics, include the Diagnostic ID shown in the App's diagnostics settings, or a report ID if available. For essential secure-startup data, include any exact Report ID shown through Copy diagnostics or the Data and privacy screen; a copied challenge-request correlation value can locate the temporary issuer attempt but is not itself a report-deletion key. For protected-payload access data, use the authenticated deletion control in the App or include the Protected Install ID shown there. For first-party multiplayer security logs, include the player username and the approximate date and time of the connection. We aim to complete deletion requests within 30 days unless a longer period is required by law, security, abuse prevention, or request verification. We may request minimal information needed to verify the request and prevent abuse.
If GDPR, UK GDPR, or similar rules apply to you, you may also contact the relevant supervisory authority.
8. Children
The App is a general-audience game and is not intended specifically for children under 13. We do not knowingly collect personal data from children under 13 through a developer-run account system because the App does not provide one.
If you believe a child under 13 has sent us personal data by email, contact cubaster@proton.me, and we will review and delete it where appropriate.
9. Security
We try to minimize the amount of data processed. The recommended-server catalog is a static GitHub Pages file and has no Cubaster application-backend endpoint or catalog-request database.
For crash diagnostics upload, the reverse proxy forwards the client IP address to the crash collector only for abuse prevention, rate limiting, and transport security operations. The crash collector does not store IP addresses in the crash report database or decoded triage metadata. IP addresses may appear transiently in operational logs, for example when a request is rate-limited or rejected.
Crash reports are sent over HTTPS and are also encrypted at the application level before upload. The public crash collector is designed to store encrypted report packages and minimal metadata, and it does not store the private decryption key. Decryption, triage, and symbolication are separated from the public upload endpoint.
Essential secure-startup reports use a separate HTTPS intake with independent rate limits, concurrency limits, retention, and a remote kill switch. The collector accepts a report only after verifying the short-lived signed challenge against the exact admitted signing key, does not forward or store the source IP with the report row, and cannot alter the App's authorization result. These fixed numeric reports are not app-layer encrypted because the public collector must authenticate and normalize them; HTTPS protects them in transit.
The protected-content issuer, key-wrapping worker, and crash collector use separate service identities and credentials. The first-party multiplayer server receives only the compact runtime security result described above, not the underlying inspected content. The crash collector cannot issue protected-content keys or access multiplayer runtime-security state.
We may use VPS, hosting, and infrastructure providers to operate Cubaster services. They process data only as service providers for hosting, transport, storage, and security operations. We do not sell crash diagnostics or catalog-request data.
No technical measure can provide an absolute security guarantee. If you have a question about a specific privacy or security risk, email us at the address above.
10. Changes to This Policy
We may update this Privacy Policy when the App, backend, app store requirements, or legal requirements change. The updated version will be published on this page with a new revision date.
11. Contact
Email: cubaster@proton.me
This page is the Privacy Policy URL for app store use.