Privacy & Data Handling Policies

Purpose and Scope

This page explains what information Classroom Token Hub (CTH) collects, how it is used and protected, who can access it, and how to request corrections or deletion.

CTH helps teachers run classroom activities and a simulated economy. District reviewers should also read For District Partners. Students and families can ask their teacher or school about classroom use, access to records, corrections, or removal.

How We Use and Share Information

CTH is developed and maintained by a classroom teacher. We use information to establish accounts, run classroom activities, display records, secure access, and investigate problems. As a self-funded project, we do not display advertisements or share user data. We also do not utilize analytics services that track users across the web.

Internally, CTH was built to operate with as little personal information as possible. When personal information is shared, they are only viewable by the classroom teacher who provisioned the class. The operator of this platform can only see randomly generated strings of characters that represent each student and class. All internal business is conducted with these pseudonymous identifiers.

While CTH collects minimal amount of personal information for the operation of the platform, we cannot make claims about our hosting, security, and content-delivery providers with regards to their data policies. For details about their policies, please visit their respective websites.

Information Teachers and Students Provide

Teachers

• A username and authenticator setup, plus passkey registration information if a passkey is added.
• A two-part display name, class name, optional section label, and class time zone.
• Roster entries, class settings, store items, announcements, and other classroom content.

Students

• Teachers supply the first and last name fields used for roster display and account claiming. These may be full names, partial names, or agreed classroom nicknames. A roster built entirely from nicknames leaves no real-name identifier in the platform; records link to a classroom seat rather than to a legal name.
• The roster also supports optional encrypted teacher notes. These notes should hold no unnecessary personal or sensitive information.
• Claiming an account takes the class join code, the matching names, and — where another student in the class shares that name — a distinguishing code the system generates and the teacher passes on. The student then creates a username, a 4–6 digit PIN, and a passphrase.

Account registration does not ask for email addresses, phone numbers, home addresses, dates of birth, parent contact details, government IDs, or district student ID numbers. Support reports and other free-text fields store text as written. They are not intended for contact information, medical details, disciplinary case records, or other unnecessary personal information.

Display Names, Notes, and Classroom Content

Names help students claim the correct roster entry and help teachers recognize students. Encrypted display names are decrypted only where the application needs them: the provisioning teacher’s roster and the student’s own interface. Teachers’ display names and class labels can be visible to students in that class.

Roster notes are encrypted, teacher-entered context about a student’s participation in one class. They are free text; CTH does not inspect or classify their contents. Notes are not automatically included in support snapshots. Other free-text fields, such as support explanations and transaction descriptions, do not all receive this field encryption.

Teachers can export class roster or student information. Downloaded files are held outside CTH and need to be handled under the school’s own access and retention practices.

Classroom Activity and Support Records

• Attendance and hall passes: event timestamps, work or break periods, pass destinations, approval and use records.
• Simulated finances: checking and savings activity, payroll, bonuses and fines, transfers, rent, obligations, insurance purchases and claims, and store purchases or item use.
• Class settings and summaries: prices, rates, economic policy, enabled features, and class-level economic summaries.
• Support: submitted explanations, expected outcomes, review notes, related activity snapshots, and technical diagnostics.

Activity is linked to a class and student participation record. These are pseudonymous student-related records when they use an opaque reference instead of a name; an amount or timestamp does not itself directly identify a student. CTH currency is simulated; there are no real bank or payment-card connections.

Retention and Deletion

Delete a student: permanently removes that class participation record and its related application data. Other class memberships remain. Deleting the last student in a class also deletes the class; if it was the teacher’s last class, the teacher account is deleted too. The deletion dialog warns about these consequences.

Unclaim a student: disconnects the sign-in account while preserving the class participation record, balance, activity, and items for the next claimant. The teacher re-enters the names to use for claiming. Use this when the wrong account claimed a roster entry or a student needs to consolidate accounts. A detached student account is deleted if it has no other class memberships.

Delete a class or teacher account: deleting a class removes its related application records; deleting a teacher account deletes all of its classes. These actions have no archive or undelete option.

Inactive teacher accounts: accounts are automatically deleted after 180 days without a successful sign-in, or after 30 days from creation if they have never signed in. Their classes are deleted through the same account-deletion process. Class activity does not reset this sign-in clock.

Downloaded exports remain under the school’s control and are not removed by application deletion. Contact support about retention of infrastructure backups or logs.

Encryption, Credentials, and Sessions

• Protected database fields: display names, roster notes, and authenticator secrets use Fernet encryption. The application decrypts them when needed. This does not encrypt every activity record, support report, or diagnostic field.
• Lookup fields: usernames and temporary roster-name matching values use keyed HMAC-SHA256 digests. Successful claiming clears the temporary name hashes and distinguishing code; encrypted display names remain for classroom use.
• PINs and passphrases: stored as salted scrypt hashes for credential verification.
• Passkeys: the application stores the registered public key and credential metadata. Passkey authentication does not send the private key to CTH.
• Session cookies: the application uses signed, HTTP-only, SameSite=Lax cookies and enables the Secure flag in production. Signed cookies protect against alteration; they are not encrypted. Pending teacher signup data, including its authenticator secret, is held encrypted on the server, with a random reference in the browser. Signup attempts expire after 30 minutes, are removed on completion or restart, and are cleared by scheduled cleanup after expiry.
• Session expiry: students have a ten-minute limit from login; teachers have a ten-minute inactivity timeout. Sign out when finished, especially on a shared device.

