Kids privacy

No student email. No student password. No student account.

CHIPS is built so young students can learn Arduino in a classroom without standing up an account. Privacy follows from that — we collect the smallest amount of data needed to make the class work, store it in named third-party services, and delete it when the class ends.

What we collect when a student joins a class

For each student who joins a class on chips.arduinostudio.com, CHIPS stores:

  • Display name — the student either chooses a built-in robot name or enters a first name, nickname, or initial when joining. No surname. No email. No date of birth. No password.
  • Class code — a short identifier given to the student by their teacher (e.g. AB12CD). Tied to the school’s class license.
  • Lesson progress — which lessons the student opened, started, or marked “done” via the in-page button. Plus a “needs help” flag the student can raise for the teacher.
  • Saved board (when the chips-native canvas ships) — when a student saves their work, we store an identifier pointing at the board document so the student can continue next class.
  • Student session cookie — a random opaque token stored in a secure, httpOnly cookie ties first-party requests to the same student session. The browser never exposes this bearer token to lesson JavaScript or localStorage, and the backend stores only its SHA-256 hash. It is not an advertising or cross-site tracking cookie.
  • Device-local convenience state — the browser may store the remembered class code; avatar cosmetics, theme and coin state; narration preference; and local copies of lesson state such as the current step, stars, completion, self-assessment, task checklists, and wiring/logic/GUI canvas progress. Lesson and canvas records are scoped by the authenticated student’s non-secret record id so the next child using the same class device does not inherit them. These browser caches stay in localStorage or sessionStorage and are not uploaded separately; the corresponding server lesson-progress events described above remain visible to the teacher.
  • Interactive lab state — non-text checks and the current wiring step can remain on the device for up to 8 hours, then the record is deleted. Prediction, observation, and fix reflections are memory-only: free text is never written to localStorage or sent to CHIPS and disappears when the page reloads.

We do not collect: surname, date of birth, email address, parent contact, photo, voice recording, geolocation, school grade, IP address (beyond what our hosting providers log for security), or any device identifiers used for advertising. Google Analytics and PostHog are both blocked on the classroom home (/) and across the complete /student route tree before their scripts initialize. We do not use third-party advertising or analytics trackers on those child-facing pages, and we never sell or share student data or use it to build profiles for anything other than running the class.

Who can see what

  • The teacher for a class sees, for each student in that class: first name, lesson progress, last-seen timestamp, and the “needs help” flag.
  • The CHIPS admin (the school’s license holder, or a designated CHIPS staff member) can list classes, see seat counts, and delete a class’s data on request.
  • Students do not see each other’s data.
  • Nobody outside this list — no advertiser, no partner — receives student data.

How long we keep it

  • While the class license is active: student data is kept so the teacher can run the class.
  • After a class license ends or is canceled: a 30-day grace window lets the school export the class’s data as CSV if they want a record.
  • After the 30-day grace: CHIPS hard-deletes all student sessions and progress for that class, plus any saved boards tied to those students. There is a maintenance script that performs the deletion (backend/scripts/purgeEduData.ts — open-source, you can verify the behavior).
  • On request: a parent or the school can ask CHIPS to delete a specific student’s data at any time. Email CHIPS@inteRFaceRnD.com with the class code and the student’s first name; we confirm with the school’s registered admin and delete within 7 days.

Where the data lives (subprocessors)

CHIPS uses these third-party services to run the application. Each has access only to the data needed to provide its service.

  • MongoDB Atlas — class licenses, student sessions, lesson progress, saved boards. MongoDB’s US-East region.
  • Railway — runs the CHIPS API backend. US-West region.
  • Vercel — serves chips.arduinostudio.com pages and provides invisible bot verification for the adult program-update form.
  • AWS S3 — project screenshots and shared assets, US region.
  • Google Analytics 4 — aggregate page-view counts on adult marketing and operator pages. It is blocked on the classroom home and all student pages. No personal identifiers sent. Google’s privacy policy.
  • PostHog — explicit product events on adult marketing and operator pages only. It is blocked on the classroom home and across the complete student route tree, and does not receive student pageviews or lesson events.
  • Gmail SMTP — transactional and marketing email sent to adults (teachers, school admins, the marketing list). Never used to email students.

For US schools (FERPA / AB 1584 / COPPA)

CHIPS is designed to act as a school official with a legitimate educational interestunder FERPA. The data above is treated as student education records under the school’s direction. For paid school deployments, CHIPS signs a Data Processing Agreement that:

  • Names the data CHIPS processes (the list above) and limits its use to providing the CHIPS service.
  • Prohibits selling student data, targeting advertising at students, or building profiles for any purpose beyond delivering CHIPS.
  • Names a deletion deadline (30 days after the class license ends, or on request).
  • Names a security-incident notification process.

CHIPS is intended for classroom use under a school’s authority. For COPPA, this falls under the school-consent path — the school provides the consent to collect the limited data above on behalf of parents.

This page is operational documentation, not a legal contract. The actual binding terms are in the DPA + Terms of Service a school signs before paid deployment. If you are a school evaluating CHIPS and want a copy of the DPA template, email CHIPS@inteRFaceRnD.com.

For EU students

CHIPS is not currently sold directly to EU students. If a school in the EU enrolls a class, the school acts as data controller and CHIPS as data processor under GDPR. Cross-border data transfers to the US (where MongoDB Atlas, Railway, Vercel, and AWS S3 run) rely on Standard Contractual Clauses where applicable. Contact CHIPS@inteRFaceRnD.com for EU-school specifics.

Contact

Questions, deletion requests, or DPA requests: CHIPS@inteRFaceRnD.com.

Last updated: 2026-07-30. inteRFace R&D · CHIPS@inteRFaceRnD.com. This document describes how the CHIPS service handles student data today; it is reviewed when the service’s data collection or subprocessors change.