Browser & network

Proctoring depends on secure browser media APIs, IndexedDB, Web Workers, MediaRecorder, Web Audio, and cross-origin delivery. Run preflight on the same device, browser profile, network, and candidate origin that will run the assessment. Start with System requirements for the candidate-facing browser, device, memory, orientation, and hardware matrix.

Supported browser matrix

The minimums are code-enforced defaults, not a guarantee for every device or enterprise policy. Start controlled trials with current desktop Chrome/Edge and expand only after completing the same soak suite. The complete policy-by-policy matrix lives in System requirements.

Device and layout gates

The system check can reject iOS, low-memory Android, mobile/tablet layout, an external monitor, or an unsuitable viewport. thresholds.allowMobile controls the layout gate and defaults to true in the current assessment presets; that does not make iOS or low-memory devices supported. When proctoring.screenShare.enabled is true, the initial device check also requires getDisplayMedia. Browsers without that capability fail immediately with screen-share-not-supported; this effectively blocks current Android and iOS browsers while still allowing tablet hardware running a capable desktop browser.

navigator.deviceMemory is approximate and not available in every browser. Android devices that reliably report a memory bucket at or below 4 GB fail the device check. If a browser suppresses the signal, preflight treats the memory as unknown and does not fail the device on memory alone. Brave Shields deliberately changes the reported bucket, so preflight also treats memory reported by Brave as unknown instead of rejecting the candidate on that value. Treat a reported result as a conservative preflight gate, not a hardware inventory.

Secure-context and permission requirements

Production candidate pages and the API must use HTTPS. Browser media APIs require a secure context (localhost is the development exception). Your page must be allowed to request:

• camera and microphone through getUserMedia;
• screen sharing through getDisplayMedia when policy requires it;
• fullscreen where enabled;
• speaker playback/autoplay after a user gesture;
• IndexedDB and Web Workers;
• cross-origin API and storage requests.

If the assessment is embedded, configure the iframe allow/Permissions Policy for the required capabilities and test browser-specific prompt behaviour. A top-level page is the safer trial baseline.

User activation

Screen sharing, fullscreen, media playback, and some Safari camera flows require a live user gesture. Promises, timers, and network calls can consume transient activation.

The Vue wrapper preserves activation through its final preflight action. With the raw SDK, construct ProctoringClient directly inside the candidate click or acquire the screen stream in that click and pass it to the SDK. Every share-again action must also be a new click. See Raw SDK integration.

Network paths to allow

Candidate networks must reach:

Allow DNS, TLS, CORS preflight/response headers, POST, and direct storage PUT traffic. Enterprise proxies that inspect or buffer large uploads can break MediaRecorder delivery even when ordinary API requests work.

Slow and interrupted networks

Preflight measures the application upload path and latency/jitter. The default minimum bandwidth floor is 2 Mbps. Passing that snapshot does not reserve bandwidth for the session.

Runtime event and media retries are bounded. While offline, the network observer emits network.offline and events continue queueing locally; upload resumes after connectivity returns. Continuous media may exhaust its byte buffer on a long outage. An online browser status also does not prove DNS, API, or storage reachability.

The Vue wrapper applies internal request deadlines: attempt resolution 12 seconds, control requests 5 seconds, photo upload 15 seconds, and telemetry 5 seconds. These are fail-safe implementation bounds, not client policy fields.

Published content loading has its own bounded 2.5-second default. A timeout, blocked request, invalid manifest, or server failure uses the package's validated bundled copy; it does not block assessment startup. Refreshing revalidates the production manifest through its ETag, so restrictive caches or proxies must allow conditional GET requests and 304 responses.

Trial test matrix

Test at least:

• current Chrome and Edge on Windows and macOS;
• the oldest browser version you plan to allow;
• 2 Mbps uplink, high latency/jitter, packet loss, and a mid-test offline interval;
• corporate VPN/proxy, restrictive DNS, ad blocker, and privacy extension;
• denied/revoked camera and microphone, camera in use, device unplug/replug;
• cancelled/wrong-surface/stopped screen sharing;
• refresh, tab close, laptop sleep/wake, and network handover;
• direct-storage CORS from the exact production candidate origin;
• long sessions at each recording policy and a clean-end drain.

Record the browser/OS/build, policy, network profile, evidence completeness, terminal status, and recovery result for every run.