The question arrives about a week before the first online test, and it is always phrased the same way: what stops them from just looking it up?
It is a fair question, and most of the answers available for it are sold on fear. Proctoring vendors publish the threat — the second screen, the open tab, the whispered answer — and price the remedy at a few hundred rupees a student per sitting, with a webcam feed and a flagged-behaviour report nobody has time to watch. For a school running weekly class tests rather than a board exam, that is the wrong instrument at the wrong price.
The useful question is narrower. Without buying anything, what can a browser actually enforce while a student has a paper open — and, just as importantly, what can it never see? Both halves matter. A control you have misjudged is worse than no control, because you will stop invigilating the thing it was never watching.
The five things a browser can enforce
Everything below happens on the student's own machine, in a normal browser, with nothing installed. These are the controls worth knowing because they are the controls that exist.
| Control | What it catches | What it does not |
|---|---|---|
| Clipboard blocked | Copy, paste, cut, right-click, drag and drop, and the keyboard shortcuts for all three | Retyping by hand. Reading from anywhere. |
| Fullscreen required | Leaving fullscreen, which is what sharing a screen or resizing to see something else usually involves | A second monitor. A second machine. |
| Tab switch detected | Moving to another tab in the same browser | Anything outside the browser. |
| Focus loss detected | Switching to another application or window on the same device | A device that was never the exam device. |
| Back button neutralised | Navigating out of the paper and returning to it | Nothing — this one does what it says. |
Two of those are worth a sentence more, because their behaviour is less obvious than their name.
Fullscreen is requested, not guaranteed. The browser can refuse the request, and some browsers do not offer it at all. When that happens the paper still opens — refusing to start a test because a browser is old would punish the student for the school's device policy. So fullscreen is a control that is usually on and occasionally absent, and an invigilator who assumes it is always on has assumed wrong.
Clipboard blocking is prevention, not detection. The attempt is stopped and counted, but it is not treated as misconduct. A student who reflexively hits Ctrl+C on a code question has done nothing a teacher needs to be told about in the moment, and a test that ends itself over a reflex is a test that generates complaints instead of marks.
One warning, then the paper ends
Detection is the easy half. Deciding what to do about it is where most of the judgment lives, and the rule worth defending is: one warning, then automatic submission.
Not zero warnings, because the first tab switch of a student's life in an online exam is very often an accident — a notification, a misclick, a parent opening the laptop lid. Ending a paper on that is indefensible to the child and to the parent.
Not three, because by the third the warning has become a budget. A student who knows they have three has two free lookups.
The warning names what happened rather than announcing a generic violation, which matters more than it sounds. "You switched to a different browser tab" is something a student can stop doing. "A proctoring rule was triggered" is something a student can only be frightened by.
The same problem appears in reverse at the start. Entering fullscreen itself causes a brief focus change, so a focus watcher armed immediately would accuse every student of leaving the exam a half-second after beginning it. It has to be armed a moment late. These are not exotic edge cases — they are what the first live sitting with thirty students surfaces, which is why it is worth a dry run on a paper that does not count.
What ends up on the paper
Enforcement during the test is only half of what a coordinator needs. The other half is what is still there a week later, when somebody asks about one student's result.
Each submitted paper carries its own record: how many warnings were issued, how many clipboard attempts were made, whether it was submitted by the student or ended automatically and for what reason, when it was opened, how long it was open, and when the instructions were acknowledged. That record sits beside the marks rather than in a separate log, which is the only arrangement that gets read.
Any paper carrying integrity events then raises a single item for a teacher or administrator to look at. The important design decision there is that reviewing is a record, not a deletion. The events stay on the paper permanently; the review notes who looked at them, when, and what they concluded.
That matters for a reason that only appears after a term of use. An unresolvable alert is worse than no alert: an item that cannot be cleared sits at the top of a queue forever, and a queue with a permanent item at the top is a queue people learn to ignore. If you are evaluating any tool for this, ask what happens to a flag after a teacher decides it was nothing.
The four things none of this catches
This is the part the vendor brochures leave out, and it is the part that should shape your invigilation plan.
- A second device. A phone face-up beside the keyboard produces no signal of any kind. No tab switch, no focus loss, no clipboard event. Nothing in a browser can see a different piece of glass.
- A person in the room. An answer said out loud is invisible to every control listed above.
- Paper. A printed sheet under the desk defeats the entire category.
- The screen being photographed. Blocking copy stops the clipboard, not a camera.
And one honest caveat covering all of it: every signal above is reported by the browser the student is sitting at. That is true of all in-browser proctoring, not of this implementation in particular. It makes these counters evidence, not proof — good enough to start a conversation with a student, not good enough to be the sole basis for voiding a result. Any school policy that treats a number from a browser as conclusive will eventually accuse the wrong child.
What actually moves the number
Having said all of that plainly: the controls are still worth switching on. They remove the casual, zero-effort route — the open tab, the paste from a document already on screen — and that route is the one most commonly taken, precisely because it costs nothing. Raising the cost of cheating from nothing to something changes behaviour at the margin, and the margin is where most of it happens.
But the two things that outperform every control on this page are not software.
The first is the room. One adult walking between desks catches all four of the things listed above, and catches them better than any webcam. If a test matters, invigilate it. If it does not matter enough to invigilate, it probably does not matter enough to police.
The second is the question. A question whose answer can be pasted from a search result is a question about recall, and recall is the easiest thing in the world to look up. A question that asks a student to work something out from numbers specific to that paper, explain a choice, or write code that has to pass test cases is one where a lookup does not finish the job. This is slower to write and it is the only durable answer — the controls raise the cost of cheating, the question design removes the payoff.
A sensible position for a school running regular online tests is therefore: switch on everything the browser offers, treat what it records as evidence rather than verdict, keep an adult in the room for anything that counts, and spend the time you would have spent evaluating proctoring vendors on the question bank instead.
What the resulting records are good for is covered in the twelve questions a reports section should answer, and the wider set of problems this one sits inside is in the challenges schools face during assessments. The controls themselves are part of the assessment software for schools.