Security and privacy overview

Version 1.3, effective October 27, 2026.

This page is for school boards, IT and procurement teams. It describes, factually, how Writeroom is built and run. It states what is in place; it does not claim certifications or audits we do not have. For the contractual commitments behind it, see the Student Data Protection Addendum. Questions: the contact form at writeroom.org/contact (topic: Security or Schools).

In one paragraph

Writeroom runs on Google Cloud in Toronto. Student writing, writing-process records, files, the database, logs and backups stay in Canada. Google Cloud encrypts data at rest and in transit by default. Only Writeroom's application server can reach the database and files; browsers never connect to them directly. Every request is checked against the user's school and role. Teachers see only their own students. Writeroom's own staff have no default access to student work. External AI features are off until a school turns them on, and when on they are sent only to endpoints that do not retain or train on the text. There are no ads, no analytics trackers and no sale of data.

Where data lives

Full detail, including what each provider receives, is on the subprocessor page.

Encryption

• Google Cloud encrypts all data at rest and all data in transit between its facilities by default.
• Connections between browsers (and the extension) and app.writeroom.org use HTTPS. HTTP Strict Transport Security is enabled.
• Secrets (API keys, tokens) are stored only in Google Secret Manager, never in code, container images or logs.

Access control

• Tenant isolation. Every request is scoped to the signed-in user's school on the server. Automated tests call every route as a user from a different school and must receive a 403 or 404.
• Role checks in one place. Every route declares who may call it (platform administrator, school administrator, teacher, student, document owner). Enforcement is in one authorization layer, not scattered through the code.
• Teachers see only their own students. A teacher can open a student's documents, replay, analytics and evidence only for assignments they own or co-teach, or documents the student shared with them. Alerts go only to teachers who can see the document.
• School administrators can see everything in their school; every such view is written to the school's audit log.
• Students can edit only their own documents, and only the document owner's browser can record writing-process events. Students never receive Integrity Signals.
• Writeroom staff. Platform administrators cannot open student work by default. A school administrator can grant time-limited support access (for example 24 hours) from the audit page; every view is logged. There is no impersonation feature.
• Settings (retention, AI, feature switches, teacher list, domains) are changed by school administrators only; teachers see them read-only. The log records who changed what and when.

Authentication and sessions

• Sign in with Google, or with email and password through Firebase Authentication. Email accounts must verify their address.
• Sessions are httpOnly, Secure, SameSite cookies: 5 days for students and teachers, 12 hours for platform administrators. No session tokens appear in URLs. "Sign out everywhere" is available. Removing a member revokes their sessions.
• Multi-factor authentication is required for Writeroom's platform administrators and recommended for school administrators.
• There are no demo accounts in staging or production (they exist only in local development). The teacher "sample class" is one read-only sandbox of fictional students and documents; no fictional people are added to any school.
• Rate limits apply to sign-in, sign-up, invitations, the contact form, AI features and expensive analytics routes, per IP address and per user.

Application security

• Input validation schemas for every request body and query; invalid input returns a 400, never a server error.
• Strict Content-Security-Policy without inline scripts, HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, frame-ancestors none.
• CSRF protection: SameSite cookies, Origin checks and a token on every state-changing request.
• Uploads are limited to images, checked by content, re-encoded on the server, and served with a sandbox policy from a separate path.
• Server-side fetches of image URLs allow only http and https, block private and metadata addresses, and enforce size caps and timeouts.
• Error responses never include stack traces. Logs never contain student text, document content, clipboard contents or tokens; request identifiers support troubleshooting.
• Prompt-injection defence on every AI feature: student text is wrapped in a random boundary, invisible and hidden text is removed, text aimed at an AI marker is stripped, answers must follow a fixed structure, scores are totalled on the server, and a compromised answer never pre-fills a grade. Attempts are flagged to the teacher only.

Development and release

• Dependencies are pinned and checked weekly by automated tooling; npm audit findings are fixed or documented.
• A written threat model lists threats, mitigations and the test for each.
• Every release is built by Cloud Build, deployed to a separate staging environment, run through the automated end-to-end suite (including tenant-isolation and validation tests and an OWASP ZAP baseline scan), then promoted to production with the same image. Rollback is one command.
• Staging and production use separate databases and buckets.

