Combined policy packet

1. Terms of Service

Who May Use DrawSplat^TM

DrawSplat^TM may be used by individual educators, students under school supervision, families, small teams, schools, districts, and organizations. When DrawSplat^TM is used with students, the teacher, school, district, or organization is responsible for deciding whether the deployment is appropriate for the students and for obtaining any required consent.

Acceptable Use

Users may create whiteboard content, notes, drawings, diagrams, images, audio notes, templates, and classroom submissions. Users may not use DrawSplat^TM to upload, store, share, or distribute unlawful, harmful, harassing, discriminatory, invasive, confidential, or unsafe content. Do not use DrawSplat^TM to collect sensitive student records, health information, financial information, government IDs, or other high-risk personal data unless your organization has reviewed and approved the deployment.

Ownership of Content

Users and their schools or organizations retain ownership of board content they create. DrawSplat^TM does not claim ownership of user-created boards, student submissions, or uploaded media. If a teacher or organization hosts DrawSplat^TM, that host controls the deployment, storage location, access rules, and deletion process.

License and As-Is Use

DrawSplat^TM whiteboard code, tools, widgets, backends, and compliance features are released under GNU AGPL-3.0-or-later as stated in the repository LICENSE file. SplatWorks^TM apps, including GridSplat^TM and ShowSplat^TM, are released under GPL-3.0-only as stated in splatworks/gridsplat/LICENSE.md. The software and every compliance feature shipped in it are free for all users — teachers, students, classrooms, campuses, districts, and self-hosting organizations. No individual or per-seat license is required to run DrawSplat^TM, GridSplat^TM, or ShowSplat^TM on district devices. Districts that want implementation support, professional learning, compliance review, or custom development may engage those services under a separate services agreement; that does not put a paid product license on student devices. DrawSplat^TM, GridSplat^TM, and ShowSplat^TM are provided without guarantees of uninterrupted service, fitness for a particular purpose, managed hosting, or legal compliance for a specific school system.

District Data Privacy Addendum

For districtwide, hosted, SSO-enabled, MySQL-backed, or managed deployments, DrawSplat^TM must be accompanied by a district data privacy agreement or written addendum. That addendum must name the controlling school or district, identify the storage mode, document the approved educational purpose, list subprocessors, state the retention schedule, name the privacy/security contact, identify the breach notification contact method, document hosting location requirements, and confirm the security commitments in this policy. A signature-ready template is available at district-addendum.html.

Return and Destruction at Termination

When a school, district, or organization ends a DrawSplat^TM deployment, the deployment owner must provide a way to return or export school-controlled content, then delete or destroy remaining student personal information from active systems within 30 calendar days unless a different written retention requirement applies. Backups must be deleted or aged out on the normal backup cycle, and no later than 90 calendar days when technically feasible.

Teacher and Administrator Responsibilities

Teachers and administrators are responsible for configuring storage, protecting share links, choosing appropriate room names, setting retention expectations, monitoring student use, and deleting content when it is no longer needed. Students should not be given provider setup URLs, Google Apps Script configuration details, or admin controls.

2. Privacy Policy

Definition of Student Personal Information

For this policy, student personal information means information that identifies, relates to, describes, or can reasonably be linked to a student or student household, including student names, class names tied to a student, account or SSO identifiers, student-created board or spreadsheet content, uploaded media, audio recordings, submissions, comments, room participation data, logs tied to a student, and any other information treated as student personal information, personally identifiable information, education records, or covered information under applicable federal, state, or local student privacy laws.

Data We Collect

The static DrawSplat^TM app does not require login and does not collect data on its own server. Depending on how a user or school configures it, DrawSplat^TM may process the following information in the browser or configured storage:

• Board title, class name, room name, panel names, and assignment mode settings.
• Optional student name entered by the teacher or student.
• Whiteboard objects such as drawings, shapes, text, sticky notes, comments, diagrams, images, audio notes, and uploaded files.
• GridSplat^TM spreadsheet content such as cell values, formulas, charts, picture graphs, templates, and native .gridsplat.json save files when a user chooses to save or open them.
• Local browser settings such as workspace mode, interface mode, storage mode, Google Apps Script URL, and session expiration time.
• Google Apps Script save logs if the teacher or school enables Google Drive and Sheets storage.

How Data Is Collected

Data is created when users draw, type, enter spreadsheet data, upload media, record audio, save locally, export, or send a board or spreadsheet to a configured backend or cloud provider. Browser-only mode stores data in the local browser. Google Apps Script mode sends configured board data to the teacher or organization’s Google Apps Script deployment. GridSplat^TM direct cloud save sends the selected spreadsheet save file to the user-authorized Google Drive, Dropbox, or OneDrive account. Future MySQL or standalone storage modes would send data to the organization’s configured backend endpoint.

How Data Is Used

Data is used only for the school-authorized educational purpose: displaying the whiteboard or spreadsheet, restoring autosaved work, supporting classroom rooms, saving or loading boards and sheets, creating templates, supporting turn-ins, and helping teachers manage classroom activity. DrawSplat^TM does not use student data for advertising, behavioral profiling, cross-context tracking, sale, lease, rental, data mining except for authorized educational purposes, or training artificial intelligence models. These restrictions apply to the static app, GridSplat^TM, Google Apps Script mode, MySQL mode, self-hosted mode, and any future hosted DrawSplat^TM version.

De-identified and Aggregate Data

DrawSplat^TM does not need de-identified or aggregate student data to operate the static app. If a hosted or managed deployment ever uses de-identified or aggregate operational data, it must remove direct and indirect identifiers, use the data only to maintain, secure, improve, or report on the service for the school-authorized purpose, and must not attempt to re-identify students or allow others to re-identify them.

Data We Do Not Collect

The static DrawSplat^TM app does not require email addresses, passwords, student account registration, payment details, biometric data, precise location, or advertising identifiers. If a school adds SSO, analytics, a backend API, or third-party hosting, those additions must be documented by the school or hosting provider.

Hosting Location

Browser-only data remains on the user’s device/browser profile. Google Apps Script data is stored in the controlling teacher, school, or district Google environment, subject to that organization’s Google configuration and regional settings. GridSplat^TM direct cloud save stores files in the user-authorized Google Drive, Dropbox, or OneDrive account selected by the deployment and user. MySQL, standalone, hosted, or managed deployments must document the country, region, cloud provider, data center, or school-controlled server location where student data is stored and processed, including backup locations when known. Deployments subject to GDPR, state data-residency rules, or district hosting requirements must approve hosting location before student use.

FERPA/COPPA School Official Statement

When DrawSplat^TM is used by a school or district for an approved educational purpose, the deployment owner or service operator may be treated as a school official or authorized service provider under FERPA and similar student privacy laws, acting under the direct control of the school for the use and maintenance of education records. For COPPA-covered students, the school or district may provide consent on behalf of parents when permitted by law and when DrawSplat^TM is used solely for the school-authorized educational purpose.

3. Student Privacy Commitments

4. Storage Modes and Retention

5. Third Parties

DrawSplat^TM’s static pages do not require third-party analytics, advertising, or tracking. Server-side visit counts come from the static-host CDN (Cloudflare Pages by default), which never adds a beacon or any other request to the visitor’s browser. The following services may be involved only if the user, teacher, or organization chooses to use them:

• Google Apps Script, Drive, and Sheets: optional storage, room sync, templates, and turn-ins.
• Google Drive, Dropbox, and OneDrive: optional GridSplat^TM direct cloud save/open when configured by the deployment owner and authorized by the user.
• MySQL: optional future self-hosted database for rooms, users, submissions, audit records, and session expiration.
• PayPal: optional payments or donations from public pricing and support links.
• Hosting provider: the organization’s selected web host, school server, or domain provider.
• Future SSO provider: optional identity provider for standalone deployments, such as a school-managed Google Workspace or Microsoft Entra configuration.

Subprocessors and Change Notices

Before student use, any hosted or managed DrawSplat^TM deployment must publish a subprocessors list naming each provider, the service purpose, the type of data processed, and the provider’s privacy/security documentation. Schools must receive at least 30 calendar days’ notice before material new subprocessors are added for student-data processing when feasible, and must have a reasonable opportunity to object, disable the affected integration, or terminate the affected hosted service.

6. Security Practices

