Privacy policy – Cubelio
The German and English versions describe the same state of the internal test phase.
Tables can be scrolled horizontally on small screens.
1. Controller and contact
The controller and contact details will be added before the public launch.
The competent supervisory authority and, if applicable, a data protection officer also remain to be added. Information about Apple’s own processing is available in Apple’s privacy policy.
2. What Cubelio processes and where
Cubelio is an adaptive speedcubing learning app. Learning records and history are stored locally on the iPad; cloud copies are added when using a parent account and authorised synchronisation. Local profiles not adopted into an account remain local.
Leagues are hidden in the first version. Granting new league permission is not possible. Previously granted permissions from the internal beta remain stored and can be withdrawn at any time through “Withdraw league permission” in the parent area. This action appears only for currently granted permission. The child sees no league in this app version. The mosaic and fixed nickname remain the profile picture and profile name and are synchronised within the family.
Hiding leagues does not change server processing. The server continues to derive league-eligible XP from synchronised learning events, independently of league permission. Weekly XP is calculated from it. When weekly reassignment runs, weekly XP for existing memberships is stored, rank and promotion/demotion are determined for profiles still enabled, and non-deleted profiles with active league permission are assigned for the following week. Authorised participants with active permission can still receive nicknames, mosaics and weekly XP. For children, current child-cloud consent is additionally required. Whether and when weekly reassignment actually runs in operation remains to be checked.
| Data category | Content and storage |
|---|---|
| Parent account | Email address, password hash in Supabase Auth; account ID, language, consent status and trial start in the cloud. Authentication session locally in the Keychain. |
| Profiles and settings | Fixed nickname, mosaic avatar, child/adult profile, age band instead of date of birth, daily goal, league permission; also currently unused push-setting fields. Local and in Supabase if adopted. No real names, photos, free text or location fields are intended in learner profiles. |
| Devices and pairing | Anonymous Auth user, binding ID, platform, model, pairing/revocation times; persistent random installation identifier for events, loaded at startup and transmitted as installation identifier: Device ID, collected, linked to identity, no tracking, purposes App Functionality; Analytics with research opt-in. Pairing code stored server-side as a SHA-256 hash, valid for 10 minutes. Local and cloud. |
| Learning history | Tasks, attempts, answers, move sequences, times/splits, assessments, selection decisions, versions and timestamps; derived learning state, XP and statistics. Local SQLite and Supabase when synchronised. |
| Local cube connection | Full MAC address and last connected cube only in the local SQLite key-value store. The separate cloud path for solve metadata is described in the next row. |
| Cube in solve events | Only brand and model without a device-specific suffix, e.g. gan:GANi4, locally in solve events and in Supabase on sync; included in the account export and, with current research opt-in, the research export. Same retention as learning events. For the demo cube, only virtual use is recorded. |
| Leagues | No league view in the first version; existing beta permissions remain stored and withdrawable at any time. The server still derives ranked XP and processes weekly XP, rank and membership when rollover runs; API disclosure to authorised participants covers fixed nickname, mosaic and weekly XP, not the account email (details above). |
| Consent and research | Versioned consent/withdrawal receipts with type, time, method and profile scope in Supabase. Pseudonymised research exports require a separate current opt-in; whether research is actually being conducted remains open (to be checked). |
| Purchases and trial | Trial start and entitlements; with subscriptions enabled, store, product, period, purchase time, transaction ID and server-side webhook purchase event in Supabase. Apple/RevenueCat process purchases; the RevenueCat purchase integration is included. The local trial start is adopted by the server when linked to an account; local trial anchors and pending purchase markers are described separately below. |
| Global billing receipts | Refresh and webhook event IDs, type, event and receipt times in Supabase. Refresh IDs contain the parent account UUID. These receipts are retained after account deletion without an automatic deletion period (section 9). They contain no full raw webhook payloads. |
| Local access cache | Last full server access response per signed-in user (parent account or paired learner device), user identifier and fetch time in a local database on the iPad: access status, training permission, feature list, trial and subscription access end including any grace period, and possibly an indication of request throttling. Account deletion removes the parent account’s entry; sign-out retains it. Failed account cleanup is retried via the deletion journal on next start; deleting the app removes app storage (section 9). |
| Local pending purchase marker | One entry per parent account in a local database on the iPad: only the parent account ID and first pending confirmation timestamp in milliseconds, no product information. It remembers a store-accepted purchase awaiting server confirmation across restarts. Until confirmation or expiry after 48 hours, checked on account binding or confirmation retry; physical deletion may wait until the app next runs for this account. Retained on sign-out; removed on account deletion or deleting the app. Failed account cleanup is retried via the deletion journal on next start. Pending restores are not persisted (section 9). |
| Local trial anchors per account or use without an account | A local database on the iPad stores the trial start and observed end per account ID or for use without an account; the latest observed device time is stored separately for the entire installation. The first account to sign in takes the trial anchor from use without an account. No automatic time limit, including after trial expiry; retained on sign-out. Account deletion removes its own anchor and legacy account assignment; failed cleanup is retried via the deletion journal. Other accounts’ anchors and the install-wide device time remain. Deleting the app removes all these local data. Data migration empties legacy trial, account-assignment and expiry data (section 9). |
| Security and deletion | PIN verifier, session, device binding and deletion journal in the local Keychain. Server deletion receipt contains operation ID, hash and deadlines without account/profile ID. |
| Technical diagnostics | Automatically active redacted app log locally; only sharing is voluntary; seen cube names are redacted; Supabase platform logs may contain IP/request and technical metadata and potentially regional information derived from IP addresses. Actual project log fields are to be checked. Apple's own crash/beta data: section 6. |
The random installation identifier and anonymous device login do not make data anonymous: learning and cloud records can be linked through the profile, account or device binding. Research data is pseudonymised personal data, not anonymous individual events. The research export retains the profile UUID, installation ID, and cube brand and model. There is no separate pseudonymisation step. Safeguards, separately held additional information and classification under Article 4(5) GDPR require legal review before a research run.
Legacy data from the internal beta: Older synchronised data still contains Bluetooth names. Cleanup remains open; limiting new data to brand and model does not retroactively change older data.
3. Purposes and proposed legal bases
The following allocation requires legal review before the public launch. Necessity, balancing of interests and any applicable legal obligations still need documentation. The basis is the General Data Protection Regulation (GDPR).
| Purpose | Proposed legal basis / boundary |
|---|---|
| Parent account, agreed service, adult synchronisation and purchase management | GDPR Article 6(1)(b), where necessary for the contract with the adult account holder. No blanket contractual basis for all children's data. |
| Cloud collection for a child profile | Separate documented consent under Article 6(1)(a); observe Article 8 for consent-based services offered directly to children. In Germany, under 16 requires consent/authorisation by the holder of parental responsibility; verification to be checked before public launch. Without this permission, child profiles remain local. The basis for exclusively local child data also remains to be checked. |
| Personal learning state, statistics and adaptive task selection | Contractually necessary service for adults; within the separate parental consent for children's cloud data. Learning use alone does not authorise research reuse. |
| Leagues / display to other participants | Separate permission/consent under Article 6(1)(a), by the holder of parental responsibility for children; display requires active league permission and, for children, child-cloud permission. No new permission in the first version; existing beta permissions remain withdrawable at any time. Hiding leagues does not change the server processing in section 2; whether existing consent wording covers it requires legal review before publication. |
| Cross-user model improvement/research | Separate, voluntary and withdrawable opt-in under Article 6(1)(a); separate parental permission for children, not a condition for training. Current consent is checked before every export. |
| Service security, troubleshooting and evidence of deletion/consent | Article 6(1)(f) proposed for necessary secure operation/evidence, giving particular weight to children's interests; balancing to be checked. Article 6(1)(c) only for an identified legal obligation, not as a blanket basis. Support intake/Apple report downloads to be checked. |
Account creation, pairing, trial and purchase do not constitute consent. A parental PIN alone does not verify parental responsibility. Prior consent is required for cloud collection for a child profile.
Research uses selected pseudonymised practice data to improve learning models across users. The profile UUID, installation ID, and cube brand/model remain. Refusal does not affect personal training. Current, unwithdrawn consent is authoritative; a prior tag marking data as suitable for research is insufficient. Withdrawal prevents further exports. Handling previously exported datasets and resulting models must be clarified before a research run; automatic retrieval is not promised. Aggregated metrics require a separate assessment and do not make the underlying events anonymous.
4. Local storage and section 25 TDDDG
The iPad holds learning history and settings in a local database, the cube cache in local app storage, and authentication/PIN data and the deletion journal in the Keychain. Keychain values are configured as device-bound without iCloud synchronisation, but may survive reinstallation. The behaviour of other operating-system device backups remains to be checked.
For storage and access strictly necessary for explicitly requested offline learning, authentication, PIN protection or pairing, the exception in section 25(2)(2) TDDDG is proposed. Non-essential storage and access may require prior consent under section 25(1), in addition to a GDPR basis. The local diagnostic buffer starts automatically with the app; seen cube names are redacted in it. Only sharing is voluntary. Whether this automatic storage is strictly necessary or requires prior consent remains to be checked, as does future storage by integrated software. Voluntary sharing and operating-system permissions do not replace this assessment.
5. Bluetooth, camera, tracking and advertising
Bluetooth connects to the smart cube and receives its moves and states. No Bluetooth background mode is enabled; Bluetooth is marked as not used for location. The camera is used only to read a pairing QR code; camera images are not uploaded to the cloud. Microphone access is not requested. Manual code entry remains available if camera permission is refused.
Cubelio provides for no advertising and no advertising tracking. Advertising attribution and collection of Apple advertising or vendor identifiers IDFA/IDFV through the corresponding additional calls are not intended. Learning events and RevenueCat billing analytics are distinct from this. Actual behaviour of the integrated software in the finished app build remains to be checked. “No tracking” does not mean “no processing”.
6. Recipients, processors and international transfers
Supabase: Authentication, database, synchronisation and server functions. The intended EU database region is Frankfurt (eu-central-1), currently on the Free plan. EU hosting does not guarantee that all operational and support processing remains in the EU. Supabase describes additional processing and standard contractual clauses. The contracting entity, data processing agreement, subprocessors and transfer assessment remain to be checked. Further information: Supabase on data regions and transfers, data processing agreement and subprocessors.
RevenueCat, Inc., USA: When purchase integration is enabled, RevenueCat manages subscriptions and entitlements and performs billing analytics as a processor. Technical and transaction data is sent to the USA; its data processing agreement provides standard contractual clauses for relevant transfers. Participation in the EU-US Data Privacy Framework has not been verified; no transfer assurance is based on it. Contractual basis, transfer risks and retention require review before activation. The purchase integration is included. On account deletion, the server attempts RevenueCat customer deletion; provider cleanup remains open if configuration is missing or an error occurs. Further information: RevenueCat privacy policy and data processing agreement.
The parent account UUID is used as the custom user identifier for RevenueCat. According to the provider, it processes purchase data and technical information such as device type, operating system and last usage. The integrated software reportedly sends Apple’s tracking permission status (ATT) without prompting for permission. Additional calls for advertising attribution or device attributes are not intended. Automatic behaviour and IP server logs remain to be checked before ruling out further identifiers.
Apple: App Store, purchase handling and its own TestFlight/crash reports. Apple is not characterised as our processor across the board. TestFlight automatically collects crash and usage data and shares it with the developer; tester contact details and comments may also be included. Store crash reports depend on diagnostic sharing. Cubelio uses Apple’s built-in crash channel. The legal basis and retention for our own report downloads remain to be checked. Further information: Apple privacy policy and TestFlight & Privacy.
Other league participants: Despite the hidden league view, authorised participants with existing beta permissions can still receive fixed nicknames, mosaics and weekly XP. Current permissions and authorised membership are required, as described in section 2. Hiding the view does not generally block other families’ server access.
Operations and backups: Encrypted local database backups exist. Other technical operational services and their possible processing of learning data, as well as support hosting and associated logs, remain to be checked. Hosting of these webpages is described under “These pages”.
7. Children and the parent area
Children need no personal email in their learning profile. Nicknames come from a fixed list; avatars have nine mosaic cells with six colours plus empty. The learning and league areas have no free text, photos or chat. Parents control cloud consent and can separately withdraw existing league permissions from the internal beta. New league permissions are not possible in the first version; “Withdraw league permission” appears only for currently granted permission. The child sees no league in this app version. Purchases belong behind the protected parental access. The PIN protects the parent area but does not replace legally valid consent or age/parent verification. The method requires legal review before the public launch.
To be checked before US launch: Classification under the US Children’s Online Privacy Protection Act (COPPA), verifiable parental consent, direct parental notice, handling of third parties and research, and written retention and security rules. This draft, store category, PIN, trial or purchase does not establish COPPA compliance. Further information: FTC on COPPA.
8. Adaptive learning logic
Cubelio derives a learning state from attempts, answers, times and moves and selects suitable tasks. The learning system estimates learning needs and practice intervals; the results are not legal or school assessment decisions. Based on the described product scope, there is no solely automated decision producing legal or similarly significant effects within Article 22 GDPR. This classification remains subject to legal review.
9. Retention
The table describes the currently specified storage locations, periods and deletion routes. Unresolved periods are expressly marked as requiring review. It does not promise new or additional automatic deletion.
| Data category | Location | Period / trigger | Deletion route |
|---|---|---|---|
| Parent account: email, password hash, account ID, language, status, trial start | Supabase Auth / Supabase; session locally in Keychain | Until account deletion; local authentication data on sign-out/cleanup; Keychain can survive reinstallation | In-app account deletion and local cleanup |
| Profile: fixed nickname, mosaic, kind, age band, daily goal, permissions; unused push settings | iPad / Supabase | Until profile or account deletion; no automatic inactivity period | Profile deletion removes content fields; residual marker below |
| Profile deletion marker: profile ID, account link, deletion time, empty mosaic | Supabase | Until account deletion; no separate period evidenced | Account-deletion cascade; prevents restoration of deleted profiles |
| Learning events, moves, times, assessments, selection decisions and derived learning state/XP/statistics | SQLite on iPad / Supabase | Until profile or account deletion; learning state is projected from events; retained after subscription ends | Profile/account deletion; clean local copies on each device |
| Device binding, anonymous Auth user, platform/model, pairing/revocation time, installation identifier | iPad / Supabase Auth and event storage | Binding data until profile/account deletion; revocation blocks access, not complete deletion | Revocation; deletion removes bound Auth users; local identifier/deletion coverage to be checked |
| Pairing code hash | Supabase | Valid for 10 minutes, no automatic physical deletion period evidenced | Profile/account deletion; expired code rejected |
| Leagues: existing beta permissions, weekly XP, rank and membership; server processing continues while the league view is hidden, as described in section 2 | Supabase; no league view in the first app version, API access remains subject to authorisation | Until profile/account deletion; league permission withdrawable at any time. Withdrawal blocks display and further rollover assignments; it does not automatically erase existing XP/membership data | Profile/account deletion; current permissions checked at each display request; review/deletion procedure after withdrawal remains open (section 10) |
| Consent/withdrawal receipts: type, version, time, method, profile scope | Supabase | Until account deletion, including after profile deletion or consent withdrawal | Account-deletion cascade; withdrawal additionally recorded |
| Pseudonymised research data: profile UUID, installation ID, cube brand/model; no separate pseudonymisation step, Article 4(5) GDPR to be checked | Source events in Supabase; export destination to be checked | Source records as learning events; withdrawal blocks further exports; retention/deletion of existing datasets and models to be checked | No blanket retrieval of previously exported data promised |
| Purchase history / entitlements: store, period, transaction ID, server-side purchase event | Supabase; Apple / RevenueCat USA when purchases enabled | Own account-bound server purchase data until account deletion; see separate rows for global receipts and local access data; provider periods and statutory retention to be checked | Own account-scoped deletion; server attempts RevenueCat customer deletion; verify success/provider residual copies separately; cancel subscription separately in App Store |
| Global refresh and webhook deduplication receipts: event ID, event type, event and receipt times; refresh IDs contain the parent account UUID and timestamp; webhooks use their event ID | Supabase | No automatic deletion period or cleanup route evidenced; retained after account deletion. The 90 days for account deletion receipts do not apply here | No automatic removal on account deletion; a period and deletion procedure must be legally defined before publication. These receipts contain no full raw webhook payloads |
| User-bound access cache: signed-in user identifier (parent account or paired learner device), full server response and fetch time; access status, training permission, feature list, trial and subscription access end including any grace period, and possibly an indication of request throttling | Local database on the iPad, separate from local trial status | Last response per signed-in user; overwritten on another fetch. On parent account deletion, that account’s entry is removed; sign-out does not erase it. No automatic time limit; deleting the app removes app storage | Account-scoped local cleanup; failures remain in the deletion journal and are retried on next start. Sign-out clears only in-memory state. Check copies on other devices and operating-system/device backups separately |
| Pending purchase marker: only parent account ID and first pending confirmation timestamp in milliseconds; no product information | Local database on the iPad; one entry per parent account | Until server confirmation or expiry after 48 hours; expiry is checked when the account is bound or pending confirmation is retried. Physical deletion may wait until the app runs for this account again; no background deletion deadline. Retained on sign-out; account deletion or deleting the app removes it | Delete entry on confirmation, observed expiry or account-scoped local cleanup; failed account cleanup is retried via the deletion journal on next start. Pending restores are not persisted |
| Local trial anchor per account or use without an account: account assignment or use without an account, start and observed end; latest device time separately | Local database on the iPad; trial anchors and separate install-wide device time | No automatic time limit, including after trial expiry; retained on sign-out. The first account to sign in takes the anchor from use without an account. Account deletion removes that account’s anchor and legacy account assignment; other accounts’ anchors and the install-wide device time remain. Deleting the app removes all these local data | Account-scoped cleanup; failed deletion is retried via the deletion journal on next start. Data migration empties legacy trial, account-assignment and expiry data; the emptied storage structures remain in place |
| Account deletion receipt: operation ID, capability hash, completion/expiry; no account/profile ID | Supabase | Valid for 90 days; physical pruning daily at 03:17 UTC after expiry | Automatic cleanup; job failure may delay physical removal |
| PIN verifier, Auth token, device binding, account-bound deletion journal | iPad Keychain | Function/account-bound; journal until deletion resolved and local cleanup completed; no fixed number of days; may survive reinstallation | Account-bound cleanup; complete coverage of each key to be checked |
| Full cube MAC and last connected cube | Local SQLite key-value store only | No automatic period evidenced; removal by profile/account deletion to be checked | Remove app storage; consider Keychain separately |
| Cube brand and model in solve events (without a device-specific suffix) | SQLite on iPad / Supabase events; account export and research export with research opt-in | As learning events: until profile or account deletion; separate period for exported research datasets to be checked | Profile/account deletion; clean local and exported copies as learning/research data |
| App log: automatically active technical diagnostics, seen cube names redacted | iPad only, two alternating text files | Ring buffer of 300 newest lines, no day limit; previous file generation may persist until next write | Overwrite/rotation; manual export only; recipient copy separate |
| Local diagnostic export | App cache on the iPad | Until the next diagnostic export or iOS cache cleanup; no fixed deletion period | Delete export folder before next export; no deletion immediately after sharing evidenced; recipient copies separate |
| Temporary JSON account export | App cache on iPad | At most 3 files; iOS deletes after share sheet dismissal; other adapter mode has 10-minute grace; next cleanup if app paused | Cleanup on start/resume, timer or account deletion; recipient retains copies they save |
| Supabase platform logs, including possible IP/request metadata | Supabase logging | Accessible log window under the plan: Free 1 day for API/database logs, 1 hour for Auth Audit Logs; not a guaranteed deletion period. Actual provider retention and project fields to be checked | Provider rotation and actual deletion to be checked; no immediate per-account erasure promised |
| Optional Auth audit database copy, including user ID and IP | Supabase | Activation and actual retention in the Cubelio project to be checked; the plan log window is not a deletion period for this copy | Configuration, deletion route and period to be checked |
| Encrypted database backups including account, profile and authentication data | Encrypted local database backups | Two monthly snapshots, up to approximately 2 months after deletion with successful monthly rotation; no fixed maximum if runs fail | Rotation after successful backup; reapply deletions before returning a restore to service, procedure to be checked |
| Provider backups / internal residual copies at Supabase and RevenueCat | Provider | Separate periods to be checked; not equivalent to our two monthly snapshots | Provider process/DPA; account deletion receipt does not cover them |
| Apple TestFlight/Store crash reports, beta usage data/comments | Apple; possible developer downloads | Apple: beta comments 1 year, crash/usage data possibly until bugs resolved; own downloads/Store periods to be checked | Apple procedure and separate handling of data subject requests |
| Logs/export files manually sent to support | Recipient chosen by user | No own support retention process evidenced yet: to be checked | Define recipient procedure; automatic upload not evidenced |
The accessible log window must be updated when the plan changes; it is not a guaranteed deletion period.
10. Your rights, export, deletion and withdrawal
Subject to the legal conditions, you have rights of access, rectification, erasure, restriction, portability, objection to processing based on legitimate interests, and complaint to a supervisory authority. The controller and contact details will be added before the public launch. Consent may be withdrawn for the future; the lawfulness of earlier processing is unaffected.
In the parent area’s Data & Account (Daten & Konto) section, you can view stored data, request a JSON account export, and delete the account. Profiles can be deleted separately. The export contains personal account data and learning history; it is not a research export or a complete retrieval of all data held by Apple or RevenueCat. Further access may be requested from the controller once contact details have been added.
Child-cloud, research and league permissions may be withdrawn separately. Existing league permissions from the internal beta remain withdrawable at any time in the parent area; granting new permission is not possible in the first version. Hiding leagues alone changes neither stored permissions nor server processing. League withdrawal blocks league display through the server and prevents further weekly assignments, but does not automatically erase existing XP and membership data. Child-cloud withdrawal blocks new collection and device access; research exports are checked against current consent. Technically, withdrawal alone does not automatically delete existing personal learning events; profile or account deletion is additionally available.
After withdrawal, we review further storage and delete the data unless an independent legal basis or statutory exception applies. No additional erasure request is required. The necessary review and deletion procedure is still missing and must be legally clarified before the public launch. See EDPB Guidelines on consent, paragraphs 117–119.
A successful account deletion removes the associated account-bound live data and bound authentication users, with these exceptions: global refresh and webhook deduplication receipts remain without an automatic deletion period; refresh IDs contain the parent account UUID.
On this device, deleting a parent account also removes that account’s access-cache entry, pending purchase marker and trial anchor including the legacy account assignment. Failed local cleanup remains in the deletion journal and is retried on next start. Sign-out does not erase these stored access data; other accounts’ trial anchors and the install-wide device time remain. Deleting the app removes all these local access data.
The 90-day validity applies only to the separate account deletion receipts, not to global billing receipts or the local access cache (section 9). Profile deletion leaves a minimal marker and consent receipts until account deletion. Existing offline copies, provider residual copies and our monthly backups need separate cleanup. Immediate remote erasure on offline devices is not promised.
Subscriptions must be cancelled separately in the App Store. The server attempts RevenueCat customer deletion and reports its status; successful account deletion does not confirm complete provider cleanup.
11. Changes and outstanding information
Before the public launch, controller and contact details, support, transfer and retention issues, and child verification must be completed and legally reviewed. Changes to features, integrated software or recipients require a fresh alignment of this policy with consent wording and Apple privacy disclosures. This draft does not constitute legal approval.
Before publication, hosting logs, recipients and contractual terms, as well as the applicable data processing and transfer agreements, also require review. Hosting of the German and English draft pages on GitHub Pages is planned; public availability has not yet been verified.
These pages
These pages are hosted on GitHub Pages (GitHub, Inc.). When you access them, GitHub processes technical data such as your IP address. Further information is available in the GitHub General Privacy Statement. Cubelio does not set cookies or use tracking on these pages.