Monitoring and incident response

• Health and readiness probes, uptime checks on the website and the app, and alerts on error rate, latency, alert delay and spend.
• Platform audit log of every platform action; school audit log of who viewed which student's replay, clips and analytics, decisions, hand-backs, settings changes and support access.
• If a security incident affects a school's data, Writeroom notifies the school's privacy contact without undue delay and within 48 hours of confirming it (so a board with its own 72-hour reporting clock has time), provides the facts the school needs for its own assessment and notifications, gives a written final report within 30 days after containment, and supports the school's investigation. Writeroom keeps a record of every incident for at least 24 months.

Data minimisation built into the product

• Writing-process recording runs only in assignment documents. Students' own documents are never recorded.
• The outside-clipboard check is on when a school starts, and a school administrator can turn it off. While it is on, only text of eight or more words that matches the document or an AI tool is kept; other items are kept as a hash and word count; anything resembling a password or code is dropped; declining the browser permission is never flagged.
• The Chrome extension reports only while an assignment document is open, records site domains rather than full addresses (full addresses only for listed AI tool sites), keeps no list of open tabs (only a count and the AI tool domains), runs its copy hook only on listed AI tool sites, and holds host permissions only for Writeroom and those sites.
• Screen clips are taken only when the assignment requires supervision and the student starts sharing after a plain-language notice; clips are deleted after 30 days by default.
• External AI is on when a school starts (unless the school's Order Form says it may not be used, in which case Writeroom locks it off), and a school administrator can turn it off. Each school has a monthly allowance of AI credits set by Writeroom; every request is priced and reserved before it is sent, and refused when the credits run out. When on, requests are sent with OpenRouter's no-data-collection and zero-data-retention settings, models come from an allowlist, no user identifier is sent, student names are replaced with placeholders in assistant requests, and email addresses are never sent. If no compliant endpoint is available the request fails rather than falling back.
• Writeroom trains no models on student data. The AI detector runs locally in Toronto and sends nothing anywhere. It is not applied to writing that is not in English.
• Unsent work kept in the browser for reliability is cleared on sign-out and after 14 days.
• Teacher exports (keystroke tables, copied summaries) show a one-line reminder that the copy leaves Writeroom's protections and is the school's responsibility.

Retention and deletion

• Defaults, adjustable by the school: writing-process records and computed signals, 12 months after the document was last edited; screen clips and their text, 30 days; documents, comments and grades, until the school deletes them or the contract ends.
• School administrators can export or delete an individual student's data, and export the whole school, from the Data tab.
• At contract end: 30-day read-and-export window; deletion of all customer data from live systems within 60 days after the contract ends; backup copies age out within 35 days after that deletion; written certificate on request. Audit logs (who did what; no student content) are kept [12 months] after the contract ends, then deleted.
• Accounts that signed up but were never given access are deleted after 90 days.

What Writeroom does not do

• No advertising, no analytics or tracking cookies, no third-party trackers on the website or in the app.
• No sale, rental or trade of personal information.
• No training of AI models on student data, by Writeroom or, through the settings above, by the AI vendors a school may turn on.
• No camera use except when a student chooses to take a photo to insert into their own document; no audio recording, no location, no keystroke capture outside the Writeroom editor, no browsing capture outside an assignment document.
• No automated decisions about students: Integrity Signals are labelled as a reason to look, not proof, and only a teacher can record an integrity decision, with their own written note.
• No consumer or individual accounts: Writeroom is provided only to schools.

Certifications and audits

Writeroom does not currently hold SOC 2, ISO 27001 or similar certifications and does not claim them. Google Cloud, which hosts Writeroom, publishes its own compliance reports and certifications. Writeroom answers schools' standard security and privacy questionnaires and supports their privacy impact assessments with written answers and this documentation, at no charge for the hours stated in the school's agreement (expected to cover one standard questionnaire per year). If we obtain a third-party assessment, we will say so here.

Reporting a security concern

If you believe you have found a vulnerability in Writeroom, tell us through the contact form at writeroom.org/contact and choose the topic "Security". Please do not access or alter data that is not yours. We acknowledge reports within [2 business days] and keep you informed until the issue is resolved.

Last updated: October 27, 2026.

Questions about this document? Use the contact form. All legal documents