Privacy notice

Written for school leaders, data protection officers and network managers. In short: School Data keeps pupil work on the device unless a user chooses cloud storage. Signed-in use also sends the limited domain usage records described below to the app’s database.

Signed-in usage reporting

When you use the app while signed in, we record your email domain, an opaque per-tab session identifier, session timestamps, approximate active seconds, and counts of selected feature interactions such as choosing tools or saving. We do not include your email address, keystrokes, filenames or document contents in these usage records. The identifier is generated for each tab session and is not used to track you across apps or websites.

Active time is counted only while the app is visible and focused and you have interacted within the last minute. Usage reports are available to authorized administrators of that app, grouped by domain. Records are stored in the app's Firebase Realtime Database and deleted after 90 days. These approximate figures are for understanding app use, not attendance, assessment or completed work. Signed-out use is not included.

The short version

There is no account unless you choose to create one, and no account is created by School Data Tools itself.
There are no advertising or tracking pixels 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 Tools 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 Tools
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
Cloud Auto-save preference	localStorage, key `sdata_cloud_autosave_enabled`	So the Auto-save on or off choice is remembered on this device	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 Tools 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 Tools continues to work — the sign-in options simply report that they are unavailable, and saving to the device is unaffected.

What School Data Tools 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 Tools 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 Tools operates no server that receives, stores or processes pupil work.

Children's data

School Data Tools 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 or age. Optional sign-in uses an account email for access checks; signed-in usage reporting stores a domain and an opaque session identifier as described above.

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.

Usage reporting is limited to the domain session records described above. It is not used for profiling or automated decisions about pupils.

Removing everything

Anything School Data Tools 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 Tools' 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

This notice describes signed-in domain usage reporting introduced on 25 September 2026. Future changes to data collection will be described here.