"No extension required" has become a selling point in online proctoring, and it means something specific: the proctoring software runs inside the exam web page, not as an add-on the candidate installs into their browser. That removes an install step and a permission prompt, but it also limits what the software can observe. This guide explains the difference and gives you ten questions to put to any vendor making the claim.
If you want the technical background on how in-browser detection actually runs, our companion piece on WebAssembly and no-install proctoring covers it. This article is for the buyer: the exam manager, IT administrator or procurement lead deciding what to deploy.
The four ways proctoring software reaches a candidate's device
Every proctoring tool has to run somewhere on the candidate's machine. There are four broad models, and each one trades access for friction.
| Model | What it is | What it can access | Install burden |
|---|---|---|---|
| Pure web app | Script loaded by the exam page | What the page is allowed to see: its own tab, camera, microphone and shared screen after permission prompts | None |
| Browser extension | Add-on installed into Chrome or another browser | Other tabs and browser activity, within the permissions the extension requests | One install per browser profile |
| Desktop app | Native program installed on the operating system | Running processes, other applications, system settings | Install plus OS permissions, often admin rights |
| Lockdown browser | A dedicated browser that replaces the normal one for the exam | The operating system's shortcuts, task switching and other applications | Install of a separate browser |
Extension-based tools are common. Kent State University, for example, tells students that a course using Proctorio needs the Proctorio Chrome browser extension, and the University of Pittsburgh's guide says students must use Google Chrome or a Chromium browser such as Brave and that the tool does not work on phones or tablets (both pages checked 6 November 2026). Proctorio's own system requirements describe its standard tier as delivered through the extension, with a desktop app added for its advanced tier. Honorlock's student page says it is "primarily browser-based" but lists the Chrome browser and the Honorlock Chrome extension among its requirements.
At the other end, Respondus describes LockDown Browser as a custom native application for Windows, Mac, iOS and Chromebook, and Safe Exam Browser is an open-source lockdown browser developed at ETH Zurich. Some vendors, such as OctoProctor, describe themselves as fully browser-based with no extension to install.
Why extensions cause friction
Extensions are not inherently bad engineering. They exist because a web page alone cannot see other tabs, and some institutions want that visibility. But they bring costs that land on IT and support teams rather than on the vendor.
Managed devices. On school- or company-managed computers, administrators control which extensions may be installed. Google's Chrome Enterprise documentation shows that admins can mark extensions as allowed, blocked or force-installed. That is good security practice, but it means every extension-based exam needs an allow-list change, coordinated before exam day, on every managed fleet your candidates use.
Browser lock-in. An extension is built for specific browsers. A candidate who normally uses Safari or Firefox has to install and use a different browser for the exam, which is a new environment at the worst possible moment.
Support load on exam day. Every install step is a step that can fail: an outdated browser, a disabled extension, a profile that syncs settings across devices, a corporate policy nobody remembered. Those failures arrive as support tickets in the minutes before an exam starts.
Permission scope. An extension that can read other tabs asks for broad permissions. That may be justified, but it has to be justified, in your data protection impact assessment and to candidates who read the permission prompt.
None of this applies to a pure web app, because there is nothing to install. The candidate opens the exam page, grants camera and microphone access through the browser's normal prompt, and starts.
What a no-extension design can see
A proctoring script running in the exam page works with the same browser features any website can use, plus whatever the candidate explicitly grants. In practice that covers more than many buyers expect:
- Camera and microphone, after the standard permission prompt. Face presence, multiple faces, gaze direction and audio levels can all be analysed in the page.
- Focus and visibility. The page knows when its tab or window loses focus and for how long.
- The candidate's screen, if the exam asks them to share it. The page can tell whether the whole screen is shared and when sharing stops.
- How answers arrive. The page sees keystrokes, pastes and clicks inside the exam itself, so it can distinguish typed text from pasted text and human input from scripted input.
- The page's own network requests, so it can see if the exam page itself contacts a service it should not.
- Device information the browser exposes, such as camera device names, some display information and, in Chromium browsers, the number of connected screens through the Window Management API.
All of this can run locally, on the candidate's device, so raw video and audio need not leave the browser at all.
What it cannot see
Being honest about the limits is the most useful thing a vendor can do. A web page cannot:
- Block or close other applications. It can notice that the exam lost focus. It cannot stop a chat app, a second browser or a note-taking tool from running.
- See other tabs or what happens in them. It knows the candidate left; it does not know where they went.
- See a second device. A phone on the desk is outside the browser entirely. The camera may catch a candidate looking down, but nothing in the browser sees the phone itself.
- Inspect the operating system. Background processes, virtual machines and system settings are outside a web page's reach. Respondus makes this argument directly, listing exploits such as virtual machines and background applications that it says extensions cannot stop either.
- Guarantee identical behaviour across browsers. Some capabilities exist only in some browsers. The Window Management API used to count screens, for example, is available in Chromium-based browsers but not in Firefox or Safari.
So the question for a buyer is not "which model sees most?" but "which model sees enough for this exam, at an acceptable cost in friction and intrusion?" A low-stakes quiz and a professional certification exam may get different answers.
Choosing by exam type
- Formative quizzes and practice tests: a pure web app, or no proctoring at all, is usually proportionate.
- Graded coursework exams at scale: a pure web app with behavioural signals and human review avoids install failures across thousands of students on varied devices.
- High-stakes certification on controlled hardware: a lockdown browser may be justified, ideally alongside identity checks and camera-based signals, since lockdown alone does not see the room.
Data protection law points the same way. GDPR's data minimisation principle asks you to collect what the purpose needs, which favours the least intrusive tool that meets the risk. A data protection impact assessment is the place to record that choice.
A 10-question checklist for vendors
Send these to any vendor that says "no extension required":
- Does the candidate install anything at all, including a browser extension, desktop helper app or separate browser, for any feature tier?
- Which browsers and versions are supported, and which features are missing on which browsers?
- Does it work on Chromebooks and on managed devices with extensions blocked?
- Does it work on tablets or phones, and if so, with which limitations?
- What does the candidate see in the browser's permission prompts, and can each permission be justified for this exam?
- Is video and audio analysed on the device, or streamed to a server? If recording is available, is it on or off by default?
- What exactly is sent to the server, and where is it stored?
- Which behaviours can the tool detect, and which can it only infer indirectly (for example, a lost focus event rather than the app that took focus)?
- What happens if the network drops mid-exam? Is anything lost?
- Can we test it on our own managed devices before signing?
A vendor that answers question 8 plainly, including what it cannot detect, is giving you something you can put in a policy and defend at an appeal.
How ProctorSafe approaches it
ProctorSafe is a pure web app. It is added to your exam page with a script tag and runs in the candidate's browser, with detection compiled to WebAssembly. Candidates install nothing; they grant camera and microphone access, and screen sharing if your exam uses it, through the browser's standard prompts. Video and audio are analysed on the device; video is not uploaded, and only integrity events are sent for review. The signals it records include face presence, gaze, tab switching, screen sharing, multiple monitors where the browser supports detecting them, virtual cameras and remote desktop tools, and how answers reached the page, with every event landing on a timeline a reviewer can check.
It does not lock down the operating system, and it does not claim to. Our remote invigilation overview describes the full signal list, the integration documentation covers setup, and the candidate demo lets you sit a short exam yourself.
It works in Chrome, Edge, Firefox and Safari, on Chromebooks, and on tablets and phones. A few detections depend on what each browser exposes: counting connected screens, for example, is only possible in Chromium-based browsers such as Chrome and Edge.
The architecture is covered in more depth in how the ProctorSafe SDK works on the device.