Privacy Policy

In short: Kubian checks that a device and its app are genuine, shares the resulting verdict (including OS, vendor firmware, and boot patch levels) with that application's backend so it can enforce its own security policy, and keeps only the records needed for verification, security, and abuse prevention. We never sell personal data and never use identifiers for advertising, and you may request access, correction, deletion, or a portable copy of your data at any time (see Section 9). Important correction: Android ID is app-scoped, but the Widevine MediaDrm ID is cross-application — the same physical device presents the same Widevine ID in every application — so Kubian can trace a device across applications through its Widevine ID. If you provide an identifier Kubian can trace back to your device (see Section 10), Kubian will delete all of your lawful Kubian-held records for that device, subject to the ban and security exceptions in Sections 6 and 9.

0. Roles: Data Collector & Data Processor

You, the game studio / developer / buyer integrating Kubian, act solely as the authoritative Data Collector. Kubian, operated by Static Labs LLC, acts solely as the authoritative Data Processor: we process only the data provided to us when you explicitly initialize Kubian's system (by executing our code) to collect and process data upon request.

In practical terms: Kubian will not, and will never, act on, collect, or store data without explicit code execution from you, the Data Collector. Our internal systems never collect data automatically until instructed by your application code. Once you execute our code, you remain the authorized authoritative Data Collector for all data collected while the game or application is running.

