Keep the data collected for learner accounts limited and explain the purpose of each field.
For schools worldwide • principals • teachers • IT
School security & privacy, with a global view.
iLearn Maths is being developed for international school use. This page explains the current account, learner-data, hosting and security model and highlights regional privacy frameworks a school may need to consider before adoption.
International readiness
Global availability is not the same as global certification
Privacy, child-safety, procurement and data-residency requirements differ by country, state, province and school system. iLearn Maths does not claim blanket worldwide legal compliance, government approval or a certification that has not been independently awarded.
Before selling into a new jurisdiction, confirm the local rules that apply to children, schools, contracts and data processing.
Where required, provide local privacy notices, data-processing terms, retention commitments and procurement answers.
Data minimisation
What information iLearn Maths uses
The standard student account is intentionally simple. iLearn Maths needs enough information to identify the learner inside the organisation, provide access and remember learning progress.
| Information | Why it is used | Standard student account |
|---|---|---|
| Learner display name | Lets authorised adults recognise and manage the learner in the dashboard. | Used |
| Generated username | Provides the learner with an iLearn Maths sign-in identity. | Used |
| Password credential | Authenticates access. Passwords are stored in the database as salted bcrypt hashes. | Used |
| Class membership | Groups learners within an organisation for classroom management. | Used when assigned |
| Lesson and question progress | Remembers answered questions, current activity/question and lesson completion. | Used |
| Student email, phone, home address, date of birth or photo | Not required by the current iLearn Maths student account model. | Not required |
Technical controls
How access is protected
These controls are present in the current iLearn Maths Firebase/Supabase implementation.
Protected content checks
Secure dashboards and paid lesson paths are served through Firebase Functions. The server checks the signed-in session, account role and content package before returning protected files.
Hashed passwords
Managed account passwords are written to Supabase using PostgreSQL pgcrypto bcrypt hashing with a generated salt. Login verification happens on the server.
Signed session cookies
Sessions use an HMAC-signed cookie. On the live HTTPS site the cookie is marked HttpOnly, Secure and SameSite=Lax so JavaScript cannot read the session token.
Role-based server permissions
Owner, school administrator, teacher, parent and student roles are checked on server endpoints. School and home accounts are separated by organisation identifiers.
Database access stays server-side
The browser does not receive the Supabase service credential. Database tables used for organisation, class and lesson progress data are configured for restricted server access in the project setup.
Login attempt limiting
The Firebase API applies a basic login-attempt limit of 10 attempts per minute per observed client address before returning a temporary 429 response.
Resumable progress
Progress is stored per signed-in account, including the current activity/question and saved question state. Learners can return later to unfinished work.
Browser security headers
The deployed configuration sets nosniff, same-origin framing and strict-origin-when-cross-origin referrer controls, and prevents API/protected responses from being cached.
School account structure
Who can do what
School accounts separate administration, teaching and learning roles.
Set up the school
Manages the organisation and teacher accounts within the school licence and seat limits.
Manage learners
Adds learners, assigns classes, creates or resets student credentials and prints selected sign-in cards together.
Learn and continue
Uses an assigned username/password to access permitted lessons. Question-level progress is stored against that individual account.
Cloud services and data location
Where the current platform runs
International schools may have data-residency or cross-border transfer requirements. The current technical location should therefore be reviewed as part of procurement.
Website hosting and server functions
Firebase Hosting serves the public site. Firebase Cloud Functions performs login/API processing and protects secure dashboards and lesson content. The functions in this project are configured for the australia-southeast1 region.
Account and progress database
Supabase stores organisation, account, class and lesson-progress records. Server functions communicate with Supabase over HTTPS. The production project’s exact database region should be confirmed before making a data-residency commitment to a school.
Regional privacy frameworks
What schools in different regions may need to review
These links are starting points for school due diligence, not a statement that every law listed applies to every iLearn Maths customer. Applicability depends on location, age, account model, contractual role and data flows.
New Zealand
Regional guidanceSchools may review the Privacy Act 2020, the Privacy Commissioner’s education-sector children’s guidance and the Ministry of Education’s Safer Technologies for Schools (ST4S) framework.
Australia
Regional guidanceSchools and providers should review the Australian Privacy Principles and current OAIC guidance for children’s online privacy. Australia is developing a Children’s Online Privacy Code, so requirements should be rechecked as the framework progresses.
United Kingdom
Regional guidanceOnline services likely to be accessed by children may need to consider UK data-protection requirements and the ICO Children’s Code. The ICO specifically provides guidance for education technology.
European Union / EEA
Regional guidanceThe GDPR provides additional safeguards for children’s personal data. Where processing relies on consent for online services, parental-consent age thresholds can vary between EU member states.
United States
Federal + local reviewCOPPA can apply to online services directed to children under 13 or with actual knowledge they collect personal information from children under 13. Schools and education technology providers may also need to consider FERPA and state or district requirements.
Other countries and school systems
Local reviewBefore onboarding a new region, iLearn Maths and the purchasing school should identify the applicable child-privacy rules, school procurement requirements, data-residency expectations and contractual terms.
International procurement checklist
Before a larger school or district rollout
As iLearn Maths expands, these are the documents and decisions that should become part of the standard school package.
Privacy & retention
- Formal privacy policy
- Defined retention/deletion periods
- Account offboarding process
- Privacy contact
School data terms
- Data Processing Agreement where needed
- Subprocessor list
- Cross-border/data-residency information
- Incident notification commitments
Local requirements
- Child privacy rules
- School or district vetting
- Local accessibility expectations
- Learning pathway and terminology mapping
School FAQ
Common questions from school leaders and IT teams
Do students need an email address?
Does iLearn Maths sell student information or use it for advertising?
Is iLearn Maths approved or accredited by every country’s education authority?
Can a teacher reset a learner password and print login cards?
Does progress follow the learner?
How long is information retained and how is deletion handled?
Where is data hosted?
Planning to use iLearn Maths in your country?
Send your school’s privacy, security, learning pathway or procurement questions. The international documentation can be developed around the regions where schools are actually adopting iLearn Maths.
International security & privacy overview updated August 2026.
