EduAlly Secure Browser is a purpose-built desktop exam environment in development—designed around isolated assessment content, policy-bound sessions, privacy-minimized signals, and human-centered review.
Protection in layers
The desktop client is only one layer. EduAlly's secure-exam architecture also narrows access to exam content, fixes the rules for each attempt, validates requirements before start, and keeps the server in charge of session state. These are v1 release requirements and design targets—not a claim that an uncertified desktop build already provides every control.
Secure questions are designed to open in a dedicated web surface—not in the ordinary EduAlly app or a general-purpose browser window.
Allowlisted routes, restrictive browser policy, and ephemeral storage keep the exam surface narrow.
The desktop session is designed to check the requirements selected for that assessment before protected content is made available.
Missing permissions, extra displays, remote sessions, virtual environments, or prohibited apps can stop the start.
The control plane binds each attempt to a versioned policy snapshot, so its rules and approved accommodations do not silently change mid-exam.
Security is opt-in per assessment; existing tests remain off unless an instructor explicitly configures them.
The control plane uses short-lived, one-use launch handoffs to connect the right student, assessment, and secure session without putting those details in the link.
Ordinary browser sessions cannot use the secure exam surface to retrieve protected questions.
The secure-exam service—not the device clock—controls begin, pause, resume, completion, and session timing.
Replay protection and idempotent requests help keep reconnects and retries from corrupting an attempt.
The desktop client is designed to cover or pause the assessment when a required safeguard, permission, or connection is lost.
Recovery work is designed around encrypted local data and restoring device restrictions safely after exit or failure.
Privacy is a security control
The v1 design is built around purpose limitation: an assessment should enable only the tracks and technical checks it actually needs, disclose them in advance, and collect no broader device story.
Read EduAlly's data safety guideProctoring evidence is designed to be encrypted before any durable write or transfer.
The client receives no bucket-wide listing, overwrite, delete, or cross-session access.
Ordered segments, checksums, hash chains, and signed manifests surface gaps or alteration.
The effective retention rule and any hold conditions are shown before the student begins.
Honest assurance
A secure browser can meaningfully narrow an exam environment. Its assurance still depends on who controls the device, which operating-system protections are available, and what the institution has tested.
Student-owned device
Best-effort containment, policy enforcement, detection, and evidence on a device the student controls. It cannot promise to defeat administrator or root access, a modified operating system, privileged tools, external capture hardware, or help from a second device.
Institution-controlled device
Stronger prevention is possible only on named operating-system versions, managed configurations, and tested hardware. A managed claim applies to that certified setup—not to every device that happens to run the app.
Proctoring signals are technical observations for an authorized human reviewer. They are not automatic findings of cheating and do not apply a grade penalty on their own. Students should be able to see the nature and timing of a relied-upon event and use an accessible appeal path.
Approved screen readers, dictation tools, alternate input, extra displays, breaks, and other controls can be scoped to one student and test without storing a diagnosis.
The design calls for a pre-exam accommodation path and an equivalent assessment option when required capture or lockdown technology is inaccessible or unavailable.
Choosing not to continue at the disclosure should not start the timer or silently create a failed submission.
Persistent text—not color, sound, or temporary notifications alone—should explain recording, upload, offline, pause, and permission states.
Desktop releases
There are no public builds yet. When a platform is ready, its card will show the supported systems, version, release notes, and a direct download—without making students hunt through a release repository.
First pilot target
BYOD pilot first · managed certification separate
The first planned desktop pilot, pending client signing, compatibility checks, privacy and accessibility review, and adversarial security testing.
Certification pending
BYOD planned next · managed AAC certification separate
Planned after the Windows baseline, with a named OS and hardware matrix plus platform-specific permission and recovery testing.
Broad beta planned
BYOD beta target · managed not planned for v1
Planned for named distributions and desktop sessions only after capture, application monitoring, and recovery behavior are verified.
A secure attempt begins from an assigned assessment in EduAlly and uses a short-lived launch handoff. Students should install only the build provided here or by their institution. Installer availability will not, by itself, mean that a managed-device configuration is certified.
Questions, answered
The browser is still being built, but its boundaries should be understandable now—not hidden behind a download button later.
Not yet. The desktop releases are still in development. The platform cards on this page will become real download actions only after each build completes signing, compatibility, privacy, accessibility, and security review.
No. On a student-owned device, the browser can provide best-effort containment, enforcement, and technical signals, but it cannot defeat an administrator or root user, a modified operating system, a second device, or an external camera. EduAlly will not describe the product as unbreakable or cheat-proof.
Only the tracks enabled by that assessment's policy. Before launch, the student should see the exact requirements, purpose, viewers, retention rule, and alternatives. Recording is designed to begin only after preflight, acknowledgement, and an explicit Begin test action—and to stop at a terminal exam state.
No. A flag is a time-stamped technical observation, not a finding of intent. The security model keeps human reviewers accountable for interpreting events in context and preserves a student-facing review and appeal path.
The session is designed to protect the questions and the student's work by covering or pausing the assessment when a required control is lost. The server remains the source of truth for timing and resume decisions; a failure should never silently become an automatic misconduct decision.
Assistive technology should not be treated as suspicious simply because it interacts with input, speech, or display APIs. The architecture supports per-student, per-test accommodations and calls for an accessible alternative when a required capture or lockdown control is not appropriate.
Built in the open
Release status, platform limits, collection, and review should all be clear before a student begins.
