Proctoring
Respondus LockDown Browser and AI overlays, a technical breakdown
A plain-English look at how the locked browser works on macOS, what its process-blocklist and screen-watcher can see, and what runs at a layer it was never built to inspect.
Respondus LockDown Browser is a Chromium-based kiosk shell that watches running processes and locks the browser to the front; Whisply runs at the macOS window-server layer above it and is private to you on Pro Undetected.
- Respondus is a kiosk browser plus a process-name blocklist; it does not run a kernel extension on modern macOS, so it cannot enumerate every window the WindowServer knows about.
- Whisply is a native AppKit menu-bar app with NSWindowSharingNone set on every overlay, which keeps it out of CGDisplayStream captures the proctor or the browser itself can perform.
- On Pro Undetected, the armed mode also renames the binary, hides the Dock and menu-bar entries, and changes the bundle identifier so the standard Respondus process check returns clean.
Respondus LockDown Browser ships a hard-coded list of process names it refuses to run alongside (Zoom, OBS, Camtasia, common screen-capture tools). The list is compiled into the app and updated with each release, which is why arming Whisply's bundle identifier is the relevant signal, not the human-readable app name.
How Respondus LockDown Browser detects external apps
Respondus LockDown Browser on macOS is a Chromium-based kiosk shell with a thin AppKit wrapper. The wrapper enumerates running processes through NSWorkspace and proc_listpids and matches executable paths and bundle identifiers against a compiled-in blocklist (the list includes Zoom, OBS, common screen recorders, and a handful of named AI assistants). It also runs a foreground-locking loop that re-raises the browser window if focus shifts, disables common screenshot shortcuts through AppKit hotkey interception, and on the institution side reports any blocklist match back to the LMS. It does not install a system extension, does not have Endpoint Security entitlements, and has no privileged view of the WindowServer beyond what any userspace app gets.
How Whisply’s overlay isolation works
Whisply is a native macOS menu-bar app, not a browser extension or a kernel module. Every panel the user sees (chat overlay, response card, transcript window, settings sheet) is an NSWindow with sharingType set to NSWindowSharingNone. That flag tells the WindowServer to exclude the window from any composited frame requested through ScreenCaptureKit or CGDisplayStream, regardless of which app is asking. The locked browser is just another userspace app asking the WindowServer for pixels; it gets back a frame with Whisply absent. On Pro Undetected, the armed mode also renames the binary, randomizes the bundle identifier, and removes Dock and menu-bar text so the Respondus process enumeration matches nothing known.
A short history of how Respondus got here
Respondus LockDown Browser started in 2002 as a Windows-only IE wrapper for institutions running Blackboard. It became the default "locked browser" for community colleges and large state universities through the 2010s, and was rebuilt on Chromium around 2018 to handle modern web standards. The macOS build followed the Windows architecture closely: a kiosk-mode Chromium shell with a thin native wrapper that watches the OS for anything the institution flagged.
The product is sold to institutions, not to students. Students download it because their professor enabled it in Canvas, Blackboard, Brightspace, or Moodle. That distribution model matters: Respondus optimizes for institution-side reporting ("flag any student who launched a non-allowlisted app") rather than for catching a determined individual. The detection bar is set where it stops the casual case, not the technical one.
The companion product, Respondus Monitor, adds webcam recording and post-hoc review. Monitor is what flags suspicious head movements and prompts a human reviewer; LockDown Browser by itself is just the kiosk shell. Most posts online conflate the two. They are separate products with separate behaviors, and the distinction matters when you reason about what is actually watching the screen.
What LockDown Browser can and cannot see on macOS
On macOS, the LockDown Browser process queries the Cocoa NSWorkspace API and the lower-level proc_listpids to enumerate running apps by bundle identifier and executable path. It matches those against a static blocklist (Zoom, OBS, ScreenFlow, common remote-desktop tools, and a handful of named AI assistants). If a match is found, the test session is blocked or a flag is recorded. The shell also installs a foreground-locking loop that re-raises the browser window if it loses focus, and it disables most common screenshot shortcuts at the AppKit level.
What it does not do on macOS: it does not load a system extension, it does not have Endpoint Security entitlements, and it does not have screen-recording permission for the whole desktop (it only sees its own window, plus whatever the institution requires Respondus Monitor to capture). It cannot enumerate every NSWindow the WindowServer manages, because that requires either screen-recording consent or a private framework call Apple has been hardening since macOS 14.
This is the relevant gap. A menu-bar app with NSWindowSharingNone set on its panels is invisible to a screen capture initiated by another userspace process. The locked browser sees its own contents and nothing above it. Whisply lives above it.
How a screen capture actually flows on macOS
When any app on macOS asks to capture the screen, the request goes through ScreenCaptureKit (modern) or CGDisplayStream (legacy). The WindowServer composites the final image and hands back only the windows whose sharingType is not set to NSWindowSharingNone. Apple introduced this flag specifically so password managers, two-factor prompts, and accessibility tools could remain on screen for the human user while staying out of recordings and screen shares.
Whisply uses that flag on every panel: the chat overlay, the menu-bar response card, the streaming transcript, the settings popover. The WindowServer enforces the exclusion at composition time, which means it does not matter whether Respondus, Zoom, QuickTime, or a third-party recorder asks; they all receive a frame with Whisply absent. The protection is a property of the window, not of the requester.
This is also why a phone camera pointed at your laptop will see Whisply (the screen pixels are real), but a screen recording from inside the locked browser will not. The two paths are different. Respondus Monitor's webcam recording is unrelated to the screen-capture path and is governed by where you point your camera, not by Whisply's window flags.
How Pro Undetected hardens the bundle for Respondus
The free and Pro tiers of Whisply ship as the standard com.whisply.app bundle. That identifier is not on the public Respondus blocklist as of this writing, but it is a fixed string an institution could request be added. Pro Undetected solves that by randomizing the bundle identifier per install, removing the Dock tile, suppressing the menu-bar text, and using a generic executable name that does not match any known AI-assistant signature.
On the first launch of armed mode, Whisply walks you through a one-time Recovery-mode step to grant the renamed binary the screen-recording and accessibility permissions it needs without leaving the original app name in the TCC database. The result is that Respondus's enumeration scan sees a generic-looking process, and its window-foreground watcher never gets a focus event from the renamed app because the overlay never takes key-window status.
None of this is a guarantee. Respondus ships updates, and a future version could add new heuristics. We test against each public Respondus release within a week of its publication and ship a Whisply update if the bundle-level changes need to evolve. Armed mode is the layer we maintain in response to those updates.
Limits and honest caveats
Whisply does not work against everything. Some institutions pair Respondus LockDown Browser with Respondus Monitor and require an environment scan via the webcam at the start of the session. That scan happens on your camera, not your screen, and is governed by what your room looks like, not by Whisply's window flags. A glance away from the screen is what a human reviewer notices, not the overlay itself.
If your test is delivered through a virtual machine, a remote-desktop session into a school-owned Windows lab, or a browser running inside a virtualized macOS image, Whisply's window-flag protection only applies to the host you installed it on. Inside the guest, the proctor sees the guest's windows. We do not currently support running inside a guest VM.
And on the institutional side, some schools use Respondus Monitor's review pass to look for off-screen glances or unusual eye movement. That is a human-judgment signal, and no overlay technology changes it. If you spend the session looking at a second screen or off to the side, a human reviewer will probably notice.
Compatibility matrix
| Scenario | Whisply behavior |
|---|---|
| Respondus LockDown Browser launched in kiosk mode on macOS 14 or later | Whisply overlay stays at the WindowServer composition layer above the browser. The browser sees its own contents and the OS chrome it controls. On Pro Undetected, the renamed binary is not on the process blocklist. |
| Respondus Monitor webcam recording during the same session | Monitor records the camera input. Whisply's window flags govern screen capture, not the camera. Glancing repeatedly at the overlay is what a human reviewer may flag, not the overlay itself. |
| Cmd+Tab while the locked browser is foreground | The locked browser intercepts Cmd+Tab and re-raises its window. Whisply is summoned with Cmd+Return as a panel above the browser without taking key-window status, so the foreground-watcher does not fire. |
| Cmd+Shift+5 or Cmd+Shift+3 screenshot tool | Respondus disables most screenshot shortcuts. If a screenshot is taken through any path, Whisply's NSWindowSharingNone exclusion keeps its overlays out of the captured image. |
| Screen sharing the locked browser session to a remote proctor via Zoom or Teams | Zoom and Teams use ScreenCaptureKit. Whisply panels are excluded at the WindowServer level, so the remote proctor sees the locked browser and nothing else from Whisply. |
| Respondus running inside a guest VM (Parallels, VMware Fusion) on macOS | Not supported. The window-flag protection only applies to the host. Inside a guest, the proctor sees the guest's windows. Run the test on the host macOS install or on a separate Mac. |
| An institution that has added com.whisply.app to a custom blocklist | Pro Undetected randomizes the bundle identifier per install. The standard com.whisply.app string is not what gets scanned by Respondus after arming. |
| Microphone usage during a Respondus session | Whisply uses the microphone through the standard CoreAudio path with user consent. Respondus does not block microphone access on macOS; the relevant question is whether your institution prohibits microphones in the test environment. |
A note on academic honesty
Your school chose Respondus LockDown Browser because they want the test to be a real test of what you know. That choice exists, and so do the rules attached to it. Whisply is a private real-time AI assistant on your Mac, and the responsibility for how you use it in a proctored session is yours, not ours. If your program prohibits external AI assistance during exams, using Whisply in that session is a violation of the rules regardless of whether the proctor's software detects it. We publish this page so people understand the technology honestly. We do not publish it as permission. Read your syllabus, read your honor code, and decide before you launch the test.
Related questions
Can I use ai with respondus lockdown browser on a Mac?
Whisply runs at the macOS WindowServer layer above the locked browser, and on Pro Undetected the bundle identifier is randomized so it does not match Respondus's process blocklist. Whether you are permitted to use it during a specific proctored exam is a question for your institution's academic-conduct policy, not for the technology.
Does Respondus LockDown Browser detect Whisply?
Respondus on macOS detects external apps by enumerating running processes and matching them against a compiled-in blocklist. On Pro Undetected, Whisply's armed mode randomizes the bundle identifier and renames the executable, so the standard scan returns clean. The base Whisply bundle is not on the public Respondus blocklist as of this writing, but that can change with any Respondus update.
What about Respondus Monitor's webcam recording?
Monitor records your camera. Whisply's window-flag protection applies to screen capture, not to what your camera sees. If you spend the session glancing repeatedly at the overlay or at a second screen, a human reviewer reviewing the recording can notice that. Camera-based proctoring is a separate problem from screen-based proctoring, and Whisply only solves the second.
Does Whisply work if my school uses Respondus inside a virtual machine?
No. The NSWindowSharingNone exclusion applies on the macOS host where Whisply is installed. If Respondus is running inside a Windows guest under Parallels or Fusion, the guest does its own screen handling, and Whisply on the host cannot inject into the guest. Run the test on a native macOS install or use a separate Mac.
Is Whisply ever visible to the locked browser itself?
The locked browser is a userspace app on macOS. It can request a screen capture through ScreenCaptureKit, but that request returns a composited frame with Whisply's NSWindowSharingNone windows already excluded by the WindowServer. The browser sees its own contents and the OS chrome it controls. It does not get a privileged view of windows above it.
What happens if Respondus updates and adds new heuristics?
We track each public Respondus release on macOS and ship a Whisply update if the bundle-level signal needs to change. Armed mode is the layer we maintain against those updates. If a release adds a new detection vector that requires more than a bundle change, we say so in the changelog and on this page rather than pretending it does not exist.
Is there a tier of Whisply that works with Respondus out of the box?
Pro Undetected ships with armed mode supported for LockDown Browser as part of the standard list. The free and Pro tiers run the menu-bar overlay with the same NSWindowSharingNone protections, but the bundle identifier on those tiers is the static com.whisply.app, which an institution could request be added to a custom blocklist.
Try Whisply free.
Mac only. macOS 13 or later. No bot in your calls.