• Use HTTPS for any public deployment and redirect HTTP traffic to HTTPS.
• Keep admin pages and provider settings separate from student whiteboard pages.
• Do not place passwords or sensitive student information in share links.
• Use school-managed accounts with MFA for Google Apps Script and Drive storage.
• Use least-privilege access for hosting, database, Google, and backend administrators.
• Encrypt backend databases, file storage, object storage, and backups at rest when using hosted, MySQL, or standalone storage.
• Record administrative access, exports, deletes, retention-job activity, and security-relevant configuration changes in audit logs.
• Review uploaded files and board content according to school acceptable-use rules.
• Patch hosting systems, scripts, and backend dependencies on a regular schedule.

Incident Response and Breach Notice

For hosted, MySQL, SSO-enabled, or managed deployments, the operator must investigate suspected unauthorized access, contain the issue, preserve relevant logs, and notify the affected school or district through the published privacy/security contact method without unreasonable delay and no later than 72 hours after confirming a breach involving student personal information. Notices should describe what happened, the data involved, affected users if known, containment steps, and recommended protective actions.

Security Review Expectations

Hosted, MySQL, SSO-enabled, or managed deployments must receive technical/security review before student use and at least annually after launch. Additional review must occur after material changes to authentication, storage mode, hosting provider, subprocessors, database permissions, or backend code. Reviews must include dependency patching, access control validation, database permission review, backup/restore testing, audit-log review, and vulnerability scanning or penetration testing appropriate to the risk and scale of the deployment.

Vulnerability Reporting

Schools, security researchers, and users may report suspected vulnerabilities to the privacy/security contact listed by the deployment owner. Reports must be acknowledged promptly, triaged according to severity, and remediated before public disclosure when practical.

7. District Deployment Checklist

Before approving DrawSplat^TM for student use beyond browser-only local testing, the school or district should document:

• The storage mode: browser-only, Google Apps Script, MySQL, standalone backend, or hosted service.
• The hosting/data location, including country, region, cloud provider, district server, and backup location when known.
• The approved educational purpose and whether student uploads, audio, turn-ins, or SSO are enabled.
• The retention schedule, including default 24-hour temporary sessions or any longer class/district retention rule.
• The privacy/security contact for parent, school, district, and vulnerability reports.
• The breach notification contact method, such as a monitored district email address or ticketing queue.
• The subprocessors list and notice process for new subprocessors.
• The consent or notice basis for students under 13 and any other covered age group.
• The encryption-at-rest, backup, audit-log, and breach-notification expectations for the chosen deployment.
• The security review schedule, including pre-launch review and at least annual review for hosted, MySQL, SSO-enabled, or managed deployments.
• The data return/destruction process at contract termination or when the deployment is retired.

8. Contact, Requests, and Policy Changes

For classroom or school deployments, privacy requests should go first to the teacher, school, district, or organization that controls the DrawSplat^TM deployment and storage. That organization must publish a monitored privacy/security contact, acknowledge parent/student/school requests within 10 school days, and complete access, export, correction, or deletion requests within 30 calendar days when feasible. The controlling organization can locate, export, correct, or delete student content from browser storage, Google Drive/Sheets, MySQL, or its self-hosted backend.

Material changes to this policy should be posted on this page with an updated date. Schools should notify affected teachers, students, and parents when storage modes, third-party providers, retention periods, or student data practices change.

9. Hosted-Service Boundary

This policy covers the static app, school-controlled Google Apps Script deployments, MySQL/self-hosted deployments, and baseline expectations for managed deployments. If DrawSplat^TM ever offers vendor-managed hosting directly, that hosted service should publish separate hosted-service terms or a signed district agreement that identifies hosting location, subprocessors, support commitments, uptime expectations, incident response roles, data segregation controls, security review frequency, retention defaults, and deletion/export procedures.

10. Policy Version History

Compliance Features (v3.1.0)

The DrawSplat^TM service includes the following compliance-focused capabilities. The Compliance Console (inside Teacher Admin) is the single surface for configuring them, and the District Privacy Packet is the artifact a district reviewer can download to inspect the current configuration plus the last 90 days of Activity Records.

• Activity Records (audit log). Every compliance-relevant action — board saves, image uploads, moderation decisions, parent requests, age-band changes, data exports, data deletions, admin setting changes, retention runs — writes an logged row to a dedicated Audit sheet tab in your Google Sheet. Filterable in the Compliance Console; downloadable as CSV or JSON.
• Safety filters. Server-enforced text keyword filter and link allowlist run on every board save. Hits are logged as TEXT_FILTER_HIT events; blocked text is rejected before reaching storage.
• Board / room freeze. A teacher or administrator can freeze a board, blocking all future writes until unfrozen. Frozen state is enforced server-side.
• Student Age Band Lock. Each student record carries one of under_13, 13_to_17, 18_plus, or unknown_minor. The band is server-locked; only an administrator can change it, every change requires a reason and emits an AGE_BAND_CHANGED audit event. Aligned with the Texas Securing Children Online Through Parental Empowerment Act’s age-registration provision.
• Teacher-issued parent verification. An administrator can generate a one-time 8-character verification code for a student. The code (SHA-256-hashed with a server-side salt) lets a parent verify their relationship through the school’s existing parent-communications channel and skip the manual identity-confirmation step.
• Family Access Tools. Parents submit requests (view / export / correct / delete / pause / safety report / privacy question) at /parents/. Verified requests appear in the Compliance Console with Approve / Deny / Done controls. Each transition is audited.
• Student data export. An administrator can download a ZIP of every board and turn-in tied to a student, plus the user row (sans credentials), a machine-readable manifest.json, and a human-readable README. Logged as DATA_EXPORT.
• Student data deletion. An administrator can delete a student’s boards and turn-ins (Drive files moved to trash; sheet rows removed) and the user row. Logged as DATA_DELETED with counts.
• Retention policy and scheduled cleanup. District-configurable thresholds for archive-after, delete-after, and audit-keep windows. A daily Apps Script trigger prunes accordingly; manual runs are also available. Each pass writes a RETENTION_ACTION event.
• Time-limit enforcement. When enabled, students see a remaining-time chip in the corner of the whiteboard; the browser locks the workspace at the daily limit and outside allowed hours. The Apps Script save endpoint enforces the same limits as the authoritative gate.
• District Privacy Packet. One-click ZIP containing the current compliance configuration snapshot, the last 90 days of Activity Records as CSV, all parent-request tickets, and a README pointing at Terms & Privacy and District Addendum. Surfaceable to district reviewers without involving DrawSplat^TM.

Operator notes for school IT staff and district administrators live in docs/COMPLIANCE.md in the repository.

The laws this page covers

