Screen privacy depends on the capture boundary

For desktop privacy tools, the hard question is not whether a window can be hidden from one sharing app. It is which capture path sees the window, and what the operating system lets that path capture. Windows, macOS and Linux do not offer one common boundary. A test that passes on one platform is not evidence that the same window is protected on another.

That is the useful category signal for builders this month: cross-platform cloaking is an integration problem as much as a window-management problem. The operating system’s capture architecture shapes what a privacy tool can verify, what permissions apply, and where assumptions can fail. Treat platform support as a starting point, not a guarantee that every recording or scraping route behaves alike.

Windows: distinguish capture routes

Windows Graphics Capture is a system API for capturing a window or display. It is one path used by capture software, not a universal switch controlling every way screen contents can be read. Other routes and older approaches exist, so a privacy tool should be tested against the capture methods relevant to its users.

For engineers, the practical test is straightforward: check the protected window in the actual sharing or recording workflow, then check again after changing the target, display, or capture mode. A result from a single window-capture test should not be generalized to every desktop capture path. Also verify titles and notifications separately; a window absent from a video frame can still reveal context elsewhere on the desktop.

macOS: permissions are not the same as cloaking

ScreenCaptureKit is Apple’s framework for screen capture. macOS also governs screen-recording access through system privacy permissions. Those controls answer whether an application can obtain screen content; they do not, by themselves, express a user’s intent to expose one window while keeping another private.

That distinction matters when reviewing a privacy tool. Permission prompts and operating-system controls are part of the security picture, but they are not a substitute for checking the captured output. A builder should test the supported macOS capture path and confirm what happens to protected windows, title text, and alerts. Do not infer that a permission granted to a capture app makes every visible item appropriate to share.

Linux: Wayland and X11 are different cases

Linux desktop capture has a sharper split. Under Wayland, capture is mediated by the compositor and commonly uses desktop portal and PipeWire components. The compositor sits between applications and much of the screen-capture flow. That is a meaningful security boundary, but it does not make every capture request harmless or guarantee that a privacy tool can cloak every window in every desktop environment.

X11 follows a different model, with clients historically able to access more shared display information. Builders should not treat a successful Wayland test as proof of equivalent behavior on X11, or the reverse. Record the session type and desktop environment during testing. Then test the capture path the user will actually run. “Linux support” needs this kind of qualification to be useful.

Test the output, not the promise

A dependable validation routine checks more than whether a private window disappears. Inspect the shared image, title lists, task switching, and notifications. Repeat the check after an application switch and on each supported operating system. Capture APIs and permission rules describe mechanisms; the visible result is what determines whether sensitive material escaped.

NoCapture says it is available on Windows 10/11, macOS, and Linux. Its listed capabilities include protecting private apps, windows, and titles from capture, masking titles in Alt+Tab, the taskbar, and window lists, and suppressing alerts from protected applications. It also has a live preview pane for checking what capture tools see. That preview is useful evidence for the path being previewed, not a universal certification of every recorder, operating-system route, or background scraper.

For a practical walkthrough of checking a share before and during a session, see how to use a live preview to audit exposure. The broader trade-off between window cloaking and virtual display approaches is covered in this comparison of cloaking methods and leak risks.

Pricing is a baseline, not a release note

The listed NoCapture plans are $0 forever for up to two protected windows on one device, $5 monthly or $39 yearly for unlimited protected windows, and $49 monthly or $399 yearly for 10 seats with administrative features. Those figures are useful when sizing a deployment; they do not answer the platform question. A low-cost plan still needs a test matrix that matches the organization’s operating systems and capture workflows.

For builders, the takeaway is to define protection per platform and per capture route. Verify what the user’s tools receive, document the limits, and repeat the check after OS or desktop-environment changes. “Cross-platform” is a distribution claim. Trust comes from the boundary you actually tested.