Privacy notice

Written for school leaders, data protection officers and network managers. In short: School Data processes no personal data of its own, sends nothing anywhere by default, and only ever touches a cloud account when a user deliberately signs in.

The short version

There is no account unless you choose to create one, and no account is created by School Data itself.
There are no analytics, no advertising, no tracking pixels and no cookies for any purpose.
By default, work stays on the device — in the browser's own storage or as a downloaded file.
No third-party script is loaded at all until a user presses a sign-in button.
If a user signs in, School Data reads and writes only its own folder in that user's Google Drive or OneDrive.

What is stored on the device, and where

Browser storage used by School Data
What	Where	Why	How long
Saved work	localStorage, keys beginning `sdata_library_`	So a pupil can reopen their work on the same computer	Until deleted from the Open window, or the browser data is cleared
Recovery copy	localStorage, key `sdata_autosave`	So a crash or a closed lid does not lose a lesson's work	Cleared as soon as the work is saved, or on sign-out
Display preferences	localStorage, keys beginning `sdata_pref_`	So high contrast and larger text do not have to be set every lesson	Until the browser data is cleared
Print options	localStorage, key `sdata_print_options`	So paper size and margins are remembered	Until the browser data is cleared
Display name and email of a signed-in user	sessionStorage	To show who is signed in without a network request	Deleted when the browser tab is closed
Access token for Google or Microsoft	Held in memory only — never written to storage	To read and write the app's own cloud folder	Gone the moment the tab is closed or the page is reloaded

Keeping the access token out of browser storage is a deliberate design decision. On a shared classroom computer it means one pupil's account access cannot be inherited by the next pupil to use that machine.

Network requests

With no user signed in, School Data makes requests to its own origin only: the HTML, CSS, JavaScript and icons that make up the app. Nothing else. This is enforced in the browser by a Content Security Policy, not merely intended.

If, and only if, a user presses a sign-in button, the following are contacted:

Google sign-in — accounts.google.com, oauth2.googleapis.com, www.googleapis.com
Microsoft sign-in — login.microsoftonline.com, alcdn.msauth.net, graph.microsoft.com

Network managers can allow or block these independently. If they are blocked, School Data continues to work — the sign-in options simply report that they are unavailable, and saving to the device is unaffected.

What School Data can see in a cloud account

Google Drive. The only scope requested is drive.file, which grants access to files the application itself created, and to files the user explicitly opens with it. It does not grant the ability to list, read or modify anything else in the user's Drive.
Microsoft OneDrive. Microsoft Graph does not offer an equivalent app-scoped permission for personal OneDrive, so the broader Files.ReadWrite scope is requested. School Data confines itself by convention to a single folder named MyData, and every path it constructs is built from a sanitised filename rather than from raw input.
User.Read and openid profile email are requested only to display the signed-in user's name. Nothing else is read from either profile.

The work itself is stored in the school's own Google or Microsoft tenancy, under the school's existing data processing arrangements with that provider. School Data operates no server that receives, stores or processes pupil work.

Children's data

School Data is designed for use by children in primary schools and follows the principle that the safest personal data is the personal data you never collect. It asks for no name, no age, no class, no email address and no identifier of any kind.

A pupil may of course type personal information into their work — a survey of names, for instance. That content is treated exactly like any other work: it stays on the device unless the pupil saves it to their own school cloud account.

Because no personal data is collected, there is no profiling, no automated decision-making, and no data to share with any third party.

Removing everything

Anything School Data has stored can be removed from a device by any of these:

Deleting individual pieces of work from the Open window.
Choosing Sign out and clear this browser when signing out.
Clearing the browser's site data for this address, which removes everything at once.

Work a pupil has saved to Google Drive or OneDrive is deleted from there in the usual way, through that provider or through School Data's own Open window.

Security measures

Served over HTTPS only, with HSTS and preloading.
A strict Content Security Policy with no unsafe-eval and no inline scripts, delivered both as a response header and in the page.
No HTML is ever built from strings: all content is inserted as text nodes, which removes cross-site scripting as a class of defect rather than mitigating it case by case.
Every file opened or imported is rebuilt field by field against a strict schema, with protections against prototype pollution, cyclic data and resource exhaustion.
Exported spreadsheet files are neutralised against formula injection.
The Microsoft sign-in library is pinned with a Subresource Integrity hash, so a compromised content delivery network cannot substitute a modified copy.
Clickjacking, MIME sniffing and cross-origin resource inclusion are blocked by response headers.

Changes to this notice

If School Data ever begins to collect anything, this notice will say so plainly and in advance. The current position — that it collects nothing — is a design decision, not an oversight, and is intended to remain the case.