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.

Family projects (no account or class code)

The free /family journey asks for no child name. Project choices, owned parts, bounded logic blocks, wiring progress, controls and fixed-choice feedback stay in this browser for up to 30 days. Parents can download, restore or clear the project. Reports are downloaded only when you choose; they are not uploaded to CHIPS. Google Analytics, PostHog, Vercel Analytics and Speed Insights do not run on family pages.

Ask CHIP is optional and requires a grown-up to enable it. When configured, it sends the question, up to eight recent messages and the current project context to Vercel AI Gateway and its provider with required zero-data-retention routing. Operational usage and security metadata may remain. Chat stays in page memory and is excluded from saved projects, reports and application logs. Only explicitly accepted logic blocks become part of the project. A signed temporary approval cookie expires after one hour; a checkbox does not verify parental identity.

Voice is separately optional. The browser speech service may process audio remotely. Recognized words appear as an editable draft; the child chooses Send. Replies can be read aloud, stopped or muted. AI cannot verify the real circuit in the family journey. A grown-up checks physical wiring.

Open class (no class code)

While we test CHIPS, any child can start for free at /start by typing a first name. There is no account, no email and no class code.

  • What we keep: the first name or nickname the child types, their lesson progress (which lessons they opened and finished, their step and their stars), and a random session code in a secure cookie so this device can come back to the same progress. We also note which of our links they came from (ArduinoStudio, the CHIPS home page, or straight in). The lesson records described below for classes (wiring-mistake counts, saved boards, device-local state) work the same way.
  • What we never ask for: surname, email, password, age, school or a photo of the child. No ads. No analytics trackers on /start or the lesson pages.
  • Progress is tied to this device. The cookie lasts up to 60 days. Another device starts fresh. “I’m someone else” on /start removes the child from this device.
  • Who sees it: the CHIPS team watches open-class learners in the teacher dashboard (first name, progress, last seen, and the help flag). Other children never see it.
  • The camera: the camera mentor on /try cannot start until someone ticks “A grown-up is with me”. It sends pictures to our AI helper to check the wiring. We don’t save the pictures.
  • When it is deleted: the open class has an end date. Within six weeks after it ends, we delete every open-class name and all open-class progress, with the same deletion script that removes a class’s data after its 30-day grace window. A grown-up can also ask us to delete a child’s open-class data at any time: email CHIPS@inteRFaceRnD.com with the first name and the day they started.

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.
  • Wiring mistakes (checked-circuit lessons) — each wrong wire connection is recorded as two circuit-terminal codes from a fixed list (for example ard.D13 and ard.A0) plus the lesson, the step and an attempt number. The record carries the class code but no student identifier and no free text, the server rejects anything outside that fixed vocabulary, teachers see only a per-class daily count, and each record expires after 90 days.
  • 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 and wiring-mistake records 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 (wrong wire connections in checked-circuit lessons are the exception: those go to the server as described above). 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 (/), on the open-class start page (/start) and across the complete /studentroute tree before their scripts initialize, and Vercel’s page-view counter and speed measurement are not loaded on those pages either. 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. For the class as a whole, the teacher sees how many wiring mistakes were made today — a single number, never which student or which wires.
  • 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. Wiring-mistake records carry no student identifier, so they cannot be matched to one student; they are deleted with the class and expire on their own after 90 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, wiring mistakes, 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 and for the public /try demo requests (idea, project and camera-frame calls). It receives browser signals for that check, never a name, an idea or a frame. On the other pages (not the classroom home, /start or /student) it also counts page views and measures page speed, without cookies (Vercel Web Analytics and Speed Insights).
  • 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.
  • Google Gemini (AI provider) — the project-idea helper and the camera mentor on the public /try page. A typed project idea, and, once a grown-up has ticked “A grown-up is with me” and started the camera mentor, one downscaled camera frame of the desk every few seconds, are sent to Google to be checked. CHIPS never saves a frame, an idea or the answer; Google’s own API terms govern what it keeps. If Google does not answer, the typed idea (never a camera frame) may be retried once through a second AI provider (Groq, or OpenRouter when Groq is not configured), under the same rules. The class and open-class lesson pages send nothing to it. Google’s Gemini API terms.

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.

The open class does not run under a school’s consent. It asks for nothing beyond a first name or nickname, collects no contact details of any kind, and puts a grown-up check in front of the camera.

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-10-12. 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.