Reference · generated from the product

Where a student record sits, and what it takes to move one

Six components hold student data, and one boundary separates the district’s own devices from everything else. Everything on the district side is encrypted at rest, and crossing the boundary requires two independent conditions to hold at the same time.

Source. Components, tiers and the gate condition are read out of the shipped configuration.Where a claim carries no verified citation the badge says so rather than the page implying one.

The horizontal line is the boundary. As shipped, everything above it stays on the district’s own devices.

above the line · the network

Static host (Cloudflare Pages) no student data

District audit relay no student data not configured

No box here holds a student record, because no such component exists to draw. This is the SHIPPED DEFAULT and a district can turn egress on. The accurate claim is that egress is district-configured and off by default, gated on a recorded DPA attestation — not that the product is incapable of it.

the device boundary

1 local shipped default

2 local+meta metadata only

3 zk-cloud gated

4 custodial gated

District configuration BOTH dc.provisioningAttested === true AND an https:// dc.auditRelayUrl. The two PII-egress tiers ('custodial', 'zk-cloud') degrade DOWN to 'local+meta'. Fail-safe, not fail-open.

below the line · this device

Browser localStorage holds student data The state root S, serialized. PII fields carry Stage-F envelope encryption.

Browser IndexedDB holds student data Six stores under StorageManager: roster, caseload, groups, config, snapshots, yearHistory — plus documents, the action store and the audit log. Encrypted with the per-device key.

Device keyring holds the key only AES-GCM 256-bit, generated once per device, non-extractable, held in IndexedDB. Passphrase-derived KEK uses PBKDF2-HMAC-SHA256 at 600,000 iterations — the OWASP 2023 floor, and the code says so.

Encrypted export / backup container holds student data Every path that writes student data off this device goes through one container format: PBKDF2-SHA256 at 600,000 iterations, AES-GCM-256, version tag mtss-enc-v1. Restore AUTHENTICATES by decrypting — no password, no restore. There is no separate signature field to forget to check; the AEAD tag is the integrity check.

network layer Maps each request to an egress kind and enforces the SAME policy at the network layer. Fail-CLOSED: no policy yet, or an unknown kind, is BLOCKED. A PII canary tripwire inspects outbound bodies below the custodial tier; a raw identifier appearing in one is blocked and reported to the page. Defense in depth. The app-layer gate and the network-layer gate are separate code paths enforcing one policy, so a bug in one does not silently open the boundary.

filled — student data is present in this component

outlined — no student data

dashed — optional, district-owned, not configured in the shipped default

Text equivalent: components either side of the device boundary, and whether each holds student data.
Component	Side of the boundary	Holds student data	Derived from
Browser localStorage	device	yes	MTSS2RTI.html — `const S` at S6; Stage-F field encryption
Browser IndexedDB	device	yes	MTSS2RTI.html — createObjectStore() census, deduped: caseload config groups roster snapshots yearHistory
Device keyring	device	no	MTSS2RTI.html — `var _KEYRING_PBKDF2_ITER = 600000;` (~29405); `{name:'AES-GCM', length:256}` (~29416)
Encrypted export / backup container	crossing	yes	MTSS2RTI.html — `async function _encryptExportContainer997(plaintext, password)` (~210027)
Static host (Cloudflare Pages)	network	no	deploy-pages.sh — the published set is an explicit allow-list of app assets; 'Cloudflare Pages: serves static files only; it stores no student data.'
District audit relay	network	no (not configured)	audit-relay-worker.js exists and compiles; dc.auditRelayUrl is empty in the shipped config

What this paper is not

This page describes the architecture as shipped. A security brief would also contain a threat model, a key-rotation procedure, a recovery runbook and a penetration test result. None of those exist yet. They are listed as planned on Documents, and a reviewer who needs one should ask for it.

← Privacy & security · All references and briefs