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 is released under the GNU AGPL-3.0-or-later as stated in the repository LICENSE file. 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 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 is 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 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.
• 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, upload media, record audio, save locally, export, or send a board to a configured backend. Browser-only mode stores data in the local browser. Google mode sends configured board data to the teacher or organization’s Google Apps Script deployment. 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, restoring autosaved work, supporting classroom rooms, saving or loading boards, 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, 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. 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.
• 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 immutable 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 Teacher Admin → 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 Teacher Admin → 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 Compliance Console (Teacher Admin → 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) — immutable Sheet tab tracking every compliance-relevant action.
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.

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', object-src 'none', frame-ancestors 'none'. Widgets that need an outbound request (e.g. Apps Script) extend connect-src with the specific host.
• 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

DrawSplat^TM pages set frame-ancestors 'none' in CSP. 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.

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.

2. Three deployment modes and what each collects

3. Data flow diagram

Browser-only mode:
  [Student browser] <-- everything stays here. No external requests by default.

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)

Self-hosted 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
  [MySQL]  (users, sessions, boards, audit_events, parent_requests, time_usage, ...)

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. Freeze affected boards / rooms (server-enforced write block). Revoke active sessions on the self-hosted backend. Disable affected Apps Script deployment if necessary.
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

All retention windows are district-configurable from Teacher Admin → Compliance Console → Retention. Every cleanup writes a RETENTION_ACTION audit row with counts.

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. Request lands in the ParentRequests sheet tab / DB table as pending_verification.
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: one-click ZIP of the student’s boards + turn-ins + user row (no hashed credentials), emailed as a 15-minute 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, use Family Access Tools at /parents/ on the school’s DrawSplat^TM site.

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

For classroom production use today, the supported path is Google Apps Script + Sheets + Drive in the district’s own Google Workspace tenant. The MySQL self-hosted path is feature-complete in code but has not yet been exercised against a live database in production. Districts that want to pilot the MySQL path should run a technical review (integration test against a non-production database, single-instance only, manual cron monitoring) before student production use. See server/mysql-backend/README.md for the production checklist.

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.