There is a gap in remote proctoring that the industry does not discuss openly, because acknowledging it would undermine confidence in products that millions of examinations depend on.

The gap is this: every major remote proctoring solution built on screen sharing is blind to an entire category of cheating tools — by design, not by oversight.

To understand why, you need to understand how screen capture works on modern operating systems. It is simpler than it sounds, and once you see it, the limitation becomes obvious.

Screen capture does not read your monitor

When a screen-sharing application captures your display, it does not read pixels directly from the monitor hardware. It requests a frame from the operating system's compositor — the software layer responsible for combining all the windows on screen into a single image. The compositor renders everything, then delivers the finished result to the screen-sharing application.

This indirection is normal and necessary. It is how every modern operating system draws the screen. But it introduces a middleman between "what is on the screen" and "what gets captured" — and that middleman can be instructed to leave things out.

The exclusion mechanism

The operating system provides a mechanism for windows to mark themselves as excluded from capture. When a window sets this flag, the compositor removes it from the captured frame before delivering it to screen-sharing software. The window still exists. It is still fully visible on the local screen. But anyone receiving the screen share sees a blank space where that window sits.

This mechanism exists for legitimate reasons — protecting sensitive content such as password managers, banking applications, and content under digital-rights management. The same mechanism is exploited by examination-assistance tools to make themselves invisible to proctoring software. A feature built to protect users is repurposed to defeat oversight.

The exclusion happens inside the compositor, before the frame ever reaches the screen-sharing application. There is nothing that application can do about it.

Why it cannot simply be patched

This is the detail that matters most. By the time a screen-sharing application receives a frame, the excluded content is already gone. The application is not ignoring the cheating tool; it genuinely never received those pixels.

This means that any proctoring solution built on top of screen sharing — any solution that monitors what a screen share shows — is inherently blind to tools that use this mechanism. It is not a bug that a vendor can patch in the next release. It is a fundamental architectural limitation of the layer the product is built on.

Vendors can add gaze tracking, browser lockdown, second cameras, and AI behaviour analysis on top — and those help against other attack methods — but none of them recover the pixels that were removed before capture. The blind spot remains exactly where it was.

The only way around it

The only path around the limitation is to capture the frame before the compositor applies the exclusion — to operate at a layer of the system that sees everything before filtering takes place. This is not achievable from within a screen-sharing application, because by definition it sits downstream of the compositor.

It requires a fundamentally different approach to examination delivery: a protocol that owns the capture stage itself rather than consuming the compositor's filtered output. That is precisely the design decision behind OroLink.

Key takeaways

  • Screen capture receives a composited frame, not raw monitor pixels — and windows can be excluded from that frame.
  • Because exclusion happens before capture, screen-sharing-based proctoring can never see those tools. It is architectural, not a bug.
  • The only solution is to capture upstream of the compositor's filtering — which a screen-sharing app structurally cannot do.

Understanding this limitation is the first step toward building something that actually works.