Because collection is developer-initiated, you are fully responsible for end-user data deletion for your application, including notifying Static Labs LLC about end-user deletion requests — for example by calling the developer deletion API (POST https://api.kubian.app/privacy/admin/enduser-deletion) documented in Section 10. Widevine ID exception to any per-app limitation: because the Widevine MediaDrm ID is cross-application (Section 1), Kubian can identify a device across applications when it is provided with a traceable identifier (Section 10), and will then delete all lawful Kubian-held records for that device, subject to the ban and security exceptions in Sections 6 and 9. Kubian cannot delete a developer's own independent records; the developer remains responsible for those.

1. Information We Collect

We collect device signals, cryptographic signatures, user account identifiers, and application data strictly for the purpose of hardware attestation, security, account management, device-bound account verification, and authentication.

We automatically collect and log technical data when you access or use the service, including IP addresses, user agent strings, timestamps, and request metadata. This data is used strictly for security, authentication, abuse prevention, rate limiting, and infrastructure protection.

When a device interacts with a service that uses Kubian, we collect and process the following device-level data:

• Hardware-Derived Identifiers & Permanent Account IDs: Android ID is app-scoped: since Android 8.0 it is scoped per application (per app signing key) and is resettable, so the same physical device presents different Android ID values in different applications. The Widevine MediaDrm ID is not app-scoped — it is cross-application: the same physical device presents the same Widevine MediaDrm ID in every application, it cannot be reset by the end user like ANDROID_ID, and it persists across app reinstalls, cache clears, and factory resets on devices with a proper Widevine implementation (behavior may vary on low-end or modified devices without one, see Section 8). Kubian can therefore trace a device across applications through its Widevine ID, and uses that ability only for security, ban enforcement, and deletion (see Section 3) — never for advertising, profiling, or sale of data. These identifiers are used to issue and maintain a permanent, 16-digit numeric account identifier (user_account_id). Anchored in the device's secure execution environment, the user_account_id is stable across app reinstalls, factory resets, and cache clears within the same application. It is not accessible to applications by default: an integrated application only ever receives it if its developer has submitted a Data Collection Request that Kubian has reviewed and approved (see Section 3). It operates alongside temporary project-scoped unique IDs to guarantee hardware attestation integrity, verify user accounts via device-bound mechanisms, and enforce active restrictions across modified environments. Each user_account_id is project-scoped: it is issued separately per application, so a device receives a different user_account_id value in every app, and a developer who receives only their own project's value cannot use that value alone to correlate a user across applications. Derivation is project-scoped and keyed — the identifier is not a raw copy or unkeyed hash of the underlying hardware ID — but Kubian internally can link those different per-project values to the same device through the shared Widevine ID, which is what makes cross-application deletion possible when a traceable identifier is provided (Section 10).
• Cryptographic attestation certificates and hardware signatures issued by the device's secure hardware
• Application package name and APK integrity hash
• Device boot state, verified boot chain status, bootloader lock state, and security level
• Operating system version, OS security patch level, vendor firmware patch level, and boot/kernel patch level — each a date-formatted number (for example, 20260701) read from the device's hardware attestation certificate on modern devices (KeyMint / Android 12+). These values describe how up to date the system, vendor firmware, and kernel images are; they contain no identifiers and cannot by themselves identify a person or device
• Environment signals including root detection, debugger presence, emulator detection, and hook detection results
• Device fingerprint strings used for audience binding in cryptographic tokens

Age Requirements & Intended Audience: Kubian services integrated within third-party applications are intended for end-users and players aged 13 and older. Except for the limited blocking measures described in Section 8, we do not knowingly collect or process personal data from children under 13 years of age. Registration for Kubian developer accounts, project creation, and administrative dashboard access strictly requires individuals to be at least 18 years of age (or the legal age of majority in their jurisdiction) or have explicit, verified involvement and consent from a parent or legal guardian.

2. Use of Information

The collected information is utilized solely to verify device integrity, protect our infrastructure, enforce rate limits, process developer-directed device bans, establish and verify device-bound user accounts, authenticate physical devices via permanent account identifiers, and ensure compliance with our security standards. We do not use your device information or device-bound account identifiers for tracking, profiling, ad tracking, or personalized advertising.

We process personal data based on our legitimate interests in maintaining service security, preventing fraud and abuse, verifying user accounts via device binding, and fulfilling contractual obligations to provide the service.

We may collect and process device-level identifiers and hardware-backed attestation signals strictly for security, account verification, fraud detection, and abuse prevention purposes. These signals may be evaluated alongside internal security checks and platform-provided attestation indicators to identify high-risk or potentially compromised environments. This data is not used for tracking, profiling, or advertising purposes.

What the application's backend receives: to let an integrated application enforce its own security policy, Kubian includes the integrity verdict and the patch-level signals described in Section 1 (OS, vendor firmware, and boot patch levels, OS version, boot state, security level) inside the signed integrity token that application's backend verifies. Raw hardware identifiers (Android ID, Widevine MediaDrm ID), attestation certificate chains, and fingerprints are never placed in developer-facing tokens — verification results travel without the underlying hardware identity.

3. Device Identifiers, Permanent Account IDs, & Device Bans

When your device interacts with an application using Kubian services, Kubian issues a permanent 16-character numeric account identifier (user_account_id) derived from your device's hardware Widevine ID using a project-scoped, keyed derivation (not a raw copy or unkeyed hash of the raw hardware value). The user_account_id is project-scoped: a separate identifier is issued for every application on the same physical device. It does not expire or rotate within an application and is made accessible to that application's developer through the Kubian Client API and SDK only under an approved Account ID Collection grant for persistent identity, device-bound account verification, and account attestation. Additionally, Kubian generates project-scoped unique identifiers ("unique IDs") derived from your hardware signals, which are specific to individual applications and isolated between projects.

Access Control, Purpose Limitation & Audit Trail: The user_account_id is treated as exceptional, high-sensitivity identity data and an application never receives it by default. Before any delivery, the responsible developer must submit a formal Data Collection Request through the Kubian dashboard declaring the requested purposes (such as approved "Other — Device-Bound Accounts" verification grants), a specific justification for the persistent identifier, and their intended retention period, and must accept a binding usage agreement before Kubian grants access. Approved use is strictly limited to application protection and security (including anti-cheat), ban enforcement, user account verification via device binding, and account/device attestation and record-keeping. Use of the identifier for advertising, ad tracking, behavioral profiling, ad profiling, marketing, data enrichment, sale of data, or correlation across applications is explicitly prohibited. Every approval creates an ACCESS GRANT audit record capturing the project, the developer account, the approved purposes, the accepted agreement version, the approval date, and the expiry date. Grants are scoped to the single approved project, expire after one (1) year, and may be revoked at any time; violations may result in warnings, temporary restriction, permanent revocation of identifier access, or termination of the developer's Kubian integration. Until such a grant exists and remains active, the identifier is technically withheld — it is never transmitted to the application or its developer through any API, SDK, token, or response payload.

Each application that integrates Kubian receives its own independently generated project-scoped unique ID and its own independently issued user_account_id for your device. A developer who receives only their own project's identifiers therefore cannot cross-reference or correlate your identity across applications using those project-scoped values alone. Kubian internally can link those values to the same physical device, because the underlying Widevine MediaDrm ID is the same in every application (Section 1). That internal linkage is used only for security, ban enforcement, and deletion — never for advertising, profiling, or sale.

Your underlying Android ID and raw Widevine MediaDrm ID are never exposed to developers. Kubian exposes the generated user_account_id and project-scoped unique IDs to integrated applications via developer APIs for authentication and attestation. Raw hardware signals are used internally by Kubian to link restrictions directly to hardware identity, ensuring bans persist securely across unique ID rotations and re-installations.

If an application developer implements a temporary restriction or device ban, that ban is enforced via Kubian's internal hardware identity linkage and permanent user_account_id. Because bans are linked to permanent hardware identity, they cannot be evaded by app uninstalls, clearing local application data, or unique ID rotations.

To maintain absolute alignment with data minimization principles, our device-banning mechanisms enforce the following strict privacy constraints:

• Configurable Lifecycles: Device bans are temporary by default (standardizing to 168 hours / 7 days unless customized by the developer up to a maximum of 365 days). Developers may also issue permanent bans that remain in effect until manually revoked. All bans are enforced by hardware identity, so they persist across unique ID rotations for the full duration of the ban.
• Administrative Isolation & Masking: Application developers possess administrative access to query a real-time index of active restrictions within their specific project scope (the ban_list). To strictly prevent long-term transaction tracing and unauthorized data exposure, unique ban receipt tokens (ban-id) are securely masked and truncated to their first 5 hex characters within these developer-facing interfaces.
• Automatic Omission: Expired ban records are instantly and automatically filtered out of all active administrative listings, ensuring outdated restriction data remains inaccessible.

Project-scoped Unique IDs are valid for a period of sixty (60) days from the date of generation or last renewal. After this period, the unique ID is considered expired. Once expired:

• No project or application can access or retrieve the expired unique ID
• The expired unique ID will be purged from active records upon the next applicable request from that project
• A new unique ID will only be generated if and when you re-authenticate or re-engage with that specific application that uses Kubian services
• The new unique ID will be a fresh, independently generated value with no public linkage to the prior expired identifier
• Active developer-initiated bans persist across unique ID rotations via the permanent user_account_id and hardware linkage. A rotated project unique ID does not lift an active ban.

Cross-application deletion via the Widevine ID: because the Widevine MediaDrm ID is shared across applications, Kubian can identify a single physical device across different games when it is provided with an identifier that can be traced back to that device (Section 10): (1) that game's project-scoped unique ID (the game UID generated for you), (2) an in-game account ID / player UID generated by that game, where that ID is linked to your device in Kubian's records, or (3) the permanent user_account_id generated for you for any application. Once Kubian is able to find your specific device from the identifier provided, Kubian will delete all of your lawful Kubian-held records for that device, across applications, subject only to the ban and security exceptions in Sections 6 and 9 (active bans, devices marked as abusive, and security infrastructure protection records are not deleted). If the identifier provided cannot be traced to a device in Kubian's records, Kubian will explain that limitation and delete only the records it can reliably identify. Kubian's deletion covers Kubian-held records only; each developer remains responsible for deleting its own independent records.

Automatic 60-day inactivity anonymization: Kubian tracks a per-application last sign-in timestamp for every device record. If a device has been inactive in a specific application for sixty (60) days — aligned with the standard 60-day Unique ID rotation — Kubian automatically anonymizes that application's record: the raw Android ID and Widevine MediaDrm ID values are fully anonymized and replaced by securely keyed hashes. No data is lost: the hashes allow Kubian to seamlessly reinstate the end user's data when they next sign in to that application. Active ban-enforcement records are preserved separately as pseudonymous cryptographic hashes as described in Sections 6 and 9.

Kubian does not provide any mechanism for developers or third parties to recover, reconstruct, or retrieve an expired unique ID. Once purged, it is permanently inaccessible through our systems.

Data Deletion & Ban Preservation: Device bans are tied to persistent device signals, the user_account_id, and security enforcement records. Submitting a data deletion request, opting out of processing, or requesting an identity reset will not lift, revoke, or shorten an active device ban. This exception also applies where a device was already banned, has been marked as abusive, or is flagged for infrastructure abuse or security infrastructure protection, even if no single active ban is listed for a particular application. In the event of a data deletion request, Kubian retains minimal, isolated cryptographic hashes of device signals strictly necessary to maintain active restrictions and prevent platform abuse. All non-essential data associated with the request will be purged in accordance with applicable law. This preservation is limited to the retention exceptions further described in Sections 6 and 9.

4. Data Sharing

We do not sell or share your personal data for cross-context behavioral advertising as defined under the Oregon Consumer Privacy Act (OCPA). Information is not shared with outside third-party entities unless legally required (e.g., via subpoena or court order) or necessary for infrastructure operations and security enforcement.

The permanent user_account_id provides a consistent device identity within each application integrating Kubian. It is not distributed automatically: it becomes visible to an application's developer only after that specific project has been granted an approved, purpose-limited Account ID Collection access (Section 3). Because it is project-scoped, a developer who receives only their own project's identifier cannot use that identifier alone to correlate a user between different applications. Kubian internally can correlate a device across applications through the underlying Widevine ID, which is shared across applications (Section 1), for security, ban enforcement, and deletion purposes only. This identifier is generated and processed solely by Kubian and its approved integrated application developers for authentication, user account verification via device binding, security attestation, anti-cheat, ban enforcement, cross-install state management, and abuse prevention. Developers who receive access are each responsible for their own collection of, access to, use of, disclosure of, retention of, and protection of the identifier, including unauthorized uses by their personnel or systems, as provided by their binding agreement with Kubian and applicable law; Kubian remains responsible for its own security and processing obligations. The identifier is strictly prohibited from being shared with outside third-party advertising networks, used for ad tracking, or used for cross-context behavioral profiling.

We may share information with trusted third-party service providers who perform services on our behalf, such as payment processing, hosting, and infrastructure security. These providers are contractually obligated to protect your data and use it only for the services they provide.

5. Data Security & Storage Technologies

We implement robust security measures, including hashing (e.g., bcrypt for account passwords), encryption in transit and at rest, and IP logging to protect against unauthorized access, alteration, disclosure, or destruction of your personal information and project API keys.

Storage & Session Technologies & Persistent Authentication: For developers accessing the Kubian administrative dashboard, we utilize essential session cookies, local storage, and secure client-side authentication tokens strictly necessary for account security, session persistence, and state management. To maintain an efficient workflow, a secure login token may be stored on the developer’s local device. Upon opening or restarting the application or browser session, Kubian communicates directly with our authentication validation endpoint to verify token validity and automatically restore the session without requiring continuous manual re-authentication. For end-users interacting with third-party applications integrated with Kubian services, Kubian does not store browser cookies or use web tracking mechanisms; all device validation and user_account_id resolutions are performed strictly via direct, encrypted API attestation requests.

We limit access to personal data to authorized systems and personnel strictly required for operational, technical, and security purposes.

Internal Data Isolation: Ban-enforcement cryptographic hashes and security records are stored in a dedicated, logically isolated repository separate from Kubian's standard operational data stores. This separation ensures that ban-enforcement records are subject to distinct access controls, retention policies, and audit procedures, and that no operational data is inadvertently merged with security-enforcement records during routine processing.

6. Data Retention

There are two retention regimes under this Policy. (a) Ordinary devices: we retain your personal data, user_account_id records, and project metrics for as long as your account or associated service integration is active. Usage statistics and anomaly logs may be retained longer for security analysis and to combat future automated abuse. Low-sensitivity integrity signals (OS, vendor firmware, and boot patch levels, security level, boot state) are retained only as part of these verification and security records and are never used for tracking, profiling, or advertising. Upon account deletion, personal data is purged from active systems in accordance with Oregon law and our Terms of Service, except for the limited security, fraud-prevention, ban-enforcement, and legal records described in this Section 6 and in Section 9.

Deletion requests are processed within a reasonable timeframe, generally within 30 days, unless retention is required for legal, security, or fraud prevention purposes as described in this Section 6 and in Section 9.

Notwithstanding the standard 60-day project-scoped unique ID retention window described in Section 3, Kubian reserves the right to retain device signals, user_account_id mapping records, attestation records, hardware certificate identifiers, and associated metadata beyond the standard retention period (b) only where a device has a known or documented history of any of the following:

• Attempts to bypass, circumvent, or interfere with Kubian's attestation or integrity verification systems
• Submission of falsified, spoofed, or manipulated attestation responses
• Repeated integrity violations including rooted environments, unlocked bootloaders, or compromised boot chains across multiple projects or sessions
• Hardware certificate revocation due to accumulated integrity violations
• Known patterns associated with automated abuse, emulation farming, or coordinated bypass attempts
• Any activity flagged as a potential threat to infrastructure, security, or other users of Kubian services

In such cases, retained data is used exclusively for security enforcement, platform integrity, fraud prevention, and, where applicable, cooperation with law enforcement or legal proceedings. Such data will not be used for advertising, profiling, or purposes unrelated to security and compliance. Extended retention under this paragraph is limited to what is reasonably necessary for those stated security purposes, is stored exclusively in the dedicated, isolated ban-enforcement repository described in Section 5, is subject to periodic necessity review, and is deleted when no longer reasonably necessary or required by law. It does not extend ordinary operational retention for devices without such a documented security history.

7. Developer Disclosure Obligation

Any developer, company, or individual ("Developer") that integrates Kubian services into their application, product, or platform is required to provide clear, conspicuous, and accurate disclosure to their end users regarding the data collected and accessed by Kubian as part of their service.

At a minimum, this disclosure must include a reference to or summary of the data collection practices described in this Privacy Policy, including but not limited to:

• The collection of hardware device identifiers, Widevine DRM signals, and security attestation data — and that Android ID is app-scoped, while the Widevine MediaDrm ID is cross-application: the same device presents the same Widevine ID in different applications, and Kubian can trace a device across applications through that ID for security, ban enforcement, and deletion purposes (not for advertising)
• The issuance, retrieval, and application-side use of permanent 16-digit device account identifiers (user_account_id) that persist across reinstalls and are scoped to each individual application — where the Developer holds an approved Account ID Collection grant (including "Other — Device-Bound Accounts")
• The existence of the Data Collection Request process: permanent account identifiers are withheld from an application unless the Developer has submitted a request stating its purposes, justification, and retention period, accepted the binding purpose-limitation agreement, and received Kubian approval; approved access is logged in an audit trail, expires after one (1) year, and can be revoked at any time
• The generation and use of project-scoped unique device identifiers
• The execution and enforcement of application-level device bans utilizing these unique identifiers, permanent account IDs, and internal hardware identity linkage
• The 60-day retention window applicable to project-scoped unique identifiers, and the automatic anonymization of raw device identifiers after 60 days of per-application inactivity (with seamless reinstatement on next sign-in via securely keyed hashes)
• The Developer's own responsibility as authoritative Data Collector for end-user deletion requests, including forwarding them to Kubian per application via POST https://api.kubian.app/privacy/admin/enduser-deletion, and the cross-application deletion process described in Section 10 (Kubian will delete all lawful Kubian-held records for a device once it can be located from a traceable identifier, except ban and security records)
• The use of device integrity signals for security, user account verification, anti-cheat, and fraud prevention purposes
• The integrity verdicts and patch-level signals (OS, vendor firmware, and boot patch levels) the Developer's backend receives inside signed verification tokens — and that raw certificates, certificate chains, and raw hardware identifiers are never included in those tokens

Developers are required to either directly incorporate the relevant provisions of this Privacy Policy into their own application privacy policy or provide a clearly accessible link to Kubian's Privacy Policy located at https://kubian.app/Privacy-Policy.

Failure to provide adequate disclosure to end users constitutes a material breach of the Developer's obligations under Kubian's Terms of Service. In the event that Kubian or Static Labs LLC incurs any legal liability, claim, regulatory action, fine, penalty, or enforcement action arising from or related to a Developer's failure to properly disclose Kubian's data collection practices to their end users, the Developer agrees to:

• Indemnify and hold harmless Kubian and Static Labs LLC from and against any and all resulting claims, damages, losses, costs, and legal fees
• Accept full legal and financial accountability for any harm suffered by end users resulting from the Developer's non-disclosure
• Cooperate fully with any regulatory inquiry or legal proceeding arising from the Developer's failure to comply with this obligation

Kubian reserves the right to suspend or terminate access to its services for any Developer found to be in violation of this disclosure obligation, without prejudice to any other legal remedies available.

8. Children's Privacy (COPPA) & Developer Safe Harbor

App Developer Responsibility: As between Kubian and a Developer under this Policy, a Developer is not treated as knowingly directing Kubian services to children under 13 where an end-user or player under the age of 13 accesses their application or Kubian services without the Developer's knowledge, direction, or intent. This contractual allocation does not determine liability under applicable law (including COPPA or other privacy statutes), which depends on the facts and applicable legal requirements. Developers remain responsible for meeting their own legal obligations, including providing required notices and age-gating where applicable.

Underage Protection & Active Blocking: Kubian services are not directed to children under 13. Where an end-user or player is identified as being under the age of 13, Kubian will perform to the best of its technical capabilities to block or restrict their interaction with Kubian Services. To enforce these protections, Kubian processes the minimum technical signals strictly necessary to maintain the block (which may include limited device hardware identifiers, user_account_id records, and IP metadata) solely to filter out, drop, or restrict processing for underage sessions. Such data is maintained in a secure, localized in-server store, is not used for advertising, profiling, or unrelated purposes, and is kept only as long as reasonably necessary to maintain the block, subject to Sections 6 and 9.

Disclaimer on Intentional Evasion & Device Modification: Because hardware attestation relies on persistent technical signals, if an underage end-user deliberately circumvents detection checks—such as by performing a factory reset on their device, altering their device fingerprint, or modifying their network location/IP to bypass security controls—such evasion alone shall not be deemed a breach of this Policy by Kubian or the Developer. Obligations under applicable privacy laws remain determined by the facts and applicable law. Kubian utilizes Widevine MediaDrm ID to generate the persistent user_account_id that persists across factory resets, app uninstalls, cache clears, and user profile changes, making identity evasion significantly more difficult. However, on certain low-end devices, modified environments, or devices without a proper Widevine implementation, identifier behavior may vary.

If an underage user is subsequently discovered to have bypassed detection, Kubian will exercise its best efforts to promptly reinstate the block, terminate active token sessions, and restrict further interaction to the fullest extent technically possible.

9. User Rights & Legal Exceptions (OCPA)

In accordance with Oregon law (OCPA), eligible users have the right to access, correct, or request deletion of their personal data held by Kubian, as well as request a portable copy of their data. To exercise these rights, please submit a request through the official dashboard support channel or contact us directly at [email protected].

Statutory Security Exceptions to Deletion: Pursuant to applicable state privacy laws, Kubian reserves the right to deny or limit data deletion or access requests where retaining the specific data is necessary to:

• Detect, prevent, or investigate security incidents, unauthorized system access, or infrastructure abuse;
• Protect against malicious, deceptive, fraudulent, or illegal activity, and enforce active developer-directed or platform-level device bans;
• Maintain the technical integrity, cryptographic validity, and attestation security of Kubian services; or
• Comply with legal obligations, ongoing law enforcement inquiries, or legal defense requirements.

Data retained under these legal exceptions will remain strictly isolated and used exclusively for security, anti-fraud, and compliance purposes.

Deletion Requests for Banned Devices: Pursuant to applicable state privacy laws (including the Oregon Consumer Privacy Act), Kubian reserves the right to deny deletion requests in whole or in part where retaining device signals, user_account_id values, cryptographic signatures, or attestation records is necessary to maintain active developer-directed or platform-level device bans, investigate fraudulent activity, protect system integrity, or protect security infrastructure where a device has been marked as abusive or flagged for infrastructure abuse. Upon processing a deletion request for a banned device, all non-essential data will be purged, while minimal, isolated cryptographic hashes of device signals — stored exclusively in a dedicated ban-enforcement repository separate from standard operational data stores — will be permanently retained solely for anti-abuse and ban enforcement. These hashes cannot be reversed to reconstruct the original device signals and are used only to verify that a previously banned device remains blocked.

10. Application Publisher Practices & Where to Learn More

Kubian provides device attestation, account identification (including the user_account_id), security, and related infrastructure services described in this Policy to Developers who integrate Kubian into their own applications. Kubian acts as a service provider to these Developers; Kubian does not control, and is not responsible for, an application publisher's own independent data collection, use, or sharing practices that fall outside of Kubian's services.

Deletion Upon Notification (Developer Responsibility & Automated API): Because Kubian acts solely as the authoritative Data Processor and only processes data the Developer, as authoritative Data Collector, instructs it to collect (Section 0), full end-user data deletion requires action by you, the Developer. You must maintain a proper per-application data-deletion system with adequate guardrails and, upon receiving an end-user deletion request, notify Kubian so your application's Kubian-held records are deleted — either by contacting us or by calling the automated developer API:

POST https://api.kubian.app/privacy/admin/enduser-deletion
Headers: access-token: KB|<app_id>|<app_secret>
JSON body: {"user_account_id": "<16-digit project-scoped id>", "unique_id": "<project unique id>"} (at least one of the two identifiers is required; when both are supplied they must belong to the authenticated project). A successful call deletes that end user's lawful Kubian-held records for that device. When the supplied identifier can be traced to the device's Widevine ID, deletion covers Kubian-held records for that device across applications, not only the authenticated project, preserving active ban-enforcement, abusive-device, and security-infrastructure records as pseudonymous hashes where applicable.

When a Developer notifies Kubian that a specific end user's data should be deleted (for example, following an end user's request made directly to the Developer), Kubian will delete the corresponding lawful Kubian-held records for that device, across applications where the device can be located from a traceable identifier, in accordance with the retention and deletion provisions of Sections 6 and 9, subject to the security and legal retention exceptions described in those Sections.

Cross-application identification via the Widevine ID: Kubian can track a device across applications through its Widevine ID (Section 1). A deletion request that provides a traceable identifier — that game's project-scoped unique ID, a linked in-game account ID, or a permanent user_account_id — can therefore delete all lawful Kubian-held records for that device across applications, subject to the ban and security exceptions in Sections 6 and 9. A request that provides no traceable identifier, or an identifier Kubian cannot link to a device, can only be honored for the records Kubian can reliably identify. Developers should still forward deletion requests for their application, and end users should review each application's own privacy policy for that publisher's independent records, which Kubian cannot delete.

Because each application publisher may collect, use, or share information independently of, and in addition to, the data processed through Kubian's services, end users should always review the privacy policy published by the specific application they are using to fully understand that publisher's own data practices.

11. Changes to This Privacy Policy

We may update this Privacy Policy from time to time. Material changes — including any new categories of data collected — are published as a new policy version, and continued use of the service after posting constitutes acceptance of the updated policy. Developer accounts may be asked to accept the current version before continuing to access the dashboard.

---

© 2026 Static Labs LLC. All rights reserved.  ·  Oregon, USA