Screen Share Proof: How PrepPilot's Overlay Stays Invisible

The single most important question candidates ask about AI interview assistants is: "Can the interviewer see it?" For browser-based tools, the answer is often yes, especially when the interviewer requests full screen sharing. For PrepPilot, the answer is definitively no. This article provides a complete technical explanation of why the overlay is invisible, how the underlying operating system APIs work, and why the native desktop approach is fundamentally more secure than browser extensions.

The Problem with Screen-Visible Overlays

Before diving into how PrepPilot solves the invisibility problem, it is important to understand why most interview assistance tools fail at it. The vast majority of AI interview helpers run as browser extensions, web applications, or Electron-based desktop apps without native window protection. Each of these approaches creates windows that are fully visible to screen capture.

When an interviewer asks you to share your screen on Zoom, Google Meet, or Microsoft Teams, the conferencing application captures the visual content of your display. Every visible window, popup, notification, and overlay appears in the captured stream. A browser extension sidebar showing AI-generated answers would be clearly visible. A separate browser window with AI coaching would be visible if it overlaps with the shared area. Even a Chrome DevTools-style popup would appear in the capture.

Some tools attempt to work around this by suggesting candidates share only the browser tab rather than the full screen. This works in some cases, but many interviewers specifically request full screen sharing, particularly for technical interviews where they want to see your entire workflow. Additionally, tab-specific sharing in Google Meet does not exist in the same way it does in Zoom, limiting this workaround to specific platforms.

Windows: The SetWindowDisplayAffinity API

Windows provides a Win32 API function called SetWindowDisplayAffinity that controls how individual windows appear in screen capture operations. This function was introduced in Windows 7 with the WDA_MONITOR flag (which displays the window only on the physical monitor and shows a black rectangle in captures) and was enhanced in Windows 10 version 2004 (May 2020 Update) with the WDA_EXCLUDEFROMCAPTURE flag.

WDA_EXCLUDEFROMCAPTURE: Complete Invisibility

The WDA_EXCLUDEFROMCAPTURE flag is the key to PrepPilot's invisibility on Windows. When this flag is set on a window handle, the Desktop Window Manager (DWM) excludes the window entirely from all capture operations. Unlike the older WDA_MONITOR flag which leaves a black rectangle where the window should be (potentially revealing that a protected window exists), WDA_EXCLUDEFROMCAPTURE makes the window completely absent from the captured frame.

Here is how it works at the compositor level. The DWM maintains a composition tree of all windows on the desktop. When a capture request comes in from an application (Zoom requesting screen pixels, OBS recording the screen, Windows Game Bar taking a screenshot), the DWM traverses this tree and renders each window into the capture buffer. Windows with the WDA_EXCLUDEFROMCAPTURE flag are simply skipped during this traversal. The pixels behind the protected window are rendered normally from whatever windows or desktop background are beneath it.

This means the captured frame shows exactly what the desktop would look like if the PrepPilot overlay did not exist. There is no black rectangle, no blurred region, no placeholder, and no visual artifact of any kind. The interviewer's view of your shared screen is completely clean.

What Capture Methods Are Affected?

The WDA_EXCLUDEFROMCAPTURE flag affects all DWM-based capture methods, which includes:

• Zoom screen sharing (all modes: full screen, application window, and portion of screen)
• Google Meet screen sharing
• Microsoft Teams screen sharing
• OBS Studio display and window capture
• Windows Game Bar recording and screenshots
• The PrintScreen key and Snipping Tool
• Any application using the Windows Desktop Duplication API, Graphics Capture API, or BitBlt from the screen DC

There is no application-layer workaround that can capture a window with this flag set. The protection operates at the compositor level, below any application code.

macOS: NSWindow.sharingType

macOS uses a different API but achieves the same result. The NSWindow class has a sharingType property that controls whether the window's content is included in screen captures and sharing sessions. Setting this property to .none excludes the window from all capture operations.

How macOS WindowServer Handles Protected Windows

The macOS WindowServer is the system process responsible for compositing all windows and handling screen capture requests. When an application requests screen capture through ScreenCaptureKit (the modern API), CGWindowListCreateImage (the older API), or any other capture mechanism, the WindowServer checks each window's sharing type. Windows with sharingType = .none are excluded from the captured image, and the pixels behind them are rendered from the window stack below.

Like the Windows implementation, there is no visual artifact in the capture. The protected window is simply absent, and the captured frame looks exactly as it would if the window did not exist.

macOS Permissions Consideration

On macOS, PrepPilot requires the standard Screen Recording permission (System Settings > Privacy & Security > Screen Recording) to capture system audio for transcription. This is the same permission that Zoom and other meeting apps require. The screen recording permission does not grant any additional access beyond what is needed, and the overlay protection works independently of this permission.

