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:

  • First name — the student types it once when they join the class. A nickname or initial is fine. 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.
  • Hashed session cookie — a per-tab token stored in an httpOnly cookie that ties subsequent requests to the same student session. Not a tracking cookie; not shared with any third party.
  • Lesson-checklist state — which task checkboxes the student ticked on the build page, persisted to the student’s browser localStorage only. Never sent to our servers; never visible to the teacher.

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. We do not use third-party advertising or analytics trackers on student 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.
  • AWS S3 — project screenshots and shared assets, US region.
  • Google Analytics 4 — aggregate page-view counts on the marketing and operator pages (not on student pages). No personal identifiers sent. Google’s privacy policy.
  • 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-05-31. 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.