'/%3e%3cpath%20d='M20%2045%20L20%2027%20Q20%2018%2031%2018%20Q41%2018%2041%2027%20L41%2038%20Q41%2047%2049%2044'%20fill='none'%20stroke='%23fff'%20stroke-width='8.5'%20stroke-linecap='round'%20stroke-linejoin='round'/%3e%3c/svg%3e)
Noodlet Built so lesson code can't hurt anyone
Interactive lessons mean running code in a student's browser. Noodlet is designed from the ground up so that code stays in a sealed sandbox — the security boundary isn't a feature bolted on, it's the foundation everything else sits on.
A separate domain, on purpose
Lessons are served from a completely separate domain. Because of how browsers isolate origins, lesson code physically cannot read the cookies or sessions that belong to Noodlet itself.
No network access
The sandbox blocks lesson code from making network requests. It can't phone home, load trackers, exfiltrate anything, or pull in code you didn't see.
No access to learner identity
A lesson has no path to a learner’s seat, identity, account, or any other lesson’s data — whether the class uses anonymous Session Mode or school-managed Class Mode.
Untrusted by default
Whether a lesson was written by a teacher or generated by AI, Noodlet treats its code as untrusted and runs every one inside the same locked-down box.
A note for schools
Session Mode identifies nobody and clears learner activity within 24 hours. Class Mode holds named progress only for UK schools with a formal agreement. In either mode, lesson content never sees personal data, and one teacher's material cannot interfere with another's. If your school needs specifics for a data-protection review, get in touch and we'll walk you through it.