The Stealth Revolution: How Invisible Overlays Work Technically

In the ongoing arms race between interview proctoring software and AI assistants, the front line has moved from the browser to the Operating System. The era of simple Chrome extensions is over. The future belongs to Invisible Overlays.

But how can a window be "invisible" to a screen share while remaining perfectly visible to the user? Let's dive into the engineering.

The Problem: The Screen Capture API

Most proctoring tools (and video conferencing apps like Zoom) use standard APIs to mirror your screen. On Windows, this is often the Desktop Duplication API. On macOS, it's the ScreenCaptureKit.

When an app requests a frame of your desktop, the OS gathers all visible windows, flattens them into a single image, and sends it to the requesting app.

The Solution: Window Affinity and Exclusion Flags

Modern Operating Systems provide specific flags that allow a developer to tell the Window Manager: "This window is sensitive. Do not include it in any screenshots or screen recordings."

Windows Implementation (SetWindowDisplayAffinity)

On Windows, we use a single native call:

SetWindowDisplayAffinity(hWnd, WDA_EXCLUDEFROMCAPTURE);

• WDA_NONE: No affinity. The window is captured normally.
• WDA_MONITOR: The window is visible only on the monitor (it appears black in captures).
• WDA_EXCLUDEFROMCAPTURE: The window is completely removed from the capture buffer. This is what Control uses.

When the OS flattens the windows for a screen share, it simply skips over the window handle (hWnd) that has this flag set.

macOS Implementation (sharingType)

On macOS, the process is similar but uses the NSWindow sharing type:

window.sharingType = .none

Setting the sharing type to .none ensures that SCScreenshotManager and other capture services ignore the window entirely.

Why Browsers Can't Do This

Chrome extensions and web apps live inside a "sandbox." They don't have access to the underlying OS window handles. They can manipulate the DOM, but they cannot tell the Windows Desktop Manager (WDM) to exclude a specific <div> from the screen buffer.

This is why Control is built as an Electron-based desktop app. It bridges the gap between the web (for rendering the AI UI) and the native OS (for stealth security).

Secondary Stealth Layers

Being invisible to screen share is only half the battle. You also have to be invisible to Focus Monitoring.

1. Click-Through Windows

By setting setIgnoreMouseEvents(true) in Electron, we can make the window "click-through." This ensures that even if you accidentally click on the overlay, the mouse event is passed directly to the browser underneath. The browser never loses focus, so HackerRank never sees a blur event.

2. Overlay Composition

Control uses a transparent background with specialized CSS filters. This allows us to render high-contrast text on a "ghost" layer that sits on top of your code editors without ever interfering with your cursor or text selection.

The Result: Undetectable Assistance

By moving to the OS level, tools like Control have created a paradigm shift. We are no longer trying to hide inside the environment the proctors control. We are operating in the layer above it, using the Operating System's own privacy features to stay out of sight.

Conclusion

Technical interviews should be a test of your ability to solve problems using the best tools available. As proctored environments become more invasive, the engineering behind stealth tools becomes more essential.

Invisible overlays are not just a "trick"—they are a sophisticated implementation of OS-level security features designed to protect user privacy and autonomy.