For schools, colleges and universities
Information for institutions
What you need to decide whether to use mithian coding with your students: how it teaches, how progress is verified, what data it holds and where, and the questions a data protection assessment will ask.
The course
A free Python course in 40 units and four parts, from a learner's first line of code to recursion, algorithms, data structures, testing and dynamic programming: 405 checked exercises and about 55 hours of lessons at a steady pace, plus 10 challenge sets on reading, tracing and debugging code. Python 3.14 runs in the student's browser, so there is nothing to install and nothing for IT to support. See the full syllabus.
Every lesson follows the same pattern: a short explanation with runnable examples, predict-the-output questions, then exercises checked automatically with explanations of what went wrong. Each unit ends with a checkpoint, and questions come back for spaced review.
Every exercise is proven by the course's build process: the model answer must pass its checks, the starting code and a set of typical wrong answers must fail, and an answer that just prints the expected result (or hard-codes it in variables) must fail too.
Teaching with classes
A teacher makes a free account, creates a class at /coding/teach and shares its eight-character join code. Before joining, a student sees exactly what will be shared with the teacher. The teacher's dashboard shows, for each student:
- verified exercises and questions, and which unit they are working on
- checkpoint scores for every unit (best score, pass at 70%)
- the exact code behind each verified exercise
- when they were last active
Everything can be downloaded as a CSV file. An optional class leaderboard shows points for verified work; students can hide themselves or use a nickname, and the teacher can switch it off.
How progress is verified
Students get instant feedback in their browser, but anything that happens only in a browser can be faked, so for signed-in students every answer is also sent to the server and checked again there:
- Code is re-run through the same checker in a separate, locked-down process (Python compiled to WebAssembly, with no file system writes, no network, no access to the rest of the server, a time limit, and a fresh interpreter for every answer).
- Other answers (multiple choice, trace tables, bug hunts, code ordering) are compared with the course's answer key on the server.
- Checkpoints are scored on the server from the student's first answers.
- Code that tries to reach into the checker is refused verification, and the code behind every verified exercise is kept for the teacher to see.
What this can't do: like any online course, it can't tell whether a student had help, copied an answer from someone else or used an AI tool. It is designed for learning and formative assessment, not for supervised exams. Work done while signed out is never counted as verified.
Data protection
| Data | Purpose | Who can see it | Kept for |
|---|---|---|---|
| Name, email, password hash (bcrypt) | Accounts, sign-in, password reset | The student; the site operator; the teacher of a class they join | Until the account is deleted, or 3 years of inactivity |
| Progress, settings, XP and badges | Carrying on across devices | The student; the site operator | As above |
| Verified answers, including code for verified exercises; checkpoint scores | Trustworthy progress; evidence for teachers | The student; their class teacher; the site operator | As above |
| Saved exercise code and playground programs | Students' own work | The student; the site operator | As above |
| Class membership, nickname, leaderboard choice | Running classes | The teacher; leaderboard names and points to classmates | Until the student leaves or the class is deleted |
| IP addresses in web server logs | Security | The site operator; the hosting provider | The hosting provider's log retention |
- No special category data is asked for. Students can use the course without an account at all.
- No third parties on these pages: no analytics, adverts, tracking pixels, external scripts or external fonts. One cookie keeps a student signed in.
- Hosting: Namecheap, Inc., on servers in Phoenix, Arizona, United States.
- Security: HTTPS only; passwords hashed with bcrypt; CSRF protection on every form; rate limits and a proof-of-work check on sign-up and password reset; changing a password signs out every other device; strict content security policy; student code runs in the student's browser with network access removed, and in an isolated sandbox on the server.
- Students' rights: each student can download all their data as JSON, correct their details and delete their account (which deletes everything at once) from their account page. The privacy notice explains this to them.
- Accessibility: see the accessibility statement (WCAG 2.2 AA, tested with axe-core).
For your DPIA
Short answers to the questions in the ICO's DPIA template, to start from:
- Nature of the processing
- Students create accounts and use an online Python course. The service stores account details, course progress, saved code and answers checked on the server. Teachers see progress for the classes students choose to join.
- Scope
- Name and email address, learning activity and code. No special category or criminal offence data. Data subjects are students and teachers, usually aged 16 or over in further and higher education.
- Context
- Students join a class with a code and see what is shared before they do. They can leave a class, and delete their account, at any time.
- Purposes
- Teaching Python; giving students feedback; giving teachers trustworthy information about progress.
- Necessity and proportionality
- Only what is needed to run accounts and classes is collected. The course works without an account. Data is deleted with the account or after three years of inactivity.
- Main risks and how they are reduced
- Unauthorised access (hashed passwords, rate limits, CSRF protection, session invalidation on password change); over-sharing with classmates (leaderboards are optional, show first name and initial or a nickname, and students can opt out); international transfer (see points to consider); faked progress (server-side verification).
Points to consider
To be upfront about what an institution may want settled before recommending the course officially:
- Hosting is in the United States. If your policy requires UK or EU hosting, or a specific transfer mechanism, get in touch: the service can be moved.
- Roles. For classes your staff run, your institution may be a controller of that class data. A data processing agreement can be put in place on request.
- Support. mithian coding is run by one person, without a service level agreement. Lessons keep working in the browser if the server is briefly unavailable, but progress won't save until it is back.
- No single sign-on (such as Microsoft or Google accounts) or VLE integration yet. Students make their own accounts.
Contact
Questions, a data processing agreement, or a call about using the course: email business@mithian.net.