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

1. Terms of Service

Who May Use DrawSplat

DrawSplat may be used by individual educators, students under school supervision, families, small teams, schools, districts, and organizations. When DrawSplat 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 to upload, store, share, or distribute unlawful, harmful, harassing, discriminatory, invasive, confidential, or unsafe content. Do not use DrawSplat 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 does not claim ownership of user-created boards, student submissions, or uploaded media. If a teacher or organization hosts DrawSplat, 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 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 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 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 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 app does not require login and does not collect data on its own server. Depending on how a user or school configures it, DrawSplat 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 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 version.

De-identified and Aggregate Data

DrawSplat 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 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 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 is used solely for the school-authorized educational purpose.

3. TCEA PROTECT Privacy Commitments

4. Storage Modes and Retention

5. Third Parties

DrawSplat’s static pages do not require third-party analytics, advertising, or tracking. 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 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 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 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 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