Security, privacy and terms

The policy for the SplatWorks ecosystem: the DrawSplat whiteboard, WriteSplat, GridSplat, ListSplat, ShowSplat, LayoutSplat, creative tools, widgets and games.

Updated October 15, 2026. SplatWorks is the ecosystem; DrawSplat is the whiteboard. This page brings the policy, security boundaries, provider disclosures and review requirements together.

The essentials

What is processed and where

Student personal information includes anything reasonably linked to a student or household: account/SSO identifiers, names, class membership, work, submissions, feedback, media, recordings, usage and identifying logs, as well as information covered by applicable student-privacy law. Importing, editing, recording, saving or sharing creates the relevant data.

Camera, microphone and screen capture require the selected feature's browser/device permission. Supported local imports, conversions and PPTX, ODP, GIF, PDF, image or native exports run in the browser. Embedding an app in an LMS does not change its storage or network boundary; same-origin handoffs and third-party browser storage restrictions still apply. Keep secrets and student records out of URLs.

The per-component inventory lists storage references and literal remote hosts. It is a static inventory; test actual requests for the approved features, including dynamic media, fonts, libraries and user-entered endpoints. October 15 SplatWorks.org and DrawSplat.org startup observations cover all 64 registered destinations per domain, with no attempted external HTTP(S) requests in fresh sessions during the recorded window; selected features and existing projects are outside that check.

Rights, requests and contacts

Parents and eligible students may request access, correction, export, deletion, restriction/pause or raise a privacy concern. Contact the school's published privacy contact for school records, or drawsplat@gmail.com for public-site privacy requests, vulnerabilities and provider/policy notice registration. The public contact routes requests; private district records and local browser files remain with their owners.

Operators must acknowledge requests within 10 school days and fulfill them within 30 calendar days, with any shorter applicable legal deadline taking precedence. Verify identity through established school/family channels and provide an assisted alternative. Deliver exports through an approved channel; do not email student records or identity documents to the developer.

Use native saves for editable work. The privacy center's archive exports origin-local storage and IndexedDB for inspection, with recognized credential fields redacted, including serialized settings; it is not a universal native-file restore format. Clearing reports blocked databases so another open tab cannot silently prevent erasure.

Retention and deletion

Existing browser drafts remain until the owner clears them or explicitly enables 1-, 7- or 30-day expiry. Expiry can be turned off without deleting drafts. It is checked on return; an offline device cannot be remotely erased. A successful browser clear offers a receipt with origin, time and cleanup counts; other record locations need separate evidence. Database cleanup and Apps Script triggers must be intentionally enabled and tested for the records they cover.

At termination, provide return/export, delete active student personal information within 30 calendar days, and expire/delete backups within 90 calendar days. Restore procedures must reapply erasures before reopening access. Retention beyond the educational purpose requires a documented legal obligation with an end date, or irreversible de-identification with no re-identification.

Security and incident response

Production hosting must use HTTPS. Public sites apply HSTS, Content Security Policy, nosniff, referrer and permission restrictions, with tighter policies where supported. Allowed origins vary with app features; the common policy preserves supported embeds and connections.

Hosted/district operators must verify encrypted database transport, encryption at rest for disks, databases, objects and backups, least-privilege access, MFA where available, protected audit logs, secret management, secure backup/restore and routine patching. Device owners must secure local profiles and files. Backend roles separate administrators, teachers and students; validate access with representative accounts. API/database credentials belong on the server.

Investigate suspected incidents, contain access and preserve evidence. Triage within 24 hours without delaying required notice. The contractual district notice is due without unreasonable delay and within 72 hours after confirming a student-data breach; earlier applicable duties take precedence. Include scope, affected data/users, containment and next steps; provide a written post-incident report within 30 days.

For GDPR-covered processing, a processor notifies the controller without undue delay after becoming aware of a personal-data breach. Where required, the controller notifies the supervisory authority without undue delay and, where feasible, within 72 hours of awareness; the Article 33 exception applies when risk to individuals is unlikely. High-risk breaches require notice to affected people without undue delay under Article 34. Do not wait for final confirmation to start these duties. See GDPR Articles 33–34. Operators manage monitoring and notification.

Review security before student rollout, at least annually, and after material hosting, authentication, storage or integration changes. Include access, dependency, retention, backup/restore and vulnerability checks appropriate to the deployment. No independent SOC 2, ISO 27001 or ecosystem-wide security certification is supplied.

Choices, consent and age

Local workflows are available without optional cloud, AI, SSO or backend processing. Connection preferences cover cross-origin fetch, XHR and beacon requests; they are not a firewall for navigation, media, embeds or every external resource. GPC/DNT status is shown; the no-sale/no-profiling protections apply regardless of those signals.