HTTPS/TLS protects connections when configured on the deployed service. Infrastructure access, backups, and key custody require their own controls. Someone with both stored encrypted data and the application’s encryption key can decrypt it.

Sign-In and Account Recovery

Student sign-in and recovery

Students sign in with their username and passphrase. A PIN is used for attendance, checking/savings transfers, and hall passes. Purchases, rent, insurance payments and cancellation, and other entitlement use require the passphrase.

When a student loses access, their teacher generates an eight-character recovery code that expires after ten minutes. The student recovery form asks for that code; it does not ask for a name or join code. A valid code is cleared when accepted, and the student is directed to create a new username, PIN, and passphrase. Setup must finish in that same browser session before the original ten-minute deadline. An accepted code cannot be reused in another session; if the session is lost or outlasted, the teacher issues a new code. Where the account is used in several classes, the changed credentials apply to that shared account.

Teacher sign-in and recovery

Teachers sign in with a username and a time-based one-time password (TOTP) from an authenticator, or an enrolled passkey. Student-assisted recovery requires every class on the account to have at least three students with claimed accounts; with fewer, the random selection below would be predictable, so recovery cannot start. To begin recovery, the teacher provides class join codes and student usernames for every class on the account: six students for one class, three per class for two, two per class for three, and one per class for four or more, or every claimed student in a smaller class. Each student may be entered only once. These entries are checked once to start the attempt and are not stored. These entries do not choose the students who will help: CTH randomly selects two eligible students in each class, independently of their seats in the teacher’s other classes, and notifies them without revealing their identities to the teacher. Each class is asked to check their accounts and hand over a code in person, only while the teacher is with that class.

One valid code per class is required. Each code expires 30 minutes after issuance; the same selected students can generate fresh codes throughout the five-day recovery attempt. Selection does not change when codes expire. Save codes while they are fresh; accepted class confirmations remain valid for the attempt. Individual entries show only a receipt, and submitting the complete set gives an overall success or failure. A failed complete submission requires fresh codes for every class from the same students. Recovery cannot finish without a valid confirmation from every class and does not use email reset links.

Who Can Access Information

Classroom accounts

Teachers access their owned classes, and students access classes they have joined. A signed-in student can add another class after matching its roster, using the same account credentials. Classroom balances, attendance, and purchases remain separate.

Platform support

Support staff can review submitted teacher reports and escalated student issues. Reports include technical diagnostics such as the page URL, route and request correlation information, IP address, and browser details. Teachers choose separately whether to include balances, the reported transaction, recent transactions, student report text, and the class label. These options are not selected by default. The submitted snapshot is fixed: support does not refresh it from live classroom records. Every ticket belongs to a class participation record, including a teacher’s own ticket, and deletion of that record removes the associated ticket. Free-text submissions contain what the author types; omit unnecessary personal details.

Hall-pass verification

A person who has a teacher’s shared verification link can select a class and enter a student’s first and last name without signing in. The staff member selects the class and supplies the name, so the check confirms or denies what they already hold rather than disclosing a student. A confirmed match adds the pass itself: destination, status, and the current day’s departure or return time. The link does not provide a student roster or multi-day history. Teachers should share it only with intended school staff.

Technical Data, Cookies, and Service Providers

The application records operational events and request traces to investigate errors and support reports. These can contain timestamps, request identifiers, endpoints, outcomes, and pseudonymous participant references. Support captures technical diagnostics at submission; classroom balances, transaction details, student report text, and class labels are included only with the teacher’s separate permissions described above.

The application uses session and security cookies. Its public pages also request external resources:

• GitHub Pages: serves the public information site.
• Google Fonts: supplies the public site’s fonts and icon font.
• jsDelivr: supplies public-page styling and application assets.
• Cloudflare Turnstile: provides bot checks on selected application forms when configured. Server verification sends a challenge token and can include the visitor’s IP address.

External requests disclose network and browser information to the receiving provider. Hosting and monitoring services can also process request and diagnostic data depending on deployment.

Contact support with questions about service providers and retention of technical data.

School Use

CTH does not display advertisements, sell user data, provide district SSO, or connect to real banks. It does provide classroom summaries, support diagnostics, and operational monitoring.

Schools and districts should review student-data use and any required notices, consent, agreements, and retention arrangements before adoption. CTH does not provide a parent-consent collection workflow. See information for schools and districts.

Questions, Access, Corrections, and Deletion

Students and families should contact their teacher or school about classroom records, corrections, or removal. Teachers and district reviewers can contact support@classroomtokenhub.com. Security concerns can be sent to security@classroomtokenhub.com.

Email correspondence is separate from application registration and includes the sender address and message content. Do not send PINs, passphrases, recovery codes, or unnecessary student information. We will update this policy when our data practices change.