Skip to main content
Start free
All help topics

For admins

Exactly what the University plugin does not do

Every claim on the other pages is verified against the running product. This page is the other half: the things a procurement checklist asks for that we do not do, said plainly, with what we do instead and who does the missing part better. A technical review will find these in an afternoon — it is cheaper for both of us if you find them here first.

Last updated Aug 28, 2026

The nine things proctoring vendors list

Procurement checklists tend to arrive as the same nine bullets. Here is each one against what the software actually does. Seven are built. Two cannot be done from a web page at all — not by us and not by anyone — and a vendor claiming them in a browser is either shipping a native application or overstating.

  • Automated proctoring (AI-led) — YES, and it needs no account with anybody. Face presence and second-person detection run on the CANDIDATE’S OWN DEVICE: a 224 KB model on a WebAssembly runtime, served from our origin, analyzing the webcam frame in the page. No key, no per-image fee, and no frame leaves the machine to be looked at by a third party. It answers “how many faces are in this frame” and nothing more — no identity is computed and nothing is scored. Institutions that already pay for a cloud vision service can point us at it instead, but nobody has to. Where the model cannot load, we record that we could not look rather than reporting an empty frame.
  • Live proctoring (human-led) — YES. Candidates publish their camera to an invigilation board and staff watch the paper as it happens, alongside the polled evidence trail. Video only: a room carrying a candidate’s household audio into a staff member’s headphones is a very different proposition from a still every thirty seconds, and it is not what supervision needs. A candidate whose connection cannot hold the stream still sits the paper — supervision is an aid, not a gate.
  • Record and review (passive) — YES. Stills, a timestamped event trail, and a reviewable verdict per sitting.
  • Lockdown browser restrictions — YES within a browser’s reach, and the agent extends it. Full-screen, paste, copy, cut, right-click, print and developer tools are all blocked or recorded. With the agent required, a paper can also refuse to proceed while prohibited software is running. It is still not a kiosk: a second device in the room defeats all of it, and nothing installed on the exam machine can stop that.
  • Identity and biometric verification — YES, AND IT NEVER REJECTS ANYBODY. A photo and photo ID are captured before the paper is released, and automated matching is available against Azure Face or your own scoring endpoint. What it produces is a score that FLAGS a sitting for a person to look at; it cannot fail a candidate on its own, and the threshold is deliberately generous. That limit is a decision, not an omission: automated face matching has error rates that are worse on darker skin and on women, and a false rejection at an examination is not a small harm. Left unconfigured, matching stays entirely human.
  • Audio and video monitoring — YES. Webcam stills, microphone loudness sampling, and periodic screen-share stills. The microphone records a NUMBER, never speech: keeping hours of a candidate’s room audio costs more in privacy than it buys in evidence.
  • Room scan audits (360°) — YES. A guided sweep before the paper is released, captured as stills a reviewer can see at a glance. It establishes what the room looked like at the start, which is the question an appeal asks. It does not stop somebody reaching for something afterwards.
  • Application interception (background apps, virtual machines, remote desktop) — YES, WITH THE EXAMINATION AGENT. This is the one item on the list that a web page genuinely cannot do, so we ship software that can: a small agent the candidate runs during the paper. It reports which prohibited applications are running, whether the machine is a virtual machine, whether the desktop is being driven over remote desktop, and how many displays the operating system sees. It signs each report against a one-time challenge from the server, so a candidate cannot capture one clean report and replay it. Without the agent, the browser records only weak signals — a software GPU, very few cores — which are shown to a reviewer and never acted on.
  • Dual-monitor detection — YES. The browser reports whether more than one display is attached, including a monitor plugged in after the paper starts. It does not say what is on the second screen.

The examination agent

Process interception, virtual-machine detection and remote-desktop detection are not things a web page can do — not ours and not anybody’s. They need code running outside the browser with the operating system’s cooperation. So the agent is a small program the candidate runs for the duration of the paper, and it is the honest answer to that half of the checklist: not “we cannot”, but “not without software the candidate installs”.

  • It binds to the candidate’s own machine and nothing else. It never talks to the network itself — the exam page carries its signed report — so it cannot send anything anywhere even if a build were tampered with, and only the pages your institution lists may ask it anything.
  • It reports the NAMES that matched a published deny-list, and a count of everything else. It does not upload a process listing. A candidate’s machine holds their banking app and their medical appointments, and collecting all of it to catch a screen recorder is not a trade worth making.
  • It does not kill anything. Terminating a candidate’s software mid-paper is how somebody’s unsaved work is destroyed.
  • It is re-checked every few minutes, not once. One check at the start proves only that nothing was running at the start; the interesting moment is forty minutes in.
