System requirements

Use this page to decide whether a candidate's device can run a Proctor assessment. Requirements vary by policy: basic does not use media, standard verifies camera, microphone, speaker, and fullscreen, and strict also requires entire-screen sharing plus continuous screen and webcam recording.

Run preflight on the same device, browser profile, network, and candidate URL that will be used for the assessment. A supported browser can still fail when permissions, enterprise policy, privacy tools, hardware, or the network prevent a required capability.

Prepare the device

Before starting an assessment:

• update the browser and operating system;
• connect the device to power and disable battery-saver mode;
• close video-conferencing, streaming, recording, and other memory-intensive applications;
• disconnect external displays unless the assessment permits them;
• use a stable private Wi-Fi or Ethernet connection where possible;
• allow camera, microphone, fullscreen, and screen sharing when the assessment requests them;
• open the assessment in a normal browser tab, not an LMS, email, social-media, or other in-app browser.

Privacy extensions, VPNs, corporate proxies, DNS filters, and browser shields can block media, storage, or API requests. Test the exact production configuration before an assessment.

Supported browsers and devices

The version floor is enforced by the SDK where a version is shown. Recommended environments are the controlled-trial baseline. Conditional environments are accepted by preflight but have feature limitations or incomplete cross-browser verification.

Chrome, Edge, and Safari below their listed version floors fail as outdated. Samsung Internet and Opera currently pass browser detection without a version floor; use a current release and include it in your own controlled-trial matrix before offering it to candidates.

Hardware and operating system

ProctorKit does not gate a specific desktop operating-system release, CPU model, amount of desktop RAM, or camera resolution. The following are operational recommendations, not additional hidden pass/fail checks.

Browser storage is used for resilient event and media delivery. If IndexedDB is unavailable, event delivery can fall back to volatile memory and may not survive a refresh. See Evidence delivery for queue, retry, and recording-storage behaviour.

Network requirements

The default preflight floor is 2 Mbps upload and 2 Mbps download. A customer can raise either threshold through policy. Passing preflight is a point-in-time result and does not reserve bandwidth for the remainder of the assessment.

For reliable sessions:

• prefer Ethernet or stable private Wi-Fi over a mobile hotspot or congested public network;
• avoid simultaneous streaming, large downloads, cloud backups, and video calls;
• allow HTTPS, DNS, CORS requests, API POST requests, and direct-storage PUT requests;
• ensure the candidate origin can reach the Proctor API, content assets, face detector, VAD/ONNX assets, and configured storage origin;
• test VPNs, proxies, firewalls, ad blockers, and privacy extensions before the assessment.

strict continuously uploads screen and webcam evidence, so sustained upload stability matters more than a single speed-test result. See Browser and network support for destinations, user-activation rules, request deadlines, and trial scenarios.

Orientation and viewport

• Desktop devices pass the layout check in portrait or landscape orientation.
• Phones and tablets pass in portrait orientation.
• A phone or tablet in landscape fails when its viewport is very wide: height / width <= 0.6, approximately a width-to-height ratio of 1.67:1 or wider.
• There is no automatic orientation lock. Rotate the device to portrait and retry preflight when the layout check fails.
• Foldable devices and desktop touchscreens are not detected as separate hardware classes. A touch-enabled desktop can be classified as mobile/tablet for layout purposes.

Feature-specific browser behaviour

Secure page and permissions

Production assessment pages must use HTTPS. Camera, microphone, screen sharing, fullscreen, Web Workers, IndexedDB, and cross-origin API/storage traffic must be allowed.

When embedding an assessment in an iframe, configure the iframe allow attribute and Permissions Policy for every required capability. A top-level browser tab is the recommended candidate experience because iframe policy and user-activation propagation differ between browsers.

What preflight verifies

Preflight verifies the requirements selected by the assessment policy, including browser/device compatibility, layout, network quality, external-display signal, media permissions, microphone speech, speaker confirmation, camera/face visibility, fullscreen support, and screen-sharing capability or grant.

A pass means the required capabilities worked at that moment. It does not guarantee that hardware will remain connected, the network will remain stable, another application will not take control of a device, or the operating system will not interrupt a mobile browser. Runtime checkpoints and observers detect later changes where the browser exposes enough information.

For the precise checks, thresholds, and failure codes, see Preflight wizard. For policy-specific capability selection, see Policy reference.

Organisation rollout checklist

Before publishing an assessment:

1. Choose basic, standard, or strict and use the table above to determine eligible devices.
2. Test current Chrome and Edge on every operating system your candidates use.
3. Test the oldest browser version you intend to permit.
4. Test the exact production URL, iframe/top-level arrangement, app-key origin, storage CORS, and network controls.
5. Test denied and revoked permissions, device unplug/replug, wrong or stopped screen sharing, refresh, sleep/wake, and a network interruption.
6. Run a full-length session for every continuous-recording policy and confirm the evidence is complete after clean session end.

Use Controlled trials as the release gate before expanding beyond the recommended desktop baseline.