• Texas SCOPE Act (Securing Children Online through Parental Empowerment Act) — protects Texas minors under 18 with rules on age registration, parental controls, harmful-content strategies, and data-use limits. The Texas Attorney General publishes an overview at texasattorneygeneral.gov. Parts have been challenged in court; we implement what is currently in force, not what has been enjoined.
• FERPA (Family Educational Rights and Privacy Act) — federal law giving parents and eligible students rights over education records, including the right to inspect, correct, and control disclosure.
• COPPA (Children's Online Privacy Protection Act) — federal law about collecting personal information from children under 13. In school deployments the district typically acts as the parent's agent for consent.
• Texas Education Code 32.151–32.156 — framework for student data agreements between districts and online service providers.
• CIPA (Children's Internet Protection Act) — federal E-rate requirement that schools and libraries deploy a technology protection measure that blocks visual depictions of obscenity / child pornography / content harmful to minors, plus an internet safety policy. CIPA is a network-level obligation on the district, not a privacy law on the vendor. DrawSplat^TM provides supporting features (see “CIPA support statement” below) but does not replace the district's network filter or internet safety policy.

What this looks like in DrawSplat^TM

Every requirement below maps to a feature in the app you can demonstrate to a district reviewer, not just a paragraph in the terms.

1. Age registration and locking

SCOPE requires providers to register the age of a person creating an account and prevent that person from later changing it. DrawSplat^TM assigns each student record an age band — one of under_13, 13_to_17, 18_plus, or unknown_minor. The band:

• Is server-locked. Students cannot change it.
• Can only be changed by an administrator, and only with a written reason.
• Records every change in the Activity Records audit log (AGE_BAND_CHANGED) with the old value, new value, who changed it, and why.
• Defaults to unknown_minor — the safest assumption — until a roster import or admin entry provides the actual value.

This is configured in Internal Compliance Console → Student Age Band Lock.

2. Strategies to limit harmful content reaching minors

SCOPE expects providers to have strategies (not perfect filtering) to keep harmful content away from known minors. We layer multiple safeguards:

• Server-enforced text keyword filter. Every save scans sticky notes, text boxes, comments, and board titles. Hits write a TEXT_FILTER_HIT event and (by default) reject the save.
• Link allowlist. Pasted URLs are checked against a district-managed allowlist before save.
• Manual moderation queue. Teachers freeze boards or remove items they find unsafe.
• Audit visibility. Every safety event is logged, so a district can prove ongoing review.

Notable scope limitation: some content-filtering provisions of SCOPE were enjoined by federal court. We do not implement parts that are not currently in force.

3. Parental empowerment

SCOPE and FERPA both give parents tools to oversee their child's online services. DrawSplat^TM's Family Access Tools at /parents/ give parents one place to:

• View what data is stored about their student.
• Download a complete ZIP export of their student's boards, turn-ins, and account row (machine-readable manifest + human-readable README).
• Correct account information.
• Delete stored work.
• Pause account access.
• Report a safety concern.
• Ask a privacy question.

Parents are verified through a teacher-issued one-time code — an 8-character alphanumeric value the school passes through its existing parent-communications channel. The code is stored only as a SHA-256 hash, expires in 14 days, and is single-use.

4. Data-use and data-sharing limits

SCOPE and FERPA both restrict how minor-data is used and shared. DrawSplat^TM's declarations:

• No advertising. The product has no ad system, no tracking pixels, no third-party analytics scripts. Visit counts come from Cloudflare Pages’ server-side analytics on the static-host CDN, which never adds a beacon or any other request to the visitor’s browser.
• No sale of data. Student data is never sold or licensed to third parties for any purpose.
• No AI training on student data. Student boards and submissions are never used to train AI models — ours or anyone else's.
• Storage stays where you put it. If your district configures the Google Apps Script backend, your data lives in your Google Drive and Sheets. If you self-host with the MySQL backend, the data is on your servers. We don't operate the storage.
• Sub-processors are limited. The only third parties involved are: Google Workspace (if you use the Google backend), Microsoft Identity (if you enable Microsoft sign-in on the Community board), and your static-host CDN (Cloudflare Pages by default).

5. Right to inspect and correct (FERPA)

FERPA gives parents and eligible students the right to inspect education records. The Family Access Tools request workflow and the admin-initiated Export Data button satisfy this end-to-end. Every export logs a DATA_EXPORT event with counts and the supplied reason.

6. Right to consent / withdraw consent

Under FERPA the district controls disclosure of education records. Under COPPA the district acts as the parent's agent for the under-13 cohort. DrawSplat^TM defers to district policy — we don't disclose student data to anyone outside the district's own deployment.

7. Right to deletion

The Family Access Tools → Delete workflow lets a parent request and an administrator execute a complete deletion of a student's boards, turn-ins, and account row. Drive files go to trash (recoverable for 30 days at the file owner's discretion); sheet rows are removed. A DATA_DELETED event records counts and the supplied reason.

8. Time-of-use and limits

When enabled, the Compliance Console's Use Limits section enforces daily-minutes caps, session limits, allowed hours of day, and weekend restrictions. The browser locks the workspace at the limit; the server gates save requests so a student cannot bypass the lock by reloading the page.

9. Audit and accountability

The Activity Records log writes a row for every compliance-relevant action: logins, board saves, board freezes, image uploads, parent requests, age-band changes, data exports, data deletions, admin setting changes, retention runs, time-limit hits. Records are filterable, exportable as CSV or JSON, and included in the District Privacy Packet download.

10. Retention and disposal

Districts configure how long boards and audit records persist via the Compliance Console's Retention Policy & Cleanup section. A nightly Apps Script trigger (installable from the same panel) archives boards older than the archive threshold, deletes boards older than the delete threshold, and prunes audit rows older than the keep window. Every run logs a RETENTION_ACTION event.

11. CIPA support statement

The Children's Internet Protection Act (CIPA) is a federal E-rate condition on the school or library: covered institutions must deploy a technology protection measure that blocks visual depictions of obscenity, child pornography, and content harmful to minors, and must adopt an internet safety policy. CIPA is a network-level obligation on the district, not a privacy law on the vendor. DrawSplat^TM ships features that support a district's CIPA posture but does not replace the district's filter or internet safety policy:

• Server-enforced link allowlist. Pasted URLs are checked against a district-managed allowlist before save.
• Server-enforced text keyword filter. Hits write a TEXT_FILTER_HIT event and (by default) reject the save.
• Board and room freeze. Teachers freeze a board to block all writes until they unfreeze it.
• Image upload approval queue. Student image uploads land as pending and stay hidden on the student view until a teacher approves them. Rejection trashes the file. Approve / reject decisions are recorded as IMAGE_APPROVED / IMAGE_REJECTED events.
• Audit trail. Every safety event is logged, so a district can prove ongoing review.

DrawSplat^TM does not replace the district's required network-level internet filter. CIPA compliance also requires an internet safety policy and (in many jurisdictions) ongoing internet-safety education, both of which remain district responsibilities.

The "show me everything in one click" answer

For a district reviewer, signature-ready compliance evidence is one click in Internal Compliance Console → District Privacy Packet → Download District Privacy Packet. The ZIP contains:

• The current compliance configuration (every setting that is on, off, or set to a specific value).
• The last 90 days of Activity Records as CSV.
• All parent-request tickets and their dispositions.
• A README pointing back at Terms & Privacy and the District Addendum.

This is the artifact that goes with your data sharing agreement (DPA) submission.

What this page does not promise

• This page is not legal advice. Specific obligations under your local data sharing agreement or any individual state law require review by your district's counsel.
• Feature parity is not guaranteed across the three deployment modes (browser-only / Apps Script / MySQL). The browser-only mode has no server, so server-side enforcement features do not exist there. See the setup docs for the per-mode capability matrix.
• Some Texas SCOPE Act provisions have been blocked by federal court. We do not implement requirements that are not currently in force.
• Independent audit (SOC 2, ISO 27001, etc.) is not in scope for a free open-source project. Districts that require certified audits should engage paid services or use the self-hosted MySQL backend on infrastructure their existing audits already cover.

Where to read more

• Terms & Privacy — the formal terms-of-service and privacy policy.
• District Privacy Addendum — a signature-ready template districts can attach to their DSA.
• Privacy Notice Builder — a customizable per-deployment privacy notice generator.
• Compliance Operator Guide — how to actually use the Compliance Console day-to-day.
• Compliance Roadmap — the full implementation history and what is still on the horizon.
• Texas AG SCOPE Act overview (external).
• U.S. Department of Education FERPA reference (external).

1. Parties

2. Approved Educational Purpose

DrawSplat^TM will be used only for the following school-authorized educational purpose:

______________________________________________________________________________

______________________________________________________________________________

3. Approved Deployment Configuration

4. Data Use Commitments

• Student data will be used only for the school-authorized educational purpose.
• Student data will not be sold, leased, rented, or shared as defined by applicable state student privacy laws.
• Student data will not be used for targeted advertising, behavioral profiling, cross-context advertising, data mining except for authorized educational purposes, or AI model training.
• De-identified or aggregate data will not be re-identified or used to identify students.

5. Retention, Return, and Destruction

6. Security and Breach Notification

• Production deployments must use HTTPS and encrypted transport.
• Hosted, MySQL, and standalone deployments must use encryption at rest for databases, disks, object storage, and backups.
• Least-privilege access, MFA where available, secure backups, patching, and audit logging are required for backend/admin systems.
• Security review is required before student use and at least annually for hosted, MySQL, SSO-enabled, or managed deployments.
• Confirmed breaches involving student personal information must be reported through the breach notice contact method without unreasonable delay and no later than 72 hours after confirmation.

7. FERPA/COPPA and Student Personal Information

For this addendum, student personal information includes information that identifies, relates to, describes, or can reasonably be linked to a student or student household, including student names, account identifiers, student-created board content, uploaded media, audio recordings, submissions, comments, room participation data, and logs tied to a student.

When DrawSplat^TM is used for the approved educational purpose, the deployment owner or service operator may be treated as a school official or authorized service provider under FERPA and similar student privacy laws, acting under the direct control of the school. For COPPA-covered students, the school or district may provide consent on behalf of parents when permitted by law and when DrawSplat^TM is used solely for the approved educational purpose.

8. Subprocessors

Approved subprocessors and service providers:

Material new subprocessors for student-data processing require at least 30 calendar days’ notice when feasible and a reasonable opportunity to object, disable the affected integration, or terminate the affected hosted service.

9. Signatures

Compliance Features Available to the District

The deployment owner configures the following controls through the internal Compliance Console. The District Privacy Packet download bundles the live configuration, the last 90 days of Activity Records, and the parent-request log in a single ZIP for review.

1. Activity Records (audit log) — operator-controlled Apps Script audit Sheet recording supported compliance actions.
2. Safety Review — text keyword filter and link allowlist, server-enforced on every save. Board / room freeze blocks further writes.
3. Student Age Band Lock — under_13 / 13_to_17 / 18_plus / unknown_minor. Server-locked, admin-only changes, reason required, audited. Aligned with Texas SCOPE Act age-registration provisions.
4. Family Access Tools — parent request form, teacher-issued one-time verification code, admin Approve / Deny / Done queue.
5. Student data rights — one-click ZIP export of a student’s boards and turn-ins; one-click data deletion of the same.
6. Retention policy — archive boards after N days, delete after M days, prune Activity Records after K days. Daily Apps Script trigger or manual run.
7. Time limits — daily seconds, session seconds, allowed hours, weekend toggle. Browser locks; server gate on save.
8. District Privacy Packet — one-click ZIP for reviewers.

Configuration is server-side via the COMPLIANCE_CONFIG Script Property and cascades to every classroom on the deployment. See docs/COMPLIANCE.md for the operator guide.

1. Who is the controller and who is the processor?

Under Art. 4 GDPR, this depends on the deployment path:

• Browser-only mode (no backend configured) — no personal data leaves the student's device or the teacher's browser. There is no processor. The school is the controller of whatever local storage it directs students to use, but no data flows over the network at all.
• Google Apps Script backend — Google is the processor (governed by your existing Google Workspace for Education DPA). DrawSplat^TM is software running inside your Google account, not a third party with its own data access.
• MySQL self-hosted backend — your district or hosting partner is the processor (governed by your existing hosting contract). DrawSplat^TM is the application layer running on infrastructure you already control.
• drawsplat.org (the public marketing/demo site) — DrawSplat Developer(s) is the publisher of the marketing pages. Students should NOT do classroom work on drawsplat.org for production use; that site exists to demo features and serve documentation. School deployments host their own copy.

Because the platform itself is not a third-party SaaS that holds student data, GDPR Art. 28 controller–processor contracting requirements between you and DrawSplat^TM do not arise. They DO arise between you and Google / your hosting provider — those agreements are unaffected by introducing DrawSplat^TM.

2. Lawful basis for processing student data

Per Art. 6 GDPR, the school typically relies on either:

• Art. 6(1)(e) — public task, where the school is performing its public-interest education duty. This is the most common basis in EU/UK state schools for routine classroom tools.
• Art. 6(1)(a) — explicit consent, less common because consent under GDPR can be withdrawn at any time and processing must stop, which is hard to operationalize in a classroom.

For students under 16 (or the lower limit set by the member state, as low as 13 in some countries — Art. 8), where consent IS the basis, parental consent is required. DrawSplat^TM ships a Family Access Portal for parents to request access, exports, and deletion.

3. Data minimisation — what DrawSplat^TM processes

DrawSplat^TM's baseline collection is intentionally minimal:

• Browser localStorage on the student's device: language preference (drawsplat.language), current board JSON, viewer-mode flag, audio mute setting (drawsplat.audioMuted), per-game enabled list, admin session token (sessionStorage, cleared on tab close). No identifiers, no behavioural tracking, no analytics. See the persistent localStorage inventory below.
• When cloud sync is enabled: a room name and a salted-SHA-256 hash of the room password (server-side). Board JSON, image uploads (if enabled), audit events. Student names if the teacher chose to attach them. The district controls retention via the internal Compliance Console.
• No cookies for tracking. The site uses localStorage only for user preferences listed above. No third-party analytics, ad networks, or fingerprinting libraries.
• No outbound network requests on the standalone widgets. The standalone widgets (Concept Map Studio, Bingo Card Generator, GIFsplat™, etc.) run entirely in the browser. They never call a server unless the teacher explicitly opts into Cloud Save (Google Drive, OneDrive, or Dropbox via OAuth).

4. Data subject rights — what the platform supports

Articles 15–22 give individuals seven rights. Here's how DrawSplat^TM supports each:

• Right of access (Art. 15) — Internal Compliance Console → "Student data export" generates a JSON dump of everything tied to that student. Parents can request the same via the Family Access Portal.
• Right to rectification (Art. 16) — Teachers can edit student boards directly; parents can flag inaccuracies via the Family Access Portal request form.
• Right to erasure / "right to be forgotten" (Art. 17) — Internal Compliance Console → "Full data delete" removes the student's boards, audit records, and image uploads. Apps Script deployments delete underlying Drive files; MySQL deployments cascade-delete.
• Right to restriction (Art. 18) — Teacher Admin → "Freeze student" suspends new writes and hides existing content from the student view while preserving it for review.
• Right to data portability (Art. 20) — every standalone widget supports Save .json, and the whiteboard supports Save .drawsplat.json. Boards round-trip; you can re-import them into another DrawSplat^TM deployment or extract them programmatically.
• Right to object (Art. 21) — your DPO documents the objection; the technical action is typically "freeze" then "delete" via the controls above.
• Right re: automated decision-making (Art. 22) — DrawSplat^TM does not perform automated profiling or automated decision-making about students. Optional AI features (where present in widgets) are always teacher-initiated, never autonomous.

Subject-initiated rights flows (parents/students requesting directly without going through a teacher) are scaffolded in the Family Access Portal but rely on the district configuring its own intake and verification process.

5. Data residency and international transfers

Under Chapter V GDPR, transfers of personal data outside the EU/UK / EEA require an adequacy decision or safeguards (Standard Contractual Clauses, BCRs, etc.).

• Browser-only mode — zero transfers; data never leaves the student device.
• Apps Script backend — the data residency is whatever Google Workspace for Education has agreed with you under the EU/UK Data Processing Amendment (DPA). DrawSplat^TM adds no further transfers.
• MySQL self-hosted — you decide where the database sits. Host inside the EU/UK if your DPIA requires it.
• drawsplat.org marketing site — hosted on Cloudflare Pages, which has EU/UK-compliant transfer safeguards in place. Marketing pages collect no personal data.

Document your hosting choice in your Records of Processing Activities (RoPA, Art. 30).

6. localStorage inventory (no cookies, no third-party trackers)

DrawSplat^TM uses browser localStorage and sessionStorage for non-essential UI preferences. Under the EU Cookie Directive (2002/58/EC as amended) plus the ePrivacy interpretation of GDPR, even non-cookie local storage may require notice for non-essential items. These are examples of storage the public pages may set, so your privacy notice can describe them:

• drawsplat.language — UI language pick (en / es / vi / ar / zh / uh). Strictly necessary for the language preference to persist between visits.
• drawsplat.audioMuted — whiteboard audio toggle. Convenience setting.
• drawsplat.disabledGames — admin per-game access list (per browser). Convenience setting.
• drawsplat.adminAccess (sessionStorage) — admin role token, cleared when the browser tab closes. Strictly necessary for the admin gate.
• drawsplat.consent.accepted — records that the user has acknowledged this notice so the banner doesn't re-appear. Strictly necessary for the banner itself.
• Per-widget content (e.g. the current concept map, bingo card, dicebreaker draft) — saved locally so a refresh doesn't lose work. The user controls this directly via Save / Load / Clear buttons inside each widget.
• SplatWorks projects — ordinary working drafts use localStorage. A file opened through another SplatWorks app uses sessionStorage in its new tab; save a project file before closing that tab.
• drawsplat-file-transfers (IndexedDB) — holds a file temporarily for transfer to the matching SplatWorks app at the same website. The receiving app removes it when read. Unclaimed transfers expire after ten minutes and are removed during the next transfer. The file is not uploaded by this handoff.
• Whiteboard board state — same pattern: the in-progress board persists across refreshes; the user can clear it via the TNT Reset button.

None of these is shared with a third party. The localStorage consent banner that appears on first visit explains this and lets the user dismiss it.

7. Security measures (Art. 32)

• Room passwords stored as salted SHA-256 hashes, never plaintext.
• Strict per-page Content Security Policy (script-src 'self', no inline scripts on admin pages, no third-party origins).
• Role-based access control in the MySQL backend (server/mysql-backend/rbac.js): five roles (admin, teacher, student, parent, viewer) with a permission matrix gate on every mutation endpoint.
• HTTPS-only via Cloudflare Pages for the public site; self-hosted deployments must terminate TLS at their own load balancer.
• Open-source code, so your security team can audit it directly (github.com/mguhlin/drawsplat).
• No third-party JavaScript bundled into the runtime — all dependencies are local files audited at release time.

8. Children's data (Art. 8)

GDPR Art. 8 requires parental consent for information society services offered directly to children under 16 (member states may lower the threshold to 13). DrawSplat^TM is offered to schools, not directly to children — schools obtain consent under the public-task / parental-authority framework. The Family Access Portal provides parents a self-service way to request access, exports, and deletion of their child's data.

If a district uses DrawSplat^TM outside that school-mediated context (e.g. a public after-school club where parents register children individually), the operator must obtain parental consent under Art. 8 directly — DrawSplat^TM does not include a built-in consent-collection flow for that scenario.

9. Data Protection Impact Assessment (DPIA, Art. 35)

A DPIA is required when processing is likely to result in high risk to rights and freedoms (Art. 35(1)). Classroom whiteboards processing children's content typically trigger that threshold under Working Party 29 guidance (children + large-scale processing of vulnerable subjects).

DrawSplat^TM does not ship a turnkey DPIA template, but the NDPA / DPA Review Packet and District Privacy Addendum cover most of the substantive content a DPIA needs: data flows, retention, security measures, third-party processors, subject rights flows. Your DPO can repackage those into your jurisdiction's DPIA template.

10. Breach notification (Art. 33–34)

You must notify your supervisory authority within 72 hours of becoming aware of a personal-data breach that poses risk to data subjects. Because DrawSplat^TM is not a SaaS hosted by DrawSplat Developer(s) — your district hosts the backend — the breach detection and notification flow runs through your existing incident response process, not through us.

That said, if you discover a security vulnerability in the open-source code itself, please report it via the contact form so the patch can ship to all deployments. We treat security reports as urgent and credit responsible disclosure.

11. Records of Processing Activities (RoPA, Art. 30)

You should keep an Art. 30 record covering each DrawSplat^TM deployment. Suggested fields:

• Controller: your school / district name + DPO contact.
• Categories of data subjects: students aged X–Y, teachers, administrators, parents.
• Categories of personal data: name (if attached to boards), student work product (board JSON), uploaded images (if enabled), audit-log events (timestamps + actions).
• Recipients: your hosting provider (Google / your MySQL host / your district IT).
• Transfers outside EU/UK: yes/no — document under Chapter V if yes.
• Retention periods: configurable in Internal Compliance Console → Retention.
• Security measures: row of TOMs taken from §7 above plus your own controls (network filtering, MFA on admin, etc.).

12. Honest gaps you should know about

To save your DPO time:

• No GDPR-targeted Standard Contractual Clauses template. DrawSplat^TM is not a controller or processor of your students' data, so SCCs don't apply between you and DrawSplat^TM. They DO apply between you and Google / your hosting provider — those agreements are unchanged by introducing DrawSplat^TM.
• No turnkey DPIA template. See §9 — use the NDPA Packet + District Addendum as source material for your jurisdiction's template.
• The drawsplat.org admin panel is not for production student data. It exists for demo and documentation. Run your own copy of the code for real classroom use, with your own admin password.
• The localStorage consent banner is the default-on path. Self-hosters who want a different consent UI can replace assets/js/consent-banner.js with their own implementation; it's a single small module.

13. Quick checklist for your DPO

Before classroom rollout in the EU/UK:

• Decide the deployment path (browser-only / Apps Script / MySQL self-host) and document it.
• Confirm controller/processor relationships with your hosting provider (Google Workspace DPA, your MySQL host's processor agreement, etc.).
• Pick a lawful basis (typically Art. 6(1)(e) public task).
• Run a DPIA using NDPA Packet + this page as source material.
• Add DrawSplat^TM to your RoPA.
• Configure retention in the internal Compliance Console.
• Update your school's privacy notice to mention the localStorage items in §6 and the data subject rights flows in §4.
• Communicate the Family Access Portal URL to parents so they have a clear path for subject rights requests.

Cross-links

• Full Terms & Privacy — the authoritative text including governing law clauses.
• District Privacy Addendum — model contract language.
• NDPA / DPA Review Packet — packet for district reviewers.
• All policy documents in one page — for printing or DPO review.
• Family Access Portal — subject-rights intake.
• Contact form — security disclosure, questions, requests.

App and Brand Identity

This page is hosted on drawsplat.org, the same public domain used for the DrawSplat^TM homepage and privacy policy. It is visible without logging in.

What DrawSplat Does

DrawSplat^TM is an interactive browser whiteboard for classroom and visual work. Users can draw, add text, shapes, sticky notes, images, audio notes, graphs, templates, panels, and classroom widgets. Teachers can create classroom links, configure collaboration rooms, review turn-ins, use moderation tools, and optionally save classroom work through a Google Apps Script backend that writes to the teacher's or school's Google Drive and Google Sheets.

GridSplat^TM is a browser-based spreadsheet, charting, and pictograph tool in the DrawSplat^TM app family. It can work without sign-in and can optionally save native .gridsplat.json files to Google Drive when a deployment enables Google Drive cloud save and a user authorizes it. AudioSplat is a browser-based multitrack recorder and editor that can optionally upload a user-selected exported audio mix to the user's Google Drive and, only when requested, ask Drive to create an Anyone-with-the-link permission for sharing and a Drive-hosted preview embed.

DrawSplat^TM tools can also run without Google access in browser-only mode. Google access is used only when a teacher, Hub administrator, user, or deployment owner chooses a Google storage path or signs in for a protected admin workflow.

Why Google Access Is Requested

Google permissions are requested to provide teacher-controlled storage, user-authorized file save/open, classroom setup, and admin authorization. DrawSplat^TM does not request Google access for advertising, profiling, selling user data, or unrelated analytics.

How Google Data Is Used

• Google account data is used to authenticate an admin session and enforce access rules for Hub or classroom setup pages.
• Drive and Sheets data is used to store and retrieve DrawSplat^TM classroom content, GridSplat^TM save files when enabled, configuration, audit records, and teacher-managed workflow records.
• Docs access is used to generate setup instructions for teachers added through DrawSplat Hub.
• Email access is used only for deployment/admin notifications supported by the Apps Script backend.
• DrawSplat^TM does not sell Google user data, use it for ads, or transfer it to advertising networks.
• Access is limited to the deployment workflows selected by the teacher, school, or Hub administrator.

Storage, Control, and Removal

For Google Apps Script deployments, the teacher, school, or Hub operator controls the Google account and Drive/Sheets files used by the deployment. DrawSplat^TM stores classroom records in that operator-controlled Google environment, not in a separate DrawSplat-hosted database by default.

For direct GridSplat^TM and AudioSplat Google Drive save, files are stored in the authorizing user's Google Drive and access is limited to the narrow drive.file scope for files created or opened by the app. AudioSplat access tokens are kept in browser memory and audio is uploaded only after the user chooses Save to Google Drive.

Administrators can remove teacher access from Hub Admin. The removal workflow deletes registry setup/admin/config entries for that teacher and attempts to remove the teacher's editor access from generated Drive folders and files. Deployment owners and users can also revoke app access in their Google Account security settings and delete DrawSplat-created or GridSplat-created files from Drive.

Privacy Policy

The full DrawSplat^TM policy packet is available at https://drawsplat.org/legal/combined-policy. That URL should match the privacy policy URL entered in the Google OAuth consent screen configuration.

District agreement status

See the State & District DPA Register for executed agreements and pending reviews. This technical packet is not an executed agreement. Contracting parties, deployment scope, data categories, notice contacts, security obligations, and signatures must be confirmed for each district.

1. Product description & approved educational purpose

DrawSplat^TM is a self-contained interactive whiteboard for K–16 classrooms. It runs as a static web app and can optionally save boards, templates, collaboration rooms, and student turn-ins to a Google Apps Script + Sheets backend the district controls, or to a self-hosted Node + MySQL backend the district runs on its own infrastructure.

Approved educational purpose: classroom drawing, notes, diagrams, charts, sticky notes, audio notes, collaboration, turn-in workflows, and supporting classroom activities. DrawSplat^TM is not used for advertising, behavioural profiling, or AI training. Full feature list.

Which deployment is your district reviewing?

Public website use: students visit DrawSplat.org to use the browser-based whiteboard, games, or other local tools without a configured storage backend. In this mode, board content and saved game progress remain on the user device or in files the user saves. The public website still receives normal web requests, and its hosting/CDN services process request metadata such as IP address, user agent, and requested URL. Public website use should not be described as involving no data processing.

District-hosted installation with MySQL: the district hosts the application, API, and database and administers accounts, storage, access, backups, retention, and deletion. Student records and work saved through that backend are held in district-controlled infrastructure. Hosting or support access by any outside party must be documented; installing the software does not itself grant the DrawSplat operator access to the district database.

Optional integrations change the scope: connecting a backend, enabling sign-in or cloud saving, sharing content, or opening third-party services requires a separate review of the selected feature and its data flow. The Google Apps Script option is also documented below but should be included in an agreement only if the district selects it.

Before completing Exhibits A and B, confirm the district’s selected website or hosting location, enabled features, student data categories, and who can access that data. The district MariaDB/MySQL path supports private saving, roster-linked classrooms, assignments, student submissions, and feedback. Validate the actual deployment and its operational controls before student use; see Recommended production posture.

2. Three deployment modes and what each collects

3. Data flow diagram

Browser-only mode:
  [Student browser] <-- board content and game progress stay local.
  [Website host / CDN] <-- page and asset requests include request metadata.

Google Apps Script mode:
  [Student / teacher browser]
      |
      |  HTTPS POST/GET, only when the teacher has configured a script URL
      v
  [script.google.com /macros/s/.../exec]  (the district's own Apps Script project)
      |
      v
  [Google Sheet]  (Boards / Rooms / TurnIns / Audit / ParentRequests / Users etc.)
      and
  [Google Drive]  (per-board JSON + PNG files in the district's Drive)

District MariaDB / MySQL mode:
  [Student / teacher browser]
      |
      |  HTTPS to the district's own domain
      v
  [district.example.org/api/drawsplat/mysql]  (Node + Express in the district's infra)
      |
      v
  [MariaDB / MySQL]  (accounts, private boards, roster membership, assignments, submissions, feedback)

4. Subprocessors

DrawSplat^TM as a product has no required subprocessors. Subprocessors only enter the picture when a district opts into a feature that needs them, and the relationship is between the district and that subprocessor — not between the vendor and that subprocessor:

5. Security controls matrix

6. Breach notification SOP

1. Discovery. A teacher, admin, parent, or external researcher reports a suspected breach via Contact / Information Request or the audit log surfaces an anomaly.
2. Triage within 24 hours. Operator confirms scope: which deployment mode, which records, which audit trail rows are affected.
3. Contain. Use the containment procedure appropriate to the backend: freeze supported Apps Script boards/rooms, revoke affected account sessions, restrict server access, or stop an affected service. Do not assume room-freeze controls cover district private boards.
4. Notify within 72 hours. Operator notifies the named district Privacy / Security Contact from the District Data Privacy Addendum using the breach notice contact method declared there. Notice includes: what happened, what data was involved, what containment was done, what the district should do next.
5. Investigate & remediate. Operator investigates root cause, patches, re-tests. The Activity Records audit log is preserved for the investigation.
6. Post-incident report. Written summary delivered within 30 days, including timeline, scope, remediation, and any changes to security controls.

7. Retention schedule

Apps Script retention windows are configurable from the Compliance Console. Its cleanup writes a RETENTION_ACTION event. District database classroom records need their own validated retention and deletion procedures.

8. Parent / student request workflow

1. Parent visits Family Access Tools and submits a request (view, export, correct, delete, pause, safety report, privacy question).
2. For the Apps Script workflow, the request lands in the ParentRequests sheet tab as pending_verification. District database requests follow the district’s separately published procedure.
3. Compliance admin gets an email notification (Apps Script MailApp.sendEmail) and reviews the request in Teacher Admin.
4. Identity verified via teacher-issued one-time 8-character code (SHA-256 hashed, 14-day expiry, single-use).
5. Verified request transitions to verified, then approved / denied / completed by an admin click.
6. Export: the Apps Script administrator downloads the student ZIP and delivers it through an approved district channel after verifying the requester. The console does not automatically email a temporary download link.
7. Delete: admin button trashes Drive files, removes rows, logs DATA_DELETED.
8. Acknowledged within 10 school days; completed within 30 calendar days when feasible.

9. FERPA / COPPA / SCOPE / CIPA crosswalks

FERPA school-official crosswalk

When DrawSplat^TM is engaged as a service provider, the district designates the vendor as a school official under FERPA’s school-official exception. Conditions:

• Performs an institutional service or function. The product is operated as part of classroom instruction (the district’s approved educational purpose stated in section 1).
• Under direct control of the school. The district controls the deployment mode (browser-only / Apps Script / MySQL), storage location, retention windows, and access rules; the District Data Privacy Addendum names the controlling district and the privacy contact.
• Use / redisclosure limits. Student data is used only for the school-authorized educational purpose. No advertising, behavioural profiling, AI training, or sale of data. No redisclosure outside the district’s subprocessors.
• Inspect / correct / delete rights. Parents and eligible students can submit a request via Family Access Tools; the District’s admin verifies and acts on the request from Teacher Admin.

COPPA school-consent notice (for under-13 users)

Under COPPA the district may provide consent on behalf of parents when the service is for an educational purpose and the district retains direct control. The district’s notice to parents typically says, in plain language:

Our school uses DrawSplat^TM, a free interactive whiteboard for classroom drawing, notes, and collaboration. The school controls all storage and access. DrawSplat^TM does not show ads, does not sell student data, does not use student work to train AI, and does not require student accounts in browser-only use. If you would like to view, correct, export, or delete your child’s data, contact the school’s published privacy contact. Schools using the Apps Script family-request workflow may also provide Family Access Tools at /parents/.

Texas SCOPE / TEC 32.151+

See legal/texas-compliance.html for the plain-language explainer.

CIPA

CIPA is a school / library E-rate internet-safety and filtering obligation, not a vendor privacy law. DrawSplat^TM supports CIPA via link allowlists, board freeze, text filtering, the moderation + image-approval queues, and the audit log, but does not replace the district’s network-level filter or its internet safety policy. Full statement: CIPA support statement.

10. District contracting documents

• Terms & Privacy
• District Data Privacy Addendum (signature-ready)
• Privacy Notice Builder (generate a local notice)
• Widget Security Boundary & Data Inventory
• Accessibility Statement
• Texas Compliance Explainer
• Compliance Roadmap
• Compliance Console Operator Guide

11. Recommended production posture

Choose the installation that matches your district’s requirements: the complete district suite provides MariaDB/MySQL account-based saving, classrooms, assignments, submissions, and feedback; the optional Apps Script deployment provides Drive/Sheets workflows and its Compliance Console. Database installer and classroom checks have been exercised with MariaDB and MySQL. This does not establish a district-wide load rating or legal certification. Validate school Google sign-in, roles, backups, restoration, retention and record-request procedures on your own deployment before student rollout. See Compliance and district review.

12. Evidence gallery (district reviewer)

These are the screens a district reviewer typically needs to see — the live Compliance Console, the Family Access Tools queue, the District Privacy Packet download, and the audit log. The CAPTURE.md checklist in the repo describes exactly where to find each one and what state to put the app in before capturing. Operators are expected to drop in their own deployment’s screenshots before sharing this page with a district reviewer, since each capture should reflect the district’s own configuration.

Operator note: replace each .evidence-placeholder div with an <img src="evidence/capture-key.png"> once you’ve captured the screen. The data-capture attribute matches the filename in docs/CAPTURE.md.

Working with us

This packet plus the District Data Privacy Addendum is the contracting surface. If your district’s review process needs a specific format, screenshot evidence, or a custom exhibit, send the request through the Contact / Information Request form and we’ll respond within five business days.

Commitment

DrawSplat^TM aims to follow the WCAG 2.1 Level AA baseline. We treat accessibility as a constraint on every new feature rather than a separate workstream, and we welcome reports of gaps through Contact / Information Request.

Conformance summary

Specific features

Keyboard navigation

• Tab / Shift+Tab cycles every focusable control on every page; no positive tabindex values are used.
• Tool and action buttons activate with Enter / Space.
• Top-nav dropdowns use the native <details name="landing-topnav"> pattern so Enter / Space opens them and Escape closes them.
• The Wheel Spinner canvas is a focusable role="button" — Space / Enter starts the spin.
• Known gap: drawing strokes, sticky-note repositioning, and shape resizing on the whiteboard canvas are not yet keyboard-driven.

Screen readers

• All interactive controls carry an aria-label matching their visible text or icon meaning.
• Icon-only buttons fall back to text via the .icon-label screen-reader-only span and a visible tooltip on focus.
• Live regions: status text in widgets and the Wheel Spinner result use aria-live="polite".
• Decorative images (illustrated heroes, brand logos in headers) use empty alt=""; informational hero images describe their content in alt.
• Known gap: the whiteboard canvas itself is not announced as a structured drawing surface; screen-reader users hear "DrawSplat whiteboard region" but not individual shapes.

Contrast & colour

• Body text against background tested at WCAG AA (4.5:1 or better) on every legal and marketing page.
• Status / result colours never rely on colour alone — e.g. the Untangle "intersection" indicator uses a count + a colour, and required form fields use a label + an asterisk.
• The Lights Out game offers three themes (Cyber Neon, Terminal Amber, Minimal Slate) so users can pick the contrast that works for them.

Motion & animation

• Wheel Spinner uses an ease-out spin animation. Decorative confetti respects screen size and decays in under three seconds.
• No game uses parallax or strobing effects.
• Planned: honor prefers-reduced-motion: reduce on the Wheel Spinner and confetti.

Font scaling & zoom

• All pages set <meta name="viewport" content="width=device-width, initial-scale=1"> with no user-scalable=no — pinch-zoom and browser zoom work everywhere.
• Layouts use CSS Grid / Flexbox with minmax(), clamp(), and percentage widths so zooming to 200% does not introduce horizontal scrollbars on the main content column.

Audio

• Every game with sound has a 🔊 / 🔇 mute toggle in the controls bar.
• Sounds are Web Audio synthesised — short blips and arpeggios — not narration. No essential information is conveyed only via audio.

Forms

• Every form field has a visible <label> tied via for.
• Error messages render in a role="status" live region close to the field.
• The Contact form, Family Access Tools form, and post-composer all use semantic <form>, <input>, and <textarea> — no custom widgets impersonating fields.

Assistive-tech tested with

Spot-tested with macOS VoiceOver in Safari and Chrome and with Windows NVDA in Firefox and Chrome. We have not yet completed a full structured audit. If your district’s VPAT process needs a specific assistive-tech matrix, send a request via Contact / Information Request.

Known gaps

• Canvas-driven keyboard drawing. Whiteboard shape creation, repositioning, and erasing require pointer input. Keyboard-only users can navigate the menubar and dialogs but cannot draw freehand strokes.
• Untangle / Flow Free / Tangram on keyboard only. These games require pointer drag. Mouse / touch / stylus input works; a keyboard-only fallback is on the roadmap.
• Reduced-motion preference. Some game spin / confetti animations don’t yet honour prefers-reduced-motion; planned for the next minor release.
• Localized screen-reader labels. Most UI strings are English; data-i18n labels in the Community Board are translated, but admin tooling is English-only.
• Structured VPAT 2.5 document. The ITI VPAT form has not been completed in full. Available on request as a separately scoped service.

Report a barrier

If you hit an accessibility barrier, please file a report through Contact / Information Request. Include the page URL, the assistive tech (if any), and a short description of what didn’t work. We aim to acknowledge within five business days and to prioritise blockers that prevent a student from completing a classroom task.

Widget Security Boundary — the short version

• Same origin, same project. Every standalone widget under /solutions/ and every game under /games/ is served from the same origin as the DrawSplat^TM static site. They are not iframed third parties.
• No third-party advertising, analytics, or trackers. Visit counts come from Cloudflare Pages’ server-side metrics on the static-host CDN; no beacon, no tracking pixel, no third-party JS is loaded on widget pages.
• Strict Content Security Policy. Pages declare default-src 'self', script-src 'self', style-src 'self' 'unsafe-inline', img-src 'self' data:, connect-src 'self', and object-src 'none'. Widgets that need an outbound request (e.g. Apps Script) extend connect-src with the specific host. Production hosts should also send frame-ancestors 'none' as an HTTP header.
• No student data leaves the browser unless a backend is configured. Standalone widgets run entirely in the visitor’s browser. Only the whiteboard at /app/whiteboard.html talks to a backend, and only if the district has set up the Google Apps Script or MySQL backend.
• Local storage is per-widget and disclosed. Some widgets save the user’s last setup in localStorage for convenience. None store student-identifying data.
• Permissions Policy default-off. No widget requests camera, microphone, geolocation, or payment. The whiteboard’s audio-note feature is the single exception — it requests microphone access only when the user explicitly clicks Record.
• Image uploads. Until the Phase 1.3 / 1.4 image-upload approval queue ships, student image uploads on the whiteboard are disabled by default in the supported Apps Script deployment. Teachers and admins can still attach images; student-side uploads stay off until the moderation queue lands.

Per-widget data inventory

Every widget and game served from this site is listed below. Columns: where the widget runs, what local storage it uses, what external network requests it makes during normal play, and whether it touches student-identifying data.

Classroom widgets (/solutions/)

DrawSplat^TM Games (/games/ and /solutions/dotsboxes/)

Whiteboard and admin pages

Network egress declaration

By default a fresh install of DrawSplat^TM makes zero outbound network requests from a widget page. Outbound requests happen only when:

• A teacher has pasted an Apps Script /exec URL into Teacher Admin. The whiteboard, Family Access Tools, and Community pages then call that URL only (connect-src 'self' https://script.google.com https://*.googleusercontent.com on the relevant pages).
• A district has stood up the self-hosted Node + MySQL backend and pointed the whiteboard at it. In that case the whiteboard calls https://<district-domain>/api/drawsplat/mysql.
• The visitor signs in with Google or Microsoft on the Community Board. The browser then talks to accounts.google.com (Google Identity Services) or, for the Microsoft path, the lazy-loaded MSAL CDN script and Microsoft Graph.

No widget calls advertising, analytics, third-party-tracker, or social-network domains. The repository commit history and the inline <meta http-equiv="Content-Security-Policy"> on every page are the verifiable record.

iframe / embed posture

Production DrawSplat^TM hosts should send frame-ancestors 'none' in the HTTP Content Security Policy header. A school portal that wants to embed a DrawSplat^TM widget should run the embed in an <iframe sandbox="allow-scripts allow-same-origin"> with only the permissions the widget actually needs — never enable allow-modals, allow-popups, or allow-top-navigation unless the specific widget documents that it requires them. The portal’s own Permissions Policy should also disable camera, microphone, geolocation, payment, and usb on the embed unless the specific widget needs them.

Where this fits in the privacy story

• Terms & Privacy — the overall policy and the legal commitments.
• District Data Privacy Addendum — signature-ready template for school / district contracting.
• Texas Compliance — plain-language SCOPE / FERPA / COPPA / CIPA explainer.
• NDPA / DPA Review Packet — the bundle every reviewer typically asks for.
• Privacy Notice Builder — generate a local privacy notice for your school.

USA — Federal

COPPA (Children's Online Privacy Protection Act)

• No built-in parental consent collection flow. DrawSplat^TM is designed to be deployed by schools, which typically rely on the COPPA school-authorization carve-out (school acts as the parent's agent for consent for instructional purposes). If you operate DrawSplat^TM outside of school authorization — for instance, a parent-facing direct-to-consumer product or a public after-school club where parents register children individually — you must collect verifiable parental consent yourself. The product does not ship a verifiable-consent flow (credit-card check, government-ID check, signed form upload, etc.).
• No automated COPPA notice generator. The Privacy Notice Builder can produce a customized notice, but you fill in the COPPA-specific fields by hand; we do not generate the FTC-style "Notice to Parents" form for you.

FERPA (Family Educational Rights and Privacy Act)

• The district is the educational agency under FERPA, not DrawSplat^TM. Subject access requests (parents requesting their child's education records) must be handled by the district. The platform provides export endpoints (Internal Compliance Console → Student Data Export) but does not include a parent-facing FERPA-request intake form. The Family Access Portal scaffolds this; the district configures verification and SLA.
• No automated annual notification. 34 CFR § 99.7 requires the school to give annual notification of FERPA rights; the platform does not generate or distribute that notice.
• No directory-information opt-out flow at the platform level. If your district designates board labels or display names as directory information, the opt-out workflow lives in your SIS, not in DrawSplat^TM.

CIPA (Children's Internet Protection Act)

• DrawSplat^TM is not a network filter. CIPA requires the school to deploy a "technology protection measure" at the network level that blocks visual depictions of obscenity / child pornography / harmful-to-minors content. DrawSplat^TM ships safety primitives (link allowlist, text keyword filter, image approval queue) that support CIPA but do not replace your district's network filter or its internet safety policy. See CIPA support statement.

USA — Texas

SCOPE Act (Texas Securing Children Online through Parental Empowerment Act)

• No age-verification mechanism at the platform level beyond the optional Age Band Lock. SCOPE focuses on operators of digital services directly used by minors. In a school deployment the district handles age registration in its SIS; DrawSplat^TM doesn't independently verify a user's age. If you deploy outside a school SIS context, you would need to add age verification yourself.
• No advertising / monetization controls — because we don't advertise. SCOPE restricts targeted advertising to minors. DrawSplat^TM runs zero advertising and no third-party trackers, so the rules are moot in this product. There is no "ad preference" UI because there is nothing to set preferences against.
• Harmful-content strategy is district-side. SCOPE requires operators to publish a strategy for preventing minors from accessing harmful content. Text and link safety filters ship in the Compliance Console; the broader strategy document (which the law requires you publish on your service) is something the district adapts from the model language in Texas Compliance and District Privacy Addendum.

TEC 32.151–32.156 (Student Data Privacy Agreements)

• District-specific TEC agreement required. Open-source licensing and the review packet do not substitute for a signed agreement. The district and provider must identify the contracting party, actual service scope, data access, and applicable obligations. See the DPA Register for verified execution status and pending reviews.

State NDPA (Network of Data Privacy Agreements) interoperability

• Consortium listing and execution status. Open-source licensing and the review packet do not substitute for a signed agreement. The district and provider must identify the contracting party, actual service scope, data access, and applicable obligations. See the DPA Register for verified execution status and pending reviews.

European Union / United Kingdom — GDPR & UK GDPR

Controller / processor contracting

• Article 28 contracting depends on the deployment. Confirm the controller, processor, hosting arrangements, and actual data access before determining which agreements are required. The review packet is not an executed processor agreement.
• No turnkey Standard Contractual Clauses (SCCs). Review international transfers and the actual parties involved with the district’s privacy adviser before selecting transfer terms.

Data Protection Impact Assessment (Art. 35)

• No automated DPIA template. Classroom whiteboards processing children's content usually trigger DPIA threshold under Working Party 29 guidance. The GDPR Compliance Summary, NDPA Packet, and District Privacy Addendum together cover the substantive content a DPIA needs, but your DPO must repackage that into your jurisdiction's DPIA template (CNIL in France, ICO in the UK, etc.). We do not generate the DPIA file for you.

Consent and cookie/storage notice

• Consent banner is acknowledge-only, not granular. The localStorage notice has one "Got it" button. We do not offer granular toggles for "necessary / preferences / analytics / advertising" because the platform stores nothing in those last two categories — there is no analytics and no advertising. Strict EU jurisdictions sometimes expect granular controls even when categories are empty; if your DPO insists, replace assets/js/consent-banner.js with a Cookiebot / OneTrust / Klaro integration in your self-host fork.
• No "withdraw consent" workflow. Because the only "consent" we collect is acknowledgement of a localStorage notice, there's no withdrawal flow — clearing your browser's storage clears it. For school-mediated processing the relevant legal basis is typically Art. 6(1)(e) public task, not consent, so withdrawal isn't applicable.

Children's data (Art. 8)

• No direct-to-consumer parental consent flow. Same reason as the COPPA gap above. The school-mediated deployment model is the intended use; direct-to-parent registration is not.

Data subject rights (Arts. 15–22) — subject-initiated path

• Identity verification for subject requests is district-configured. The Family Access Portal accepts requests but does not perform identity verification itself (no government-ID upload, no notarized form, no SAML login). Your district decides how to verify a requestor's identity and configures the intake accordingly.
• No 30-day SLA timer. GDPR Art. 12(3) requires response "without undue delay and at the latest within one month." The platform does not track request age or send reminder emails to administrators; that's on your case-management workflow.

Records of Processing Activities (Art. 30)

• No RoPA template. The GDPR Compliance Summary §11 lists the suggested fields you should record; we don't generate or maintain the RoPA file itself.

Breach notification (Arts. 33–34)

• No automated 72-hour breach notification. The platform does not detect breaches in your hosting environment (we have no telemetry to do so). Your incident response process runs through your hosting provider and supervisory authority. If you find a vulnerability in the open-source code, report it via the contact form and we'll patch and release.

Cross-cutting gaps that apply everywhere

• No Data Protection Officer on file. DrawSplat^TM is open-source software, not a corporate entity with a designated DPO. The named contact for security issues and questions is DrawSplat Developer(s) at [email protected] or via the contact form; that's not a substitute for your district's DPO.
• No SOC 2 / ISO 27001 attestation. Same reason — there's no SaaS operator to be audited. If your procurement office requires those, point them at your hosting provider's attestation (Google Workspace and major MySQL hosts have them).
• No formal subprocessor list. The platform itself uses no subprocessors (no SaaS dependencies, no analytics, no advertising). When you self-host the MySQL backend, YOUR hosting provider is a subprocessor between you and your students — that's covered in your contract with them, not in ours.
• No bug bounty program. We do credit responsible disclosure publicly. There is no monetary reward.
• Penetration test cadence is informal. Code is open-source and your security team can audit it directly; we do not publish scheduled third-party pen-test reports.
• Accessibility audit is informal. The Accessibility Statement describes the standards we target and the known issues; there is no third-party WCAG audit certificate.
• No vendor questionnaire pre-filled. Common district vendor questionnaires (HECVAT, SIG, CAIQ) are not pre-completed. Most of the data points needed are in the existing policy documents; you map them to your questionnaire format manually.

Things we deliberately do not do

Some "gaps" are intentional design choices, not roadmap items:

• No telemetry. Nothing about user behavior is reported back to anyone. This means we cannot proactively detect misuse, generate usage analytics for your district, or surface aggregate adoption metrics. If your district wants those, you instrument them at your hosting layer.
• No third-party JavaScript. All runtime dependencies are local files. This means we cannot use Google Analytics, Mixpanel, Sentry, etc. for error tracking — your hosting provider's logs are the source of truth.
• Identify the contracting provider and deployment. Open-source licensing and the review packet do not substitute for a signed agreement. The district and provider must identify the contracting party, actual service scope, data access, and applicable obligations. See the DPA Register for verified execution status and pending reviews.
• No mandatory cloud features. Browser-only mode works fully. Cloud sync, Google Drive save, MySQL backend, image approval, parent portal — all opt-in. This lets a school start without ANY data processing concerns and scale up only as policy allows.

How this list is maintained

Every commit that closes a gap should remove the relevant bullet here. Every commit that introduces a new compliance obligation should add a bullet. If you spot something we've missed — a regulation you need that isn't named — please file it via the contact form and we'll either close the gap or document it here.

Cross-links:

• GDPR Compliance Summary
• Texas Compliance
• Terms & Privacy
• District Privacy Addendum
• NDPA / DPA Review Packet
• All policy documents in one page