What the agent is worth, stated plainly: it signs its reports with a key that ships inside the agent build, so somebody willing to reverse-engineer the binary can forge a clean one. That is true of every vendor doing this, and none of them should call it unbreakable. What it buys is a large rise in effort — a candidate must now defeat a signed binary rather than press F12 — which is a real difference in practice and not a guarantee. If your regulations demand certainty rather than evidence, the answer is a physical examination center.
Every one of these signals is asserted by the candidate’s own browser, which is why none of them decides anything. A candidate who can run the page can withhold an event, so the absence of a flag proves nothing and the presence of one is evidence for a person to weigh — never a verdict.

There is no hardware-level anti-cheat

Proctoring here runs in the browser, and a browser has no hardware level. We cannot see what is running on the machine, we cannot enumerate connected devices, and we cannot tell whether a second screen is a monitor or a television showing a football match.

If your regulations require a locked-down machine, you need a dedicated lockdown browser or a physical examination center, and you should budget for one. What we provide is the browser-observable layer: focus changes, paste, camera snapshots, connection gaps, and a per-candidate watermark.

We cannot detect external devices

Some products claim to detect unauthorised USB or Bluetooth devices from a web page. The browser APIs that touch hardware — WebUSB, WebHID — require an explicit permission grant from the user for a specific device. A candidate intending to cheat simply will not grant it, so the check would only ever succeed against people who were not cheating.

The watermark is attribution, not prevention

A moving watermark carrying the candidate's registration number makes a leaked screenshot or recording traceable, and makes the candidate aware of that. It does not stop a determined person pointing a phone at the screen, and because it is rendered in the page, somebody comfortable with developer tools can remove it from their own view.

It works against the realistic threat — a paper photographed and shared in a group chat — and not against a developer. Anyone selling you a watermark as something that "renders screen recorders useless" is overselling, and your own IT team will say so.

Face matching does not reject anybody

Identity capture stores the candidate's photo and photo ID side by side for a person to compare, which is what the UGC definition of a proctored examination actually asks for. Automated matching is available as an option — you can connect Azure Face or your own endpoint — but a score never rejects a candidate; it only raises review priority.

That is a deliberate limit, not a missing feature. Automated face matching has badly distributed error: worse on darker skin, worse on women, worse in poor light — which is to say worse for a candidate sitting an evening examination under a single ceiling bulb. A system that auto-rejected on that score would be wrong about real students, unevenly.

SAML is not implemented — OIDC is

Institutional sign-in supports OpenID Connect, which covers Microsoft Entra ID, Google Workspace and Okta. SAML returns a clear "not implemented" rather than a half-built implementation.

That is on purpose. XML signature verification has a long history of wrapping attacks, and getting it subtly wrong means anyone can mint an assertion for any account. If your directory is SAML-only — some Shibboleth federations are — tell us, because that is a real gap for you and not something to work around.

There is no studio-grade video DRM

We do not use Widevine, FairPlay or PlayReady, and we will not pretend otherwise. What exists is signed expiring delivery, per-student watermarking, copy and print controls, PDFs rendered so there is no text to select, and a device cap that stops password sharing. If your content genuinely requires studio DRM, you need a specialist video platform.

The plugin store with 'SGPA' typed into the search box, showing the University plugin as the only result.
Searching the store by the word you would actually use. 'SGPA' appears in none of the plugin's name, tagline or description — the keywords are what make it findable.

It is not a full ERP

No fee ledger, no hostel or transport, no payroll, no admission-test engine. The plugin covers the academic spine — programme, candidate, examination, result, record — and expects to sit alongside whatever you run for the rest.

If any of these is a blocker, say so early. We would rather lose an evaluation in week one than fail an audit in month six, and for several of these the honest answer is that a different tool is the right one.
Can you stop a candidate taking a screenshot?
No, and neither can anyone else on the open web. The watermark makes a screenshot traceable to the candidate rather than preventing it.
Do you support SAML?
No. OpenID Connect only — Entra ID, Google Workspace, Okta. SAML returns a clear not-implemented response rather than a partial implementation we could not stand behind.
Can the system automatically fail a candidate for cheating?
No, by design. Flags set review priority, a person reviews the evidence, and the academic board decides. Every signal has an innocent explanation more common than the guilty one.
Is our data locked in?
No. Records export, marksheets are PDFs you hold, and verification links keep working whatever happens to your license.

Related