DrawSplat^TM is designed to collect as little student data as possible.

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

The free version is provided under the license stated in the DrawSplat^TM repository and README. Paid one-time licenses and self-hosted site licenses cover the current as-is build unless a separate written agreement says otherwise. DrawSplat^TM is provided without guarantees of uninterrupted service, fitness for a particular purpose, managed hosting, custom support, 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.