The operator retains its COPPA duties, including required notice and verification that authorization actually comes from the school. Schools may provide COPPA authorization only where permitted for the school-authorized educational use; that does not approve unrelated processing or optional AI. For direct-family collection requiring parental consent, the operator must verify authorization through an established channel, record the purpose/services/retention and support withdrawal. No public child-account registration or ecosystem-wide verified-consent system is provided. Apps Script age locks govern its whiteboard records, not every app.

Brain Sort, Clock Wizard, Step-Splat, Toneshifter and Vibe Check keep API keys in tab memory and require separate approval for each AI provider destination in a tab; reload removes the key. Turning connections off revokes approvals, including pending requests in other open tabs. AI fetch requests reject redirects. Prompts and selected content leave the browser when approved. Use only separately approved business API accounts with verified retention, region and no training/data-sharing opt-in. The approval checkbox is not parental consent. Other tools may retain configuration; review their storage and shared-profile clearing.

Providers and policy changes

Public hosting: Cloudflare, Inc. (United States; global edge network). Optional services: Google Workspace/Drive/Calendar/identity, Microsoft identity/OneDrive, Dropbox, OpenAI API, Anthropic API and individually approved hosting, libraries, media, roster/SSO, bot or sharing endpoints. Company country is not the processing region.

Before student processing, verify each enabled provider's actual contract, roles, jurisdiction/region, data/access scopes, retention/deletion, security, incident notice and applicable transfer safeguards. Flow down the same educational-purpose, no-sale, no-profiling and no-training restrictions. Exact host-log retention and deployment-specific contracts/settings remain evidence items.

SplatWorks gives affected schools at least 30 calendar days' advance notice before a material new public-service student-data provider, through this dated page and registered district contacts. Schools may object, disable the integration or terminate/export before processing starts. Urgent security/legal changes require prompt notice, explanation and the same mitigation path. Self-hosted operators must operate this process for their own providers. Material policy changes are dated here and sent to registered notice contacts; schools notify affected families and staff.

Terms of service

Use and ownership. Educators, supervised students, families and organizations may create and share work for lawful purposes. Users and schools retain their content ownership. Do not upload or distribute unlawful, harmful, harassing, discriminatory, privacy-invasive or unsafe content. Sensitive student/health/financial records, government IDs and other high-risk data require the organization's specific approval.

Software license. DrawSplat, standalone tools/widgets and backends use AGPL-3.0-or-later, subject to component notices. The five office apps use GPL-3.0-only. Preserve third-party notices and follow each component's license. Software and shipped controls are free, with no per-seat fee; optional support, training or custom development uses a separate services agreement.

Service expectations. Software is provided as-is without guarantees of uninterrupted service, fitness for a particular purpose, managed hosting or legal compliance for a particular school. Operators are responsible for their hosting, approved services, storage, access, backups, retention and student supervision. Students must not receive setup secrets or administrator controls.

School agreements. Districtwide, hosted, SSO-enabled, MySQL-backed or managed deployments require a district agreement/addendum naming the parties, approved purpose/components, data, locations, providers, contacts, retention, security and incident responsibilities. Templates and review packets are not executed agreements. Existing signed agreements retain their terms unless the parties amend them. Any future vendor-managed hosting must identify its storage, access, support/uptime and operational commitments in hosted-service terms or a signed agreement.

District approval and paperwork

Before student use, record the exact deployment and services; approve the purpose, age/consent basis, data flows and locations; test access, rights requests, retention, erasure and backup/restore; identify the responsible contacts; and complete applicable agreements. Keep the redacted evidence and review it annually or after material changes.

PROTECT report cards and review

The October 15, 2026 review gives supervised public browser-only use 9/14 and district self-hosted readiness 8/14. Optional AI/cloud/SSO/backends are off in the public scope. No named district installation was audited. The targets of 13/14 and 14/14 depend on verified operating evidence; these are provisional assessments.

View the horizontal report cards and category scores

Provisional category scores, each out of 2

Category	Public evidence	District readiness
Parental rights and access	1	1
Retention and deletion	1	1
Opt-out options	2	2
Transparency	2	1
Encryption and security	1	1
Consent and age restrictions	1	1
Third-party management	1	1
Total	9/14 — approve with conditions	8/14 — hold for deployment evidence

Public report card (PNG) · District report card (PNG) · Assessment and conditions · Score data (JSON).

Policy history

October 15, 2026: consolidated security, privacy, terms, providers and deployment review; removed repeated summaries and outdated overlapping text. Commitments, deadlines and signed-agreement status are preserved.