What Browser-Based Proctoring Can and Cannot Detect

What can a browser tab actually see?

Everything a browser tab observes reaches you as an event, live, through one callback. There is no hidden channel: what the SDK can report is exactly what a web page is permitted to know about its own camera, microphone, focus, and window. The event names below are the whole surface, so if a concern is not on this list, a plain tab cannot see it.

import { ProctorLink } from '@proctorlink/sdk';

// jwt and sessionId come from your backend's POST /v1/sessions response.
const session = ProctorLink.createSession({ jwt: sessionJwt, sessionId });

// Every signal a browser tab can legitimately observe arrives here, live.
session.onEvent((event) => {
  switch (event.type) {
    case 'tab.hidden':        // candidate switched away from the exam tab
    case 'clipboard.paste':   // content pasted into the exam
    case 'clipboard.copy':    // exam content copied out
    case 'fullscreen.exited': // left fullscreen
    case 'device.changed':    // a camera or microphone was swapped
      review(event);
  }
});

await session.start();

The signals that arrive here are tab focus (tab.hidden, tab.visible), fullscreen state (fullscreen.entered, fullscreen.exited), clipboard actions (clipboard.copy, clipboard.cut, clipboard.paste), window changes (window.resized), the right-click menu (context.menu), device swaps (device.changed), and the page unloading (page.unload). None of these describe the room. They describe the tab. If you are new to the field, start with What is online proctoring? for the concepts before the mechanics.

Can it detect phones, a second monitor, or a VM?

This is the question buyers ask most, so here it is signal by signal. The short version: anything that lives inside the tab or in front of the camera is detectable, and anything that lives in the room, in another application, or below the browser is not, at least not from a browser tab alone.

A phone on the desk is the clearest example. A web page has no access to the room, so it cannot see the phone directly. It can only surface it indirectly: the candidate glancing down may show in a keyframe a reviewer then reads, and switching to a phone-mirroring app fires tab.hidden. A second monitor is detectable only in Chrome and only with the candidate’s permission, and a virtual machine or remote-desktop session is invisible to any tab because it lives below the browser.

Which signals actually change the score?

Detecting a signal and penalising it are different things, and conflating them is how proctoring earns a reputation for false accusations. Browser events are recorded as context for a reviewer; face analysis is what drives the verdict. Only a pooled set of browser events deducts points at all, capped at a combined twenty: tab.hidden, fullscreen.exited, the clipboard actions, and camera.denied.

Everything else, including tab.visible, fullscreen.entered, window.resized, context.menu, device.changed, and page.unload, is captured and returned but does not change the score, because each fires often for innocent reasons: a rotated phone, a Bluetooth headset connecting, a normal exam submission. That restraint is deliberate. Ordinary behaviour should not manufacture an accusation, so a single tab switch does not flag a candidate. The heaviest penalties sit with the face findings, identity mismatch and multiple faces, which is why the camera, not the clipboard, is the real detector.

What about mobile browsers?

The platform imposes one more limit worth stating plainly. iOS Safari has no screen-capture API, and it suspends the camera when the tab is backgrounded, so a candidate who switches apps on an iPhone stops sending frames rather than being recorded doing so. A client that goes silent is itself a signal, though: a session that stops reporting scores worse than one reporting violations, because the continuous heartbeat monitoring notices the gap. Plan mobile exams around that behaviour rather than assuming a phone browser observes as much as a desktop one.