I spent two weeks reverse-engineering exactly what Zoom, Google Meet, Microsoft Teams, OBS, and other screen-sharing tools actually capture. The findings surprised me - and they should change how you think about privacy and AI tools during video calls.

This isn't a marketing post for Acemode. It's a technical deep-dive on what's actually possible at the operating system level. Some of these conclusions apply to Acemode. Most apply to any application's relationship with screen capture.

The mental model most people have is wrong

When most people think about screen sharing, they imagine the tool "taking a screenshot many times per second" of whatever is on their screen. That's roughly right for some implementations, but the reality is more nuanced.

Modern screen capture works through one of three mechanisms, and the differences matter:

  1. OS-level frame capture - the operating system itself provides the frames. This is what professional tools use. It's the fastest and most reliable, but it goes through the OS's compositor, which means the OS has full control over what's included.
  2. Window enumeration + capture - the tool asks the OS for a list of windows, then captures specific ones. Used for "share a single window" features. Limited to what the OS exposes.
  3. GPU-level capture - capturing directly from the GPU framebuffer. Used by some game streaming tools. Bypasses some OS protections but requires special permissions.

Most consumer tools (Zoom, Meet, Teams) use the first two. Some advanced tools use the third. This matters for what they can and cannot capture.

What the OS actually controls

Both macOS and Windows give applications a way to opt out of being captured. This is intentional. Why? Because some content shouldn't appear in recordings:

The mechanisms are:

macOS: CGWindowSharingType

Each window on macOS has a property called CGWindowSharingType, which can be set to one of three values:

When a window is set to kCGWindowSharingNone, screen capture tools see nothing where that window would be - they see whatever was behind the window, or the desktop background.

Windows: SetWindowDisplayAffinity

Windows has the equivalent API: SetWindowDisplayAffinity with the flag WDA_EXCLUDEFROMCAPTURE. Same concept - the OS desktop window manager (DWM) excludes the window from capture buffers.

Microsoft introduced this specifically because legitimate apps needed it. From their documentation: "Used by applications that handle high-value information that should not appear in screen captures or recordings."

What can and cannot bypass these protections

This is the question that matters most for users of stealth tools. Here's the actual answer based on testing:

Cannot bypass:

Can potentially bypass:

The screen-share notification bar - what triggers it

Some users worry about the "[Your Name] is sharing" notification bar that appears in Zoom and Meet during screen sharing. They wonder if AI tools trigger this.

The answer: no, they don't. The notification bar is shown by the conferencing tool itself, in its own window, on the sharer's screen. It's a UI element of Zoom/Meet/Teams, not something triggered by external apps.

The conferencing tool decides when to show it. It shows it when you press the "Share Screen" button in their UI. It does not show it because some other app on your computer started doing something.

What a screen-sharing tool sees vs what it shows

There's a subtle distinction here. The tool might capture a frame, but it may not show every part of that frame.

For example, in Google Meet's "share entire screen" mode:

  1. Meet asks the OS for the screen contents
  2. The OS returns the screen, with any windows marked as kCGWindowSharingNone excluded
  3. Meet streams what it received - but doesn't know what it's missing

From Meet's perspective, the excluded window simply doesn't exist. It can't show what it didn't receive. The protection is at step 2, before the data ever leaves the OS.

What about screen recording vs. live screen sharing?

Same protection. The recording flag goes through the same OS API as the streaming flag. If a window is excluded from capture, it's excluded from both live streaming and recordings.

This means: even if someone is secretly recording the call (which is a legal issue, not a technical one), excluded windows still won't appear in the recording.

The exception: virtual cameras

One subtle case: tools that route your screen output through a virtual camera (like OBS Virtual Camera, which lets you use your screen as a "webcam" feed in Zoom).

If OBS captures your screen, then sends it through a virtual webcam, then Zoom uses that as the camera feed - the protection should still hold (because OBS is the one doing the capture, and it respects the OS exclusion).

But if someone is sophisticated enough to set up a virtual capture card with a custom driver, all bets are off. This is firmly in "people who want to record you secretly are doing felonies" territory, not "normal interview risks."

What about anti-cheating software in interview platforms?

Some companies use specialized anti-cheating software during interviews - Proctortrack, Honorlock, others. These are different from screen sharing.

Anti-cheat tools typically:

These are a different threat model than a Zoom screen share. A determined anti-cheat tool with admin access can probably see anything. The question is whether they're checking and what their detection list looks like.

If your interview uses dedicated proctoring software with a kernel-level component, assume nothing is hidden from it. If your interview is just on Zoom or Meet, the OS-level protection holds.

The detection arms race

Zoom and Meet aren't actively trying to detect tools that hide from them. They're not building anti-stealth detection because their job is screen sharing for legitimate use cases (passwords, DRM, etc.).

However, in some corporate enterprise deployments, IT departments may add their own monitoring layer. If you're interviewing through your current employer's managed laptop, your IT department has probably installed monitoring software that can see things consumer tools can't.

If you're on a personal device, with consumer Zoom/Meet/Teams, OS-level protection holds.

What this means practically

For users of tools like Acemode:

For users of stricter platforms with proctoring software, the picture is different. Anti-cheat software with elevated permissions can sometimes see what Zoom can't. Know your environment.

Verify it yourself in 2 minutes

Don't take any of this on faith. The verification is trivial:

  1. Open Google Meet and create a meeting
  2. Join the same meeting from a second browser window or another device
  3. From the first window, click "Share screen" → "Your entire screen"
  4. Look at the second window - that's exactly what your interviewer would see
  5. Open Acemode (or any tool with screen capture protection)
  6. Watch the second window - the tool will not appear in the feed

I recommend every user of any stealth tool do this exact test before any real interview. The five minutes of confidence it gives you is worth it.

Final thought

Screen capture is more controllable than most people think - both for the OS to control what's captured, and for users to verify what's being captured. The technology has been around for years (DRM-protected video has been excluding itself from capture since the 2010s). It's just being used in new contexts now.

If a feature works, it works. The OS doesn't care if you're protecting a Netflix stream from screenshots or hiding a productivity tool during an interview. The protection mechanism is identical.