Trust & exam integrity
Security that supports fair assessment.
Security works in layers: account checks, institution permissions, server-managed exams, protected settings, and careful notification delivery. Here is what the platform actually does.
The controls behind the experience
Account protection
Passwords are salted and hashed with bcrypt. Sessions and role checks protect routes; Google sign-in and optional TOTP authenticator-based two-factor verification are supported.
Institution boundaries
Institution roles and enrollment are checked by the server before protected question, student, exam, and result records are returned.
Server-managed exams
The server controls exam deadlines, attempts, and submission. Per-exam tab-switch warning limits can trigger automatic submission when reached.
Registered student device
Android exam sessions use one active registered device, and app-only exams require its verified ID. Institution staff can manage resets, subject to a configurable cooldown that discourages rapid device swapping.
Zero-blob question storage
Question images are validated and optimized to WebP, then stored in the configured Cloudflare R2, Supabase, or Neon object storage driver. PostgreSQL stores references and encrypted location metadata, not raw image bytes.
Sensitive configuration
Storage credentials and TOTP secrets are protected at rest with AES-256-GCM using the server's APP_ENCRYPTION_KEY. Access to settings is restricted by role.
Exam integrity is a shared responsibility
Attempts preserve the questions and answers used for that sitting, so later edits to the live question bank do not silently change a completed attempt. Exam duration, permitted attempts, result publication, and tab-switch warning thresholds are governed by server-side exam rules. Visibility events are signals, not a complete proctoring system: device failures, accessibility tools, operating-system behavior, and network problems may affect what the platform can observe. Institutions should set clear exam instructions and review disputed cases.
App-only access and its limits
For an app-only exam, web participation is blocked and exam requests must present an Android client marker, bearer session, and the student's verified registered device ID. This reduces ordinary browser-based access, including access through browser DevTools and extensions. The marker and device ID are not cryptographic proof of a genuine app or hardware; the platform cannot guarantee that virtual machines, screen sharing, or multi-monitor setups are blocked. Institutions should treat app-only access as one layer of exam integrity.
Snapshots and accountable actions
Each attempt records its own question snapshots, answer selections, and scoring details, so edits to the live question bank do not rewrite that attempt. Platform administrators and authorized institution staff can review audit trails within their respective scopes. Audit records can be filtered and exported as CSV files that spreadsheet tools can open.
Notification privacy and access
Platform and institution notifications can reach Android and web subscribers through Firebase Cloud Messaging when configured. Audience topics are delivery groups, not a substitute for authorization: a notification never grants access to an exam or result. Group messages avoid individual scores. The server checks the account and institution or batch permissions again when a user opens a protected link. On sign-out, the Android app clears its topic subscriptions; browser push depends on browser permission and client synchronization. Delivery and heads-up behavior depend on device, browser, and operating-system settings.
Data and service safeguards
Protected requests use HTTPS in deployment. Passwords are stored as hashes, and selected secrets are encrypted server-side. Question image upload limits are validated by the server. Authentication, authorization, input validation, rate limits on selected routes, and audit records reduce misuse. We rely on configured cloud and Firebase providers for parts of storage, messaging, analytics, and crash reporting; those services have their own security controls and limitations. Review our Privacy Policy for the data involved.
What users and institutions should do
- Use a strong, unique password and enable two-factor verification where available.
- Keep staff roles and student enrollments current; remove access promptly when someone leaves.
- Use supported, updated browsers and Android versions, and protect registered devices.
- Do not put personal scores, answers, passwords, or sensitive information in general announcement text.
- Report suspicious access or a suspected vulnerability through an available contact channel on the homepage. Include enough detail to investigate, but do not send passwords or private student records in an initial report.
Our practical commitment
No system can promise that a test is cheat-proof or that data is risk-free. We continue to improve safeguards, investigate credible reports, and correct confirmed issues. If you believe an account is compromised, change its password and contact us as soon as possible.