The Teacher's Sandbox
For district IT & administrators

Dear IT Department,

A teacher sent you this page because they'd like to use a Sandbox Kit. Here's how the kits handle data, and how you can check it yourself in a few minutes.

Short version: Sandbox Kits have no backend. We don't operate any server, database, analytics service or license server that a kit talks to. Web Apps run from a single local HTML file, and their Content Security Policy blocks every network connection. Google Workspace tools run as a script bound to a Sheet or Doc that the teacher owns. We, the vendor, never receive or have access to student data.

What we receive

DataWho handles itStudent data?
Purchaser name, email and paymentOur payment processor (Gumroad or Lemon Squeezy). We receive the buyer's name and email so we can deliver the purchase.No
Anything entered into a kit (rosters, grades, notes)Stays on the teacher's device, or in the teacher's own Google accountNever sent to us
Usage analytics, crash reports, telemetryNone are collected—
License activation or check-insNone. Kits never check a license online.—

Tier A: Off-Grid Web Apps

Architecture

  • Each app is delivered as a single index.html file, with all HTML, CSS and JavaScript inline. There are no external scripts, CDNs, web fonts, images or iframes.
  • It runs from the local file system (file://), a USB drive or any static folder. You don't install anything, and it doesn't need admin rights.
  • Data is saved in the browser's own storage (localStorage / IndexedDB) for that browser profile on that device. Chrome sync does not sync this storage.
  • Teachers can back up with an "Export" button that saves a JSON file on the device, and restore with "Import." Neither involves a network transfer.
  • Teachers can move rosters between kits with a class list file: a local JSON file that holds only class names and student names (no IDs, grades or notes). The free Build Your Class tool creates it, and every kit can import it or a CSV the teacher exports from their own spreadsheet. The file is read in the browser with the File API and is never uploaded.

Enforced by the browser, not just by promise

Each Web App declares this Content Security Policy in its <head>:

<meta http-equiv="Content-Security-Policy"
      content="default-src 'none';
               script-src 'unsafe-inline';
               style-src 'unsafe-inline';
               img-src data: blob:;
               font-src data:;
               connect-src 'none';
               form-action 'none';
               base-uri 'none'">

With default-src 'none' and connect-src 'none', the browser refuses fetch, XHR, WebSocket, sendBeacon and loading any remote script, style, image, font or frame. form-action 'none' stops form submissions. 'unsafe-inline' is needed only because the app is one self-contained file. Since no external source is allowed, inline code has nowhere to send data.

How to verify (about five minutes)

  1. Open the app in Chrome, open DevTools (F12) and go to the Network tab. Use the app for a while. The only entry you should see is the local file itself.
  2. Turn off Wi-Fi or unplug the network. The app works exactly the same.
  3. Open index.html in any text editor. It's readable, not minified or obfuscated, so you can search it for fetch, XMLHttpRequest or http.
  4. Check the CSP <meta> tag near the top of the file.

One thing to know

Browser storage belongs to the device and browser profile. On a shared computer, anyone using the same profile can open the app and see its data. We recommend using kits on a teacher-assigned device or profile, following your usual device policies.

Tier B: Google Workspace Power Tools

Architecture

  • Each tool is a container-bound Google Apps Script inside a Sheet or Doc template. The teacher clicks "Make a copy," and the template and its script are copied into their Drive. They own that copy.
  • We have no access to the teacher's copy. We can't see it, edit it, push updates to it or receive anything from it.
  • The script runs under the teacher's Google identity, inside your Workspace tenant, and is subject to your existing Workspace policies.
  • The source code can be read in full under Extensions → Apps Script.
  • No web app deployments, no published add-ons and no external service integrations.

Minimal, declared OAuth scopes

Each script lists its scopes explicitly in appsscript.json. None of them request script.external_request, which Apps Script requires before a script can use UrlFetchApp. Without that scope, the script can't contact outside servers.

KitScopesWhy
Gradebook Guardianspreadsheets.currentonly
script.container.ui		Read and write only the Sheet it lives in, and show its menu and pop-up windows.
Family Update Mail Merge (in development)spreadsheets.currentonly
gmail.compose
script.container.ui		Read the Sheet and create drafts in the teacher's Gmail for them to review and send.

About the "unverified app" screen

Depending on your Workspace settings, teachers may see Google's "Google hasn't verified this app" screen the first time they authorize a copy. It appears because each copy is a private script owned by the teacher, not a publicly listed app that has gone through Google's review. The authorization screen lists exactly the scopes above. If your domain restricts Apps Script or unverified apps, the scope table on this page is what you'd need to review.

Questions

We're happy to answer technical questions or send a review copy of any kit to your team.dan@dantheman3d.com

Thanks for looking out for our students' privacy. We built these tools with the same goal.
— Dan, teacher & technology coach, The Teacher's Sandbox