Respondus LockDown Browser and AI overlays, a technical breakdown

Respondus LockDown Browser is a custom Chromium build that an institution distributes as a required download. When a student opens an exam through Blackboard, Canvas, Moodle, D2L, or a Respondus-hosted link, the regular browser hands off to the LockDown shell, which loads the quiz inside its own window with most browser chrome removed. The address bar, extensions, developer tools, right-click menus, printing, and most keyboard shortcuts are stripped or intercepted.

On macOS, the app uses standard AppKit and WebKit/Chromium APIs to ask the OS to keep its window in front and to refuse common escape paths. It checks for a list of known apps before launch, asks the user to close anything it does not like, and watches for a small set of process and window events while the exam is running. With Respondus Monitor enabled, it also records webcam, microphone, and a primary-display screen recording that is uploaded to Respondus for later review.

What it is not, and this matters, is a kernel-level enforcement module. It does not install a driver, it does not patch the WindowServer, and it does not have privileged access to other processes' memory. Apple's app sandboxing model makes that kind of system rewrite very hard to ship through normal distribution channels, and Respondus has not gone that route on the Mac.

Whisply is a menu-bar app. It does not appear in the Dock, it does not show up in Mission Control by default, and it has no main window in the AppKit sense. The interface you see when you press Cmd+Return is an NSPanel that floats above the active app, drawn by the same WindowServer process that draws every other window on your Mac.

Because Whisply is a separate process owned by your user, LockDown Browser cannot reach into it. The kiosk can hide its own chrome, raise its own window, and intercept its own key events, but it cannot reach across the macOS process boundary to close, hide, or read another app's window. That boundary is enforced by the operating system, not by Respondus.

Whisply opts every overlay window into NSWindow content protection. The flag tells the WindowServer that the window's pixels must not be included in any screen capture or screen share initiated by another process. When LockDown Browser, Respondus Monitor, Zoom screen share, QuickTime, or the system screenshot tool ask for a frame of the display, the compositor substitutes black where the Whisply window was.

Early proctoring tools, around 2012 to 2016, focused on process names. They would launch, enumerate running apps via a public API, and refuse to start if they saw something like OBS, Reflector, or a screen recorder by name. This is brittle. Any app not on the list slipped through, and any user willing to rename a binary slipped through too.

The second wave, roughly 2017 to 2021, added window-title scraping and accessibility-tree inspection. The proctor would walk the visible window list and bail if it saw a meeting app, a remote-control tool, or a known overlay. Apple's privacy work since macOS Mojave restricted a lot of that, requiring explicit user consent for screen recording and accessibility. Today most of those checks are advisory at best on a current macOS release.

The third wave, where Respondus and most of its peers live now, leans on browser-level hardening, server-side analytics, and human review of recorded video. The kiosk locks the browser, the server flags weird timing or navigation, and a reviewer skims the webcam tape. Each layer is honest about what it can see, and each layer has gaps when something sits entirely outside the recorded frame.

LockDown Browser captures everything inside its own window. Your answers, your scroll position, the time you spent on each question, your tab attempts, and a stream of high-level events go back to your LMS. With Respondus Monitor, it adds a webcam recording of your face, a microphone recording of the room, and a screen recording of your primary display.

The screen recording is the part most people misunderstand. It is produced by the same macOS screen-capture pipeline that every other app uses. That pipeline respects window content protection. A window marked as protected appears as a black rectangle in the recording, not as a hidden secret, and the rectangle is the same shape and position as the window itself.

Outside the recorded display, LockDown Browser has no eyes. A second Mac, a phone next to the keyboard, a printed page, a person in the room, all of these are invisible to it. That is not a Whisply claim, it is just how a browser-shell proctor works. Whisply happens to use that same blind spot in a privacy-respecting way, on the same machine, through content-protected windows.

Respondus ships updates. Apple ships updates. macOS 26 changed parts of the screen-capture pipeline. macOS 27 will change more. A flag that is honored today could be revisited tomorrow, and a new build of LockDown Browser could ask the OS for capabilities it does not currently use. We test against the current release of LockDown Browser on every supported macOS version, and we ship fixes when something shifts, but no overlay can promise that a kiosk built by a different company will behave the same way forever.

There are also user-side mistakes that no software can prevent. A second monitor that the proctor asked you to disconnect. A webcam pointed at a reflective surface. A microphone picking up a clearly synthesized voice. Whisply staying out of the screen recording does not help if the room itself gives the game away. The honest answer is that the technology handles a specific, well-defined slice of the problem, and the rest is up to the person sitting at the desk.

If your institution requires a second-camera setup, a phone scan of the room, a locked-down virtual machine, or any form of remote-desktop inspection, the rules of the room change. Whisply is designed for a single Mac running a kiosk browser, with the camera and microphone facing you in the normal way. Anything beyond that is outside what we test.