Tauri's content_protected Configuration

PrepPilot is built on Tauri, a Rust-based framework for building desktop applications. Tauri provides a first-class content_protected option in its window configuration. When enabled, Tauri automatically applies the appropriate OS-level protection: SetWindowDisplayAffinity(WDA_EXCLUDEFROMCAPTURE) on Windows and NSWindow.sharingType = .none on macOS.

This is not a custom hack or a fragile workaround. It is a supported feature of the Tauri framework, tested across versions and maintained by the open-source community. Any Tauri application can use this feature, and it has been stable across Windows 10, Windows 11, macOS Ventura, Sonoma, and Sequoia.

The Floating Pill: UX Design for Stealth

Beyond the OS-level invisibility, the overlay's visual design is optimized for stealth use. The default appearance is a small, semi-transparent pill shape approximately 320 pixels wide and 48 pixels tall in its collapsed state. It sits in a corner of the screen (configurable by the user) and uses a dark translucent background that blends with most desktop environments.

When an AI response is ready, the pill expands vertically to display the response text. The text uses a 14-pixel font with high contrast for readability. The expansion animation is smooth but fast (200ms) to avoid distracting the candidate during a conversation. When the candidate is done reading, the pill auto-collapses after a configurable timeout (default: 30 seconds) or when a new question is detected.

The pill is positioned using the Tauri window API with the always-on-top flag, ensuring it stays visible above all other windows including full-screen applications. It is draggable so candidates can reposition it to avoid overlapping with the video call window. The position persists across sessions so candidates do not need to reposition it for every interview.

Browser Extensions vs. Native Apps: A Direct Comparison

To illustrate why the native approach matters, here is a direct comparison of how browser-based and native AI interview tools behave during different screen sharing scenarios:

Scenario 1: Full Screen Sharing

Browser extension: Completely visible. Any popup, sidebar, or notification from the extension appears in the shared screen. The interviewer can see everything.

PrepPilot (native): Completely invisible. The overlay is excluded from the captured frame. The interviewer sees a clean desktop.

Scenario 2: Application Window Sharing (Zoom)

Browser extension: Visible if the browser is the shared window. The extension's UI elements are part of the browser window and appear in the capture.

PrepPilot (native): Completely invisible. Even though the overlay may visually overlap with the shared Zoom window on the candidate's screen, the captured frame excludes it.

Scenario 3: Browser Tab Sharing

Browser extension: Partially safe. Extension popups typically do not appear in tab-only captures, but extension sidebars and injected page elements may. Behavior varies by browser and extension.

PrepPilot (native): Completely invisible. Tab sharing captures only the browser tab content and never includes native desktop windows, protected or not.

Scenario 4: Screen Recording (OBS, Game Bar)

Browser extension: Completely visible. Screen recording captures everything on the display including extension UI elements.

PrepPilot (native): Completely invisible. The recording software receives frames without the protected window.

Verifying Invisibility Yourself

PrepPilot includes a built-in verification feature so candidates can confirm the overlay is invisible before their interview. The "Test Screen Share" button activates the overlay and simultaneously starts a screen recording using the system's built-in recorder. After a few seconds, it stops the recording and plays it back. If the overlay is working correctly, the playback shows a clean screen with no overlay visible, even though the overlay was on screen during the recording.

This verification takes under 30 seconds and gives candidates peace of mind before entering a high-stakes interview. We recommend running it whenever you update your operating system or graphics drivers, as these updates can theoretically affect compositor behavior (though this has not occurred in practice).

Edge Cases and Limitations

While the overlay protection is robust, there are a few edge cases worth noting. On Windows, the WDA_EXCLUDEFROMCAPTURE flag requires Windows 10 version 2004 or later. Earlier Windows versions fall back to WDA_MONITOR, which shows a black rectangle instead of complete invisibility. PrepPilot detects the Windows version and warns users if they are on an older build.

Remote desktop connections (RDP, TeamViewer, AnyDesk) present a unique scenario. When you connect to a machine via remote desktop, the remote desktop client itself is performing screen capture on the remote machine. Protected windows will not appear in the remote desktop session. This means if you are using RDP to connect to your work computer and running PrepPilot there, the overlay will not be visible in your remote desktop window. For this reason, PrepPilot should be run on the physical machine where you are conducting the interview, not on a remote machine accessed via RDP.

Linux support is more limited. The X11 window system does not have an equivalent of SetWindowDisplayAffinity, and Wayland support varies by compositor. PrepPilot on Linux uses a transparency-based approach that is less robust than the Windows and macOS implementations. We recommend Windows or macOS for the most reliable stealth experience. For platform-specific setup guides, see our articles on Zoom, Google Meet, and Teams.