We are committed to protecting the privacy and data sovereignty of every student, teacher, parent, and school on UbuntuPlay.
Core design principle: UbuntuPlay is built offline-first. The Classroom Server runs entirely on a teacher's local device. Student learning data is processed locally and never leaves the school unless you explicitly sync aggregated, anonymised reports to the Hub.
UbuntuPlay is a dual-tier educational platform for schools in Zambia and across Africa. It consists of:
Data Controller: Zipangile, a software company registered in Zambia. Our principal product is UbuntuPlay.
Founder & Developer: Sobhuza Ziba
Privacy Contact: privacy@zipangile.com
Legal Contact: legal@zipangile.com
Postal: Zipangile, Lusaka, Zambia
This policy governs all data processing activities associated with the UbuntuPlay platform, including the Classroom Server, Hub, Parent Portal, Developer Portal, Organisation Portal, and Android applications.
The data we handle varies by the type of user and the tier of the platform (local Classroom or cloud Hub).
| Data Type | Where Stored | Transmitted to Hub? |
|---|---|---|
| Student game scores & progress | Local Classroom Server | Never |
| Student display names / identifiers | Local Classroom Server | Never |
| Tutor chat / AI session history | Local Classroom Server | Never |
| Teacher name & email | Local Classroom Server (encrypted) | Never |
| School name, province, plan | Hub (encrypted) | Yes — registration |
| Anonymised aggregate stats | Hub | Yes — periodic sync |
| Teacher translation contributions (UI strings) | Hub (translation corpus) | Yes — optional, on by default |
| Parent account & child profiles | Hub (encrypted) | Yes — parent portal |
| School-linked child progress | Hub (pseudonymised weekly totals) | Yes — with teacher approval |
| Billing & licence records | Hub (encrypted) | Yes — billing only |
| Gogo AI inference input/output | Browser memory only | Never |
Understanding data flow is critical to understanding your privacy on UbuntuPlay:
When a teacher opens the Classroom Server, all student activity is stored in JSON files on the teacher's local device. No internet connection is needed for lessons, game play, or AI tutoring. Data stays on the device indefinitely unless the teacher or head teacher explicitly exports or deletes it.
Periodically, the Classroom Server sends a heartbeat to the Hub. This heartbeat includes only:
Alongside the heartbeat, schools that have community translation sharing enabled (the default) push their Translation Editor contributions — interface strings only, see Section 9.
A parent may request a school link for their child. This flow requires explicit teacher approval. Once approved, the Classroom Server computes pseudonymised weekly aggregates (total minutes, games played, average accuracy) for that child — the child's name and identifier are not included — and includes them in the next heartbeat. The Hub stores these as progress data on the child's profile, visible only to the parent.
The Gogo AI tutor runs entirely inside the teacher's browser using WebAssembly (LiteRT-LM with Gemma 4 E2B). No student input, AI prompts, or responses are transmitted to any server — the model runs locally in the browser's memory. See Section 8 for full details.
We apply encryption at multiple layers across the platform:
All PII fields — including names, email addresses, phone numbers, addresses, and contact information — are encrypted at rest using AES-256-GCM with a randomly generated, per-instance 256-bit key. The encryption key is stored on the server's local filesystem with mode 0600 (owner-read only). Sensitive fields are automatically identified and encrypted before writing to disk and decrypted transparently when read by authorised server processes.
School licence keys are signed and verified using Ed25519 asymmetric cryptography. The signing private key never leaves Zipangile's infrastructure. Schools hold the public verification key, which allows offline validation without any network call.
All communication between devices and the Hub uses HTTPS with HSTS enforced (1-year max-age, includeSubDomains, preload). The Classroom Server automatically provisions a self-signed TLS certificate covering all active LAN IP addresses and serves the classroom interface over HTTPS on the local network.
Hub authentication is managed by Better Auth (self-hosted), using bcrypt-hashed passwords and signed session cookies. Session tokens are rotated on each authentication event. Rate limiting, IP blocking, and CSRF protection are applied to all authentication endpoints.
Scheduled encrypted backups of Hub data are taken automatically. Backup archives are encrypted before storage. Backup management tools are available via the Hub Admin panel.
UbuntuPlay is designed for use in schools. All student data is managed by the school (as data processor) under the supervision of the head teacher. Zipangile does not directly collect, access, or process individually identifiable student information.
UbuntuPlay supports students of all ages, including children under 13. We take children's privacy extremely seriously:
UbuntuPlay collects minimal, privacy-respecting analytics to help improve the platform and support impact reporting for schools, NGOs, and government partners.
Detailed per-student analytics (game scores, session lengths, accuracy trends) are stored locally on the Classroom Server and are never transmitted externally. Schools and teachers can view, export, and delete this data at any time from the Teacher Dashboard.
The Hub receives only aggregated, school-level statistics: total learning minutes, total sessions, number of active students (count only, no names), and subject-level accuracy averages. This data cannot be used to identify any individual student.
Individual game sessions on the Classroom Server log anonymised events (game ID, subject, grade, duration, score, level) associated with an internal pseudonymous student ID. These events power the local analytics dashboard. When synced to the Hub, only the aggregated school totals are included — never individual session records.
We log standard server access metadata (IP address, endpoint, timestamp, HTTP status) for security monitoring, rate limiting, and abuse detection. These server logs are retained for 90 days and are not used for marketing purposes.
UbuntuPlay does not use Google Analytics, Facebook Pixel, or any third-party behavioural tracking service. There are no advertising trackers on any part of the platform.
The Gogo AI tutor is a core feature of UbuntuPlay. We have designed it with a privacy-first architecture:
The AI model runs entirely inside the teacher's browser as a WebAssembly (WASM) module. The Gemma 4 E2B model is downloaded once and cached locally. All inference — question generation, tutoring responses, study plans — happens in the browser's memory.
The Gogo Bridge is a local WebSocket connection between the Classroom Server and the teacher's browser (where the WASM model runs). All traffic flows over the local network or localhost. No bridge traffic is routed through the internet.
For Zambian language translation (Bemba, Nyanja, Tonga, Lozi), the Classroom Server may optionally use an NLLB-200 translation service running on the local network (port 5001). This service is entirely local — translations are not sent to any external API. If no local translation service is available, the platform falls back gracefully to English.
When a teacher uses the Game Builder to generate quiz questions or lesson content, prompts are processed locally via the Gogo Bridge. The teacher is responsible for reviewing and approving any AI-generated content before deploying it to students.
What we collect: when a school saves local-language translations in the Classroom Server's Translation Editor and the school is connected to the Hub, those translations are shared with UbuntuPlay: the English source string, the human translation, the language (Bemba, Nyanja, Tonga or Lozi), the interface string identifier, the contributing school's ID and name, and timestamps. Nothing else — never learner or teacher personal data.
Teachers' corrections are pooled into per-language translation corpora on the Hub. We use them to (a) improve the locale packs shipped to every school, and (b) build and train Zambian-language translation and AI models (for example, fine-tuning the offline translation models that power the platform). Contributions from multiple schools are cross-checked against each other — a translation confirmed by several schools carries more weight.
Contributions are validated on arrival (machine-translation artifacts, encoding damage, and structurally broken values are rejected), de-duplicated into per-language corpora, and periodically archived as timestamped dataset snapshots. These corpora and datasets may be used to train and evaluate translation/AI models and to build the shipped language packs. Published datasets or models, if any, would contain only the string pairs and aggregate provenance (for example, the number of confirming schools) — school identities are retained internally for consensus tracking and credit.
Sharing is enabled by default and disclosed in the Translation Editor, the teacher Settings page, and the school's Data Sharing Agreement. The head teacher can disable community translation sharing at any time in Classroom Settings — translations then remain purely local to the school and continue to work exactly the same on that server. Schools may also request deletion of their previously contributed pairs by contacting us (see Contact Us).
The Parent Portal allows parents and guardians to create accounts on the Hub to monitor their children's educational progress.
When a parent registers, we collect: email address (required), password (bcrypt-hashed, never stored in plain text), and optional display name. This data is stored on the Hub with PII fields encrypted at rest.
Parents may create child profiles including a display name, grade level, and optional school association. Child profiles are stored on the Hub with name fields encrypted at rest. Child profiles on the Hub contain no biometric, health, or sensitive personal data.
If a parent requests a school link and a teacher approves it, the Classroom Server transmits pseudonymised weekly learning summaries (total minutes, games played, average accuracy — no names or individual session data) to the Hub. This data is stored on the child's profile and is visible only to the parent. The parent or teacher can revoke this link at any time.
Subscription payments for Family Plus and Family Premium plans are processed by Flutterwave. UbuntuPlay does not store card numbers, bank account details, or mobile money credentials. We receive and store only: plan tier, payment status, payment reference number, and billing dates. See Section 11.
If you subscribe to Family Plus or Premium, we send transactional emails (weekly digests, progress reports, licence expiry notices) via Resend. You can opt out of digest emails at any time from your dashboard settings. Transactional emails related to your account (billing, security alerts) cannot be opted out of while your account is active.
Family Premium subscribers may configure screen-time schedules and daily limits for their children. These settings are stored on the Hub and are used only to control access to the games route on the platform. They are not shared with any third party.
We use a minimal set of third-party services. Below is a complete list:
| Service | Purpose | Data Shared | Privacy Policy |
|---|---|---|---|
| Fly.io | Cloud hosting for the Hub server | All Hub server data (stored in Fly.io volumes in Johannesburg, South Africa — region jnb) | fly.io/legal/privacy-policy |
| Flutterwave | Payment processing (ZMW) | Payment amount, email, plan type — no card data stored by UbuntuPlay | flutterwave.com/privacy-policy |
| Resend | Transactional email delivery | Recipient email address, email content (progress digests, licence notices) | resend.com/privacy |
| Better Auth | Authentication engine (self-hosted) | Runs on Fly.io — no data sent to Better Auth's servers. Authentication is self-hosted. | Self-hosted — no third-party data transfer |
We do not use Facebook, Google Analytics, advertising networks, data brokers, or any behavioural analytics services. We do not sell data to third parties under any circumstances. All fonts are self-hosted — no font requests are sent to third-party CDNs.
All data on the Classroom Server is retained until the school or teacher deletes it. There is no automatic deletion. Schools are responsible for managing their local data in accordance with their own data governance policies. The Classroom Server provides export and deletion tools in the Teacher Dashboard.
School registration data and anonymised aggregate statistics are retained for the duration of the school's licence plus a 2-year archive period, after which the data is deleted. Upon licence termination, the school may request immediate deletion of all associated Hub records.
Parent accounts and child profiles are retained until the parent deletes their account. After account deletion, all personal data is purged within 30 days. Subscription transaction records (amount, date, reference) are retained for 7 years for financial compliance purposes — these records do not contain PII beyond the subscription email address.
Server access logs (IP, endpoint, timestamp) are retained for 90 days and then automatically deleted.
Encrypted Hub backups are retained for up to 90 days in a rolling window.
Depending on your location and applicable law, you may have the following rights regarding your personal data:
To exercise any of these rights, contact us at privacy@zipangile.com. We will respond within 30 days.
We believe schools and organisations should own and control their data. This is a core principle of the UbuntuPlay platform architecture:
The UbuntuPlay Hub is hosted on Fly.io in Johannesburg, South Africa (region: jnb). Server data at rest is within Africa.
The following services may involve data transfers outside Zambia:
We take care to select service providers that offer adequate data protection standards. Where possible, we use providers with African infrastructure or data processing agreements.
We may update this Privacy Policy from time to time to reflect changes in the platform, applicable law, or our data practices. When we make material changes, we will:
Continued use of the platform after the effective date of an updated policy constitutes acceptance of the changes.
If you have any questions about this Privacy Policy, want to exercise your data rights, or wish to report a data protection concern, please contact us:
We aim to respond to all privacy enquiries within 30 days.
See also: Terms of Service · Cookie Policy · Acceptable Use Policy