Skip to article
DrawSplat Wiki
Read in your language
Privacy and district review
Source

Widget Security Boundary

Per-widget security boundary and data inventory

Current deployment scope

Use the wiki’s compliance and district review reference to match this document to your actual installation. Apps Script console controls apply to Drive/Sheets workflows; they do not automatically administer district MariaDB/MySQL private boards, rosters, assignments, submissions, or feedback. Templates and review packets do not establish a signed NDPA/DPA or certify legal compliance.

Districts and reviewers asked for a single page that answers: "What does each DrawSplatTM widget actually do with student data?" This page lists every widget and game served from the DrawSplatTM static site, what it stores, what external requests it makes, and what student data (if any) it collects.

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 DrawSplatTM 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/)

WidgetlocalStorage / sessionStorageExternal requestsStudent-identifying data
Bingo Card GeneratorNoneNoneNone
Bingo CallerNoneNoneNone — player names typed at runtime stay in memory
Coin FlipperNoneNoneNone
Concept Map StudioNoneNoneNone — node labels, links, and attached images typed or pasted at runtime stay in memory
Dice RollerNoneNoneNone — optional player names typed at runtime stay in memory
Dicebreaker CreatorNoneNoneNone
Draw & SketchNoneNoneNone
Fortune Wheel (teacher)Saved setup blobs (no student data)NoneNone
Fortune Wheel (student)NoneNoneNone
Markdown StudioAuto-save of the current document onlyNoneNone unless the user pastes such data into their own document
VideoSplatProject manifests and user-selected media blobs in IndexedDB; same-origin app shell in Cache StorageNone — media analysis, editing, anonymization, and export run locallyOnly content present in media the user explicitly selects; it remains in that browser unless the user exports a file
Meme PuzzleNoneNoneNone
Mermaid Diagram StudioNoneNone — loads /vendor/mermaid.min.js from the same origin only; Mermaid runs with securityLevel: 'strict' so embedded HTML/JS in diagram source is sanitizedNone — diagram source typed at runtime stays in memory
Quiz & Flashcard StudioSaved quiz drafts and local report rows only when the user clicks Save DraftNone — loads /vendor/jszip.min.js from the same origin only for XLSX/ODS/ODT import and XLSX exportNone unless the user types student names into local player/report fields; stays in their browser
Rubric BuilderSaved rubrics drafted by the userNoneOnly if the user types student names into a rubric; stays in their browser
Story WheelSaved prompt setsNoneNone
Wheel SpinnerNoneNoneNone — entries typed at runtime stay in memory
Word Search MakerNoneNoneNone

DrawSplatTM Games (/games/ and /solutions/dotsboxes/)

GamelocalStorage / sessionStorageExternal requestsStudent-identifying data
Castles & CatapultsNoneNoneNone — optional player names typed at runtime stay in memory
Dots and BoxesNoneNoneNone — optional player names typed at runtime stay in memory
Flood FillNoneNoneNone
Flow FreeNoneNoneNone
Fun QuizNoneNoneNone
Lights OutNoneNoneNone
Tangram PackingNoneNoneNone
UntangleNoneNoneNone

Whiteboard and admin pages

PageStorageExternal requestsStudent-identifying data
/app/whiteboard.htmlLocal .drawsplat.json save format; optional localStorage for preferencesOnly the configured Apps Script /exec URL (if a teacher has set one) or the self-hosted MySQL backend URLOnly the data the school or district explicitly entered — e.g. student name on a turn-in. No data leaves the browser unless a backend is configured.
/admin/admin.html (Teacher Admin)Local admin preferences; admin passcode prompt held in memory onlyConfigured Apps Script /exec URL onlyAdmin reads / writes age band, parent requests, audit log, etc. — only when explicitly invoked by the admin.
/parents/index.html (Family Access Tools)NoneConfigured Apps Script /exec URL only, when a parent submits a requestThe parent submits their own name/email plus the student name they request data for. Used only to route the ticket to the school admin.
/community/ (Community Board)Sign-in token (HMAC bearer) and "last visited" timestampThe Community Apps Script /exec URL configured by the site operatorAuthor name + email on posts that the user voluntarily submitted to the board. Used for moderation routing.
/blog/ (Blogs About DrawSplat)NoneOnly a same-origin fetch of /blog/drawsplat.rss. Click-throughs on each card open the source blog in a new tab. The Subscribe-via-RSS button is a plain anchor to https://raindrop.io/collection/71392298/feed — no fetch from the page itself.None — the RSS file ships in the static repo (a snapshot of an operator-curated Raindrop.io collection); post titles, authors, and excerpts come from that snapshot.

Network egress declaration

By default a fresh install of DrawSplatTM 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 DrawSplatTM hosts should send frame-ancestors 'none' in the HTTP Content Security Policy header. A school portal that wants to embed a DrawSplatTM 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