Screen Sharing From VNC and RDP to getDisplayMedia: Exposure and Scams

Screen sharing started as remote desktop protocols, VNC's Remote Framebuffer protocol (described in 1998, documented as RFC 6143 in March 2011) and Microsoft's RDP, and moved into the browser with the W3C Screen Capture API and getDisplayMedia(). Today every major platform gates capture behind a picker or a permission, but the most common failures are human: a whole screen shared instead of a tab, a notification that pops up mid demo, a token printed in a terminal, or a stranger on the phone asking you to install remote access software.

That is the short answer. The longer one matters if you demo software, pair program or run a help desk, because the protections you get depend on which surface you share and which operating system draws the picker. This post covers the protocol history, what the Screen Capture specification requires of browsers, how each major OS gates capture, how to avoid leaking secrets, how to lock down remote control, what regulators say about tech support scams, and what to do after a key was visible on a shared screen.

For protocol internals, see our companion posts on RDP and VNC and how to secure them and on WebRTC, ICE, STUN, TURN, DTLS and SRTP. This post stays on the capture side: what is on the screen, who can see it and who can take control.

Key takeaways

• VNC was introduced in a January/February 1998 IEEE Internet Computing paper from the Olivetti and Oracle Research Laboratory in Cambridge. Its Remote Framebuffer (RFB) protocol was written up as informational RFC 6143 in March 2011, which says plainly that RFB offers no security beyond an optional, weak password check.
• Microsoft describes RDP as an extension of the ITU T.120 protocol family, with up to 64,000 virtual channels for clipboard, drives, printers, audio and more. BlueKeep (CVE-2019-0708), released by Microsoft on 14 May 2019, was a pre authentication remote code execution flaw in Remote Desktop Services; Microsoft shipped fixes even for out of support Windows versions.
• The W3C Screen Capture specification defines getDisplayMedia(). Browsers must let the user pick the surface every time, must not let the page narrow that choice, require a user gesture, and cannot persist the permission. The spec tells browsers to steer users away from sharing a whole monitor.
• Sharing a tab exposes one page. Sharing a window exposes one application. Sharing a screen exposes everything that appears on it, including notifications, password manager popups and the meeting chat.
• macOS gates capture in Privacy and Security, Screen and System Audio Recording. Windows draws a yellow border around any window or display captured through its Graphics Capture API. Android 14 added single app sharing and per session consent; Android 15 hides notification content and one time passcodes from screen shares. iOS apps can detect when the screen is being recorded or mirrored.
• If a secret appears on a shared or recorded screen, treat it as exposed. Revoke it, rotate it, remove it from wherever it was displayed and check the logs, in that order, as the OWASP Secrets Management Cheat Sheet recommends.
• The FBI reported 19,000 tech support scam complaints with estimated losses over 542 million dollars in the first half of 2023 alone. The FTC's rule of thumb: real security warnings never ask you to call a phone number, and legitimate tech companies do not cold call you about your computer.

Milestones: from framebuffers to browser pickers

Dates below come from the primary documents listed in the Sources section. Where a source gives a version rather than a date, the table says so instead of guessing.

We could not confirm a first release date for RDP on a Microsoft page we fetched, so the table leaves it undated rather than repeating the commonly cited late 1990s Terminal Server date.

How the main screen sharing technologies compare

How did VNC and RDP work, and what security history did they collect?

VNC and the Remote Framebuffer protocol

The 1998 VNC paper describes "an ultra-thin client system based on a simple display protocol that is platform independent." The idea was radical for its time. Instead of carrying your laptop, you could reach your own desktop, with its applications still running, from any machine in the building or anywhere in the world. RFC 6143 keeps that framing: RFB operates on the framebuffer, so it applies to any windowing system, and the client is stateless, so you can disconnect and reconnect from a different machine and find the session exactly where you left it.

The protocol is simple. A server listens on TCP 5900. The client and server agree on a protocol version and a security type, then the server sends rectangles of changed pixels and the client sends key and pointer events. The RFC defines only two working security types: None, and VNC Authentication. VNC Authentication is a 16 byte random challenge that the client encrypts with DES, using the user's password as the key, truncated to eight characters or padded with nulls. The RFC states that this check is cryptographically weak and that the base protocol offers no protection against observation or tampering. Its own advice is to agree an extended security type or to run the session over a secure channel such as IPsec or SSH.

That design explains VNC's security history. The protocol was built for trusted lab networks. Put it on the open internet with no password, or with an eight character password, and anyone who finds the port gets your screen and your keyboard. MITRE ATT&CK tracks this as a lateral movement technique, which we cover in T1021.005, VNC remote control.

RDP and its virtual channels

Microsoft's developer documentation describes RDP as a protocol for remote display and input over network connections, "based on, and an extension of, the ITU T.120 family of protocols." Where VNC ships pixels, RDP uses its own server side video driver to package rendering information, and its own keyboard and mouse drivers to receive input. It supports up to 64,000 virtual channels. Those channels are what make RDP useful and what make it risky: clipboard sharing, printer redirection, sound, and local drive redirection, which makes the client's local drives visible inside the remote session. Microsoft also documents that support staff can view and control a user's remote session, which is the shadowing feature help desks use.

The legacy design used RC4 encryption with a 56 or 128 bit key. Modern deployments use TLS and Network Level Authentication (NLA), which forces the user to authenticate before a full remote session is created. The full protocol is published in Microsoft's Open Specifications as MS-RDPBCGR, Basic Connectivity and Graphics Remoting.

BlueKeep and the lesson it left

On 14 May 2019 Microsoft released fixes for CVE-2019-0708, a remote code execution flaw in Remote Desktop Services (formerly Terminal Services), reachable by an unauthenticated attacker who connects over RDP and sends crafted requests. NVD lists CVSS base scores of 9.8 and 10.0, and CISA added it to the Known Exploited Vulnerabilities catalog on 3 November 2021. Microsoft took the step of publishing updates for platforms out of mainstream support, through the Update Catalog only, because of the potential impact.

The MSRC mitigation guidance is still the template for remote desktop exposure. Install the update. Enable NLA on supported systems, because "an attacker would first need to authenticate to Remote Desktop Services using a valid account" before reaching the flaw. Block TCP 3389 at the perimeter. Disable Remote Desktop Services where you do not need them. Our BlueKeep explainer covers the vulnerability itself, and T1021.001, Remote Desktop Protocol covers how attackers use RDP once they have credentials.

The pattern across both protocols is the same: tools built for trusted networks become dangerous when exposed to the internet or left with side channels such as clipboard and drives on by default.

What does the W3C Screen Capture spec define?

The W3C Screen Capture specification defines how all or part of a user's display can become the source of a media stream through navigator.mediaDevices.getDisplayMedia(). It extends the Media Capture API that also gives us getUserMedia() for cameras and microphones. The stream can be recorded locally or sent over WebRTC. As of this writing, the latest version on w3.org is a Working Draft dated 27 August 2026, and the editor's draft still carries the note that it is subject to major changes.

The spec is unusually direct about risk. Its introduction warns that the feature has significant security implications, because a page that captures a display could see confidential information from other origins that the browser sandbox would normally hide. The rules that follow are designed around that:

• The user chooses, every time. The browser must let the user choose which surface to share from all available choices on every call, and the page cannot use constraints to limit that choice. Constraints apply only after the user picks.
• No persisted permission. A granted capture permission cannot be persisted. MDN's summary is blunt: the user must be prompted every time.
• A user gesture is required. If the page does not have transient activation, meaning the user just clicked or pressed something, the call is rejected. MDN adds that the API is available only in secure contexts (HTTPS).
• Steer away from monitors. Browsers are "strongly recommended to steer users away from sharing a monitor," and encouraged to warn against sharing browser windows or screens where browser windows are visible.
• Do not capture the prompt. The picker and its previews must not appear in the captured stream.
• Audio is optional and separate. System audio must not be shared without active consent, and the spec encourages browsers to let users share video without audio.
• Privacy indicators. The spec extends the Media Capture privacy indicator rules so browsers can show when display capture is live.

The spec also defines a CaptureController object and a set of hints a page can pass. displaySurface says which kind of surface the app would like offered first. selfBrowserSurface asks the browser to exclude the current tab, which avoids the "hall of mirrors" effect when someone shares the meeting tab itself. surfaceSwitching asks the browser to offer a "share this tab instead" control. systemAudio and windowAudio control which audio options appear. monitorTypeSurfaces can ask the browser to leave whole screens out of the picker. setFocusBehavior() lets the capturing app decide whether the captured tab or window comes to the front.

Chrome's developer documentation describes how Chrome implements these hints and why. Video conferencing apps can set monitorTypeSurfaces: "exclude" to protect companies from leaks caused by employee error, and Chrome then removes the Entire Screen pane. Chrome deliberately does not let a page pre select a specific window or screen, because that "would give the web app too much power over the user." Chrome documents systemAudio from version 105, displaySurface, surfaceSwitching and selfBrowserSurface from version 107, and monitorTypeSurfaces from version 119, all on desktop.

What is the difference between sharing a screen, a window and a tab?

The spec defines three display surface types: monitor (a physical display or a collection of displays), window (a single application window) and browser (a single browser tab). The differences matter more than most people expect.

A few details are easy to miss:

• Hidden content in windows. The spec encourages browsers to obscure parts of a window that are not currently rendered, but how they do it varies. Some freeze the last image, some grey it out. Do not rely on an overlapping window to hide something from a window share.
• Screen sharing on a multi monitor setup. Some systems aggregate several displays into one logical monitor. Check which surface the preview shows before you click Share.
• Mobile is different. The spec notes that small screen devices often have no concept of a window. That is why Android added its own app level sharing, covered next.

The safest default for most work is a tab, then a window, and only then a screen. If your meeting tool offers it, use a dedicated empty desktop or a second display reserved for presenting.

How do macOS, Windows, Android and iOS gate screen capture?

Browsers sit on top of the operating system. Even if the browser shows a picker, the OS decides whether the browser, or any other app, may read the screen at all.

macOS

Apple's Mac User Guide puts the control in System Settings, Privacy and Security, Screen and System Audio Recording. For each app listed you turn recording on or off, and you can allow both screen and audio, or audio only. Apple notes that once you allow a third party app or website to record, what it collects is governed by that party's own terms and privacy policy.

For developers, Apple's ScreenCaptureKit documentation says to request screen recording permission before capturing and to add an NSScreenCaptureUsageDescription key explaining why. Apple recommends its system content sharing picker, SCContentSharingPicker, rather than a custom selection interface. Remote access apps get special treatment: the Persistent Content Capture entitlement, available from macOS 14.4, lets approved VNC apps view and record the screen, and an app must apply to Apple before it can use it.

For managed Macs, Apple's Privacy Preferences Policy Control payload has a Screen recording entry that can only deny named apps access to capture the contents of the display. In other words, an administrator can block screen capture for named apps through device management, but cannot silently grant it.

Windows

Microsoft's Windows Graphics Capture documentation describes a secure system picker, GraphicsCapturePicker, through which the user picks a display or window. While capture runs, "a yellow notification border is drawn by the system around the actively captured item," one per item if several captures run at once. After the user consents, the app can use that captured item across several sessions.

On the protection side, SetWindowDisplayAffinity with WDA_EXCLUDEFROMCAPTURE, introduced in Windows 10 version 2004, makes a window appear only on the physical monitor and nowhere else, including captures. Password managers and banking apps can use this so their windows do not show up in captures. On older Windows versions the same flag behaves like WDA_MONITOR.

Android

Android's media projection API dates to Android 5 (API level 21). An app asks MediaProjectionManager for a screen capture intent, and the system shows a consent dialog. Android 14 (API level 34) introduced app screen sharing, letting the user share a single app instead of the full display, and the Android docs say app screen sharing leaves out the status bar, navigation bar, notifications and other system interface elements, even when the app runs full screen. The Android 15 feature overview notes this was first enabled in Android 14 QPR2, and that for apps targeting Android 14 or higher, user consent is required for each MediaProjection session.

Android 15 added a set of screen share protections for all apps:

• Notification content is hidden during screen sharing. If an app provides a public version of a notification, Android shows that instead; otherwise the content is redacted.
• Sensitive content such as password input is hidden from remote viewers.
• Activities from apps that post notifications where a one time passcode is detected are hidden.
• A status bar chip alerts the user to screen sharing, casting or recording, and projection is suspended when the lock screen activates. Google's stated reason: "Screen projection exploits expose private user data such as financial information because users don't realize their device screen is being shared."
• Apps can register a screen recording callback and warn users when they are visible in a recording.

Developers can exempt themselves for demos using the Disable screen share protections option in Developer Options. Leave that off on any phone you use for real accounts. The system's own screen recorder is exempt because its recordings stay on the device.

iOS and iPadOS

On iPhone and iPad, apps cannot read other apps' screens on their own. Capture starts from system controls, and Apple's developer documentation describes a broadcast picker (RPSystemBroadcastPickerView) in which the user selects a broadcast provider, with ScreenCaptureKit now recommended in its place. Apps can observe UIScreen.isCaptured, which Apple documents as true while the system is recording, mirroring or using AirPlay to stream the screen, and react, for example by pausing sensitive content. Apple also notes that FairPlay protected video is blacked out in recordings and mirrors, although its audio is not.

How do you avoid exposing tokens, keys and customer data while sharing?

Most screen sharing leaks are not exotic. They come from a handful of places that a presenter forgets are visible.

Terminals. Commands such as env, printenv, cat .env, history, verbose debug output, kubectl get secret with YAML output, and cloud CLI configuration listings can print live credentials. So can a failed command that echoes a connection string. Scrollback keeps all of it one scroll away.

Editors and IDEs. A file tree showing .env or credentials.json, a search result or a debugger variable view can expose values.

Browsers. Password manager dropdowns, saved form values, other tab titles and address bar suggestions all appear in a window or screen share.

Consoles. Cloud consoles show new access keys; support consoles show personal data. Demo them in a tenant with synthetic data.

Notifications. A chat preview, a mirrored SMS passcode or a calendar invite with a dial in PIN.

Recordings. Anything shown in a recorded meeting is stored, often transcribed and sometimes shared widely. A token nobody noticed live can be paused and read later. The Screen Capture spec makes the same point: content that appears only briefly may slip past a human viewer, but not past a machine.

The habits that work: share a tab or window; use a demo browser profile with no saved passwords; keep secrets in a secrets manager or keychain rather than files you might cat; use demo tenants with synthetic data; mute notifications. Before you share, ask what someone would read if this frame were paused and zoomed.

What do Do Not Disturb and notification masking do?

Notification controls stop the most common accidental leak, the message preview that slides in during a demo.

On Windows 11, Microsoft's support documentation says Do not disturb silences notifications and can turn on automatically. Under Settings, System, Notifications, Turn on do not disturb automatically, the conditions include "When duplicating the display," "When playing a game" and "When using an app in full-screen mode." Notifications you miss are waiting in the notification center afterwards.

On macOS, Apple's Notifications settings include Show Notifications: when mirroring or sharing the display, which you can set to pause notifications. Focus modes add schedules and per app rules on top.

On Android 15, as described above, the system redacts notification content during screen shares on its own, shows a public version where the app provides one, and hides OTP related activities.

Two limits are worth knowing. These settings act on system notifications, not on in app banners inside the window you shared. And "when duplicating the display" rules are aimed at mirroring to a projector, so check whether your setup counts a meeting app's share as duplicating. The reliable approach is to switch Do Not Disturb on by hand before presenting.

How do remote control features in meeting tools work, and how should they be locked down?

Screen sharing shows pixels; remote control sends keyboard and mouse input to another machine. RDP and VNC are remote control protocols first, while browser getDisplayMedia() is capture only. Meeting platforms that offer remote control add it through their desktop client, typically as a "request control" action the sharer must approve and can revoke. Check your own platform's documentation, because the details differ.

A lockdown checklist that applies whatever tool you use:

• Disable remote control by default in the meeting platform's admin settings, and enable it only for groups that need it, such as the help desk.
• Restrict who can request control to people inside your organisation; block it for external participants and guests.
• Require explicit approval each time and make the "stop" control obvious to users.
• Prefer view only for pair programming and design review. Most of the value comes from seeing, not driving.
• For dedicated remote access tools, require multi factor authentication, turn off unattended access unless a ticket justifies it, log every session, and remove agents from machines that no longer need them. MITRE ATT&CK tracks attacker use of legitimate remote access software as T1219.002, Remote Desktop Software.
• For RDP, follow Microsoft's BlueKeep era guidance: patch, require NLA, keep 3389 off the internet, and disable the service where it is not needed. Turn off drive and clipboard redirection where support staff do not need them.
• For VNC, never expose 5900 to the internet. Bind the server to localhost and reach it through SSH or a VPN, as RFC 6143 suggests.

What are tech support scams, and what do regulators advise?

A tech support scam is fraud in which someone posing as a support technician persuades a victim to grant remote access, pay for fake repairs or move money. The remote control features above are the scammer's main tool.

The FBI's Internet Crime Complaint Center described the pattern in its 29 September 2023 announcement on "Phantom Hacker" scams, which it described as an evolution of general tech support scams. In the first phase, a fake support agent reaches the victim by phone, text, email or a pop up and asks them to call a number. Once the victim calls, the scammer "directs the victim to download a software program, allowing the scammer remote access," pretends to run a virus scan, and asks the victim to open financial accounts. Later phases bring in fake bank and fake government callers who tell the victim to move money to a "safe" account. The FBI reported 19,000 tech support scam complaints to IC3 between January and June 2023, with estimated losses of over 542 million dollars; almost half of victims were over 60, and they accounted for 66 percent of losses.

The FBI's advice is short:

• Do not click unsolicited pop ups, text links or email attachments.
• Do not call a phone number from a pop up, text or email.
• Do not download software at the request of someone who contacted you.
• Do not let an unknown person who contacted you control your computer.
• The US government will never ask you to send money by wire to foreign accounts, cryptocurrency or gift cards.
• Report to your local FBI field office and to ic3.gov.

The FTC's consumer guidance adds the signs to watch for: fake security pop ups that urge you to call, calls from someone claiming to be a technician from a well known company, scam numbers placed in search results and ads, fake subscription renewal notices that demand a call within 24 hours, and government impersonation. Its most useful line: "Real security pop-up warnings and messages will never ask you to call a phone number." It also says legitimate tech companies will not contact you by phone, email or text about a problem with your computer. It warns that requests for payment by gift card, wire transfer, cryptocurrency or payment app are a red flag because that money is hard to recover. If you gave a scammer a password, change it, and change it anywhere else you reused it. Report scams at ReportFraud.ftc.gov.

The same scam targets employees, with attackers posing as the internal help desk. A policy that the help desk never starts unscheduled remote sessions, plus a known way to verify callers, blunts it.

Step by step: prepare a machine for sharing and check remote access exposure

These steps are for your own machines. Run them before a demo day, a support rotation or a pairing session.

1. Find remote desktop services listening on your machine

On macOS:

# List listening TCP sockets and look for VNC (5900) and RDP (3389)
sudo lsof -nP -iTCP -sTCP:LISTEN | grep -E ':(5900|3389) '

On Linux:

ss -ltnp '( sport = :5900 or sport = :3389 )'

On Windows (PowerShell):

# Is anything listening on RDP or VNC ports?
Get-NetTCPConnection -State Listen -LocalPort 3389,5900 -ErrorAction SilentlyContinue

# Is Remote Desktop enabled? 0 means connections are allowed
Get-ItemProperty 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections

# Is Network Level Authentication required? 1 means yes
(Get-CimInstance -Namespace root\cimv2\TerminalServices `
  -ClassName Win32_TSGeneralSetting -Filter "TerminalName='RDP-Tcp'").UserAuthenticationRequired

If something is listening that you did not expect, find the owning process and decide whether it should exist at all. If you need RDP, require NLA and keep 3389 reachable only through a VPN or gateway.

2. Reach VNC through SSH instead of exposing it

RFC 6143 recommends a secure channel such as SSH. Bind the VNC server to localhost on the remote host, then forward a local port:

# Forward local port 5901 to the VNC server on the remote host's localhost:5900
ssh -L 5901:localhost:5900 user@remote-host
# Then point your VNC viewer at localhost:5901

3. Review which apps can record your screen

On macOS, open System Settings, Privacy and Security, Screen and System Audio Recording and turn off any app you no longer use for sharing. If you want an app to ask again next time, reset its decision. This changes a permission, not your files, but check the bundle ID first so you reset the right app:

# Confirm the bundle ID of the app before resetting its permission
osascript -e 'id of app "AppName"'

# Reset the screen recording decision for that one app
tccutil reset ScreenCapture com.example.appname

On Windows, review Settings, Privacy and security for apps you do not recognise, and remember that Graphics Capture always draws a yellow border while it runs. On Android, look for the status bar chip during any share, and make sure Disable screen share protections in Developer Options is off.

4. Silence notifications automatically

• Windows 11: Settings, System, Notifications, Turn on do not disturb automatically, then tick "When duplicating the display" and "When using an app in full-screen mode."
• macOS: System Settings, Notifications, set Show Notifications: when mirroring or sharing the display to off, and add a Focus mode for presenting.
• Android 15 and later: content redaction is on by default during shares; also turn on Do Not Disturb for the session.

5. Set up a clean terminal for demos

# bash: commands that start with a space are not saved to history
export HISTCONTROL=ignorespace

# zsh equivalent
setopt HIST_IGNORE_SPACE

# Read a secret without echoing it to the screen
read -rs API_TOKEN && export API_TOKEN

# Clear the screen and the scrollback buffer before you share
clear && printf '\033[3J'

Use a separate presenting profile with no restored sessions, so old scrollback does not reappear.

6. If you build a web app that shares screens, ask for a tab by default

The Screen Capture spec and Chrome's documentation give you hints that make the safe choice the easy one. Call this from a click handler, because a user gesture is required:

shareButton.addEventListener("click", async () => {
  const controller = new CaptureController();
  const stream = await navigator.mediaDevices.getDisplayMedia({
    video: { displaySurface: "browser" }, // offer tabs first
    audio: true,
    controller,
    monitorTypeSurfaces: "exclude",       // hide the Entire Screen option
    selfBrowserSurface: "exclude",        // do not offer this meeting tab
    surfaceSwitching: "include",          // allow "share this tab instead"
    systemAudio: "exclude",               // tab audio only, not system audio
  });
  const [track] = stream.getVideoTracks();
  // Check what the user actually picked; hints are not guarantees
  console.log(track.getSettings().displaySurface);
});

These are preferences, not enforcement. Browsers ignore hints they do not support, and the user keeps the final choice, so read displaySurface from the track settings if your app needs to know.

What should a team's screen sharing policy say?

A good policy is one page. It should cover:

1. Default surface. Share a tab or a window. Share a full screen only when needed, and use a clean display or desktop when you do.
2. Before sharing. Do Not Disturb on; demo browser profile; demo tenant with synthetic data; clean terminal; close password managers and personal chat.
3. Secrets on screen. Never display production secrets. If one is displayed, report it and rotate it; no one is blamed for reporting.
4. Recordings. Who may record, where recordings live, how long they are kept, and who reviews recordings before they are shared outside the meeting.
5. Remote control. Off by default; internal participants only; help desk use by ticket; view only for pairing.
6. Remote access tools. An approved list, MFA required, unattended access only with a ticket, session logs kept.
7. Help desk verification. The help desk never asks you to install software or accept a remote session it did not schedule. Here is how to verify a caller.
8. Customer data. No live customer records in demos or training sessions, and masked views for support screen shares.
9. Device settings. Review screen recording permissions quarterly and keep Android screen share protections on.

What should you do if you exposed a secret on a shared screen?

Treat it as exposed, even if you think nobody noticed. Recordings, transcripts and screenshots outlive the meeting. The OWASP Secrets Management Cheat Sheet lists the containment order, and it applies directly:

1. Revoke. De authorise the exposed key at the issuer immediately.
2. Rotate. Create a replacement and deploy it, ideally through an automated process.
3. Delete. Remove the secret from wherever it was displayed: the file you opened, the shell history, logs, and the meeting recording or transcript.
4. Log and review. Check the provider's audit logs for use of the old credential between exposure and revocation.

As an example for a cloud access key, the commands below create a new key and disable and delete the old one. Deleting a key is irreversible. List the user's keys first and check the key ID twice so you remove the exposed key, not the one you just created.

# 1. Confirm which key IDs exist for this user
aws iam list-access-keys --user-name deploy-bot

# 2. Create the replacement key and update your secret store with it
aws iam create-access-key --user-name deploy-bot

# 3. Disable the exposed key (reversible) and watch for breakage
aws iam update-access-key --user-name deploy-bot \
  --access-key-id AKIAEXPOSEDKEYID --status Inactive

# 4. After checking the ID again, delete the exposed key (irreversible)
aws iam delete-access-key --user-name deploy-bot \
  --access-key-id AKIAEXPOSEDKEYID

For tokens and SSH keys, use the issuing service's revocation page or CLI, then remove the old value from config files and history. For a password, change it everywhere you reused it. If the screen showed customer personal data, follow your incident and privacy process, because notification duties may apply.

Finally, ask the meeting owner to trim or delete the recording and transcript.

Choosing what to share: a decision table

Common mistakes

• Sharing the entire screen by habit. It turns every notification and every other app into part of the presentation.
• Assuming overlapped windows hide content. Window capture behaviour for obscured areas varies by browser and OS.
• Leaving notifications on. A single chat preview or SMS code can be enough.
• Demoing with production data. Real customer names, emails and tokens end up in recordings that live for years.
• Treating "nobody saw it" as safe. Recordings can be paused, zoomed and transcribed. Rotate.
• Exposing VNC or RDP to the internet. RFC 6143 itself says RFB has no protection against observation or tampering; BlueKeep showed what an exposed RDP service can mean.
• Leaving drive and clipboard redirection on for every RDP session, including ones with untrusted hosts.
• Granting screen recording permission once and forgetting it. Review the list on macOS and remove apps you no longer use.
• Turning off Android screen share protections for a demo and leaving them off.
• Accepting a remote session from an unexpected caller, including one claiming to be your own help desk.

FAQ

Is it safer to share a tab or a window?

A tab is usually safer because it exposes one web page and nothing else in the browser. A window exposes everything inside one application, which for an IDE or terminal can include other files and tabs. Share a full screen only when you must.

Can a website record my screen without asking?

No. The W3C Screen Capture spec requires a user gesture, a picker where you choose the surface every time, and no persisted permission. The operating system may also require you to grant the browser screen recording permission, as macOS does.

Why does my Mac ask for screen recording permission?

macOS gates screen capture per app under Screen and System Audio Recording, and apps ask when they first need access. Apple reserves persistent screen access for approved VNC apps through a special entitlement. If prompts confuse you, review the list in System Settings and remove apps you no longer use.

Does Do Not Disturb hide notifications during screen sharing?

On Windows 11 you can turn on Do not disturb automatically "when duplicating the display." On macOS you can pause notifications when mirroring or sharing the display. Android 15 redacts notification content during screen shares by default. None of these hide in app banners inside the window you are sharing.

What should I do if I showed an API key on a video call?

Rotate it as if it were public. Revoke the old key, issue a new one, remove the old value from files and history, check the provider's logs for use, and ask the meeting owner to trim or delete the recording and transcript.

Is VNC secure?

The base protocol is not. RFC 6143 says RFB provides no security beyond a weak DES based password check and no protection against observation or tampering. Run VNC only over SSH, a VPN or an extended security type that encrypts the session, and never expose port 5900 to the internet.

How do tech support scammers use screen sharing?

They contact you or trick you into calling them, then ask you to install remote access software so they can control your computer, fake a virus scan and get into your financial accounts. The FBI and FTC both say never to let someone who contacted you take control of your computer.

What is the Android screen sharing status bar chip?

On Android 15 devices, a chip in the status bar shows when the screen is being shared, cast or recorded, and projection pauses when the lock screen comes on. Android added it because users often did not realise their screen was being shared.

Where Safeguard fits

Safeguard does not manage screen sharing, meeting platforms, device permissions or remote access tools, and nothing in the steps above depends on it. Credential rotation after an on screen exposure is a job for your identity provider, cloud console and secrets manager. The honest connection is narrower. The browsers, meeting clients, remote desktop servers and VNC implementations that carry screen sharing are built from open source components, and the services you rebuild or redeploy after rotating a credential pull their dependencies again. Safeguard scans repositories, container images and SBOM files for known vulnerable components, shows which projects contain a given component and version, and can open fix pull requests when a fixed version exists. If you build a product that embeds a VNC library, a WebRTC stack or a remote support agent, that is where Safeguard helps.

Fix it without waiting for upstream

Screen sharing safety is mostly habits and settings, but the software that carries it, from WebRTC stacks to VNC libraries and remote support agents, ships open source components that need patching like any other dependency. And after a secret is rotated, the services you redeploy rebuild from their dependency trees, which is a good moment to make sure they rebuild from fixed versions.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show Safeguard's dependency workflows and its approve each step model for remote work, not meeting or screen sharing settings. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo is a real Android session: you send work to a computer running the Safeguard CLI and approve the command on the phone with Allow once, Allow for turn or Deny. It is the opposite of unattended remote control. Nothing runs on the computer until a person approves that specific command, which is the same principle this post recommends for help desk sessions.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same flow applies when the component to bump is a VNC, WebRTC or remote support library pinned in a project you own.

Click through it at your own pace, or open it full screen.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. After you rotate a credential and rebuild a service, the same terminal scan checks the rebuilt project's dependencies before it goes back into production.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• W3C: Screen Capture (Working Draft)
• W3C: Screen Capture editor's draft
• W3C API: Screen Capture specification record and version history
• MDN: MediaDevices.getDisplayMedia()
• Chrome for Developers: Privacy-preserving screen sharing controls
• IETF RFC 6143: The Remote Framebuffer Protocol
• Richardson, Stafford-Fraser, Wood and Hopper: Virtual Network Computing, IEEE Internet Computing, 1998 (ORL reprint)
• Microsoft Open Specifications: MS-RDPBCGR, Remote Desktop Protocol Basic Connectivity and Graphics Remoting
• Microsoft Learn: Remote Desktop Protocol
• Microsoft Security Update Guide: CVE-2019-0708
• Microsoft Support: Customer guidance for CVE-2019-0708
• NVD: CVE-2019-0708
• Microsoft Learn: Screen capture (Windows Graphics Capture)
• Microsoft Learn: SetWindowDisplayAffinity function
• Microsoft Support: Notifications and Do Not Disturb in Windows
• Apple Support: Control access to screen and system audio recording on Mac
• Apple Support: Change Notifications settings on Mac
• Apple Platform Deployment: Privacy Preferences Policy Control payload
• Apple Developer: ScreenCaptureKit
• Apple Developer: SCContentSharingPicker
• Apple Developer: Persistent Content Capture entitlement
• Apple Developer: ReplayKit
• Apple Developer: RPSystemBroadcastPickerView
• Apple Developer: UIScreen.isCaptured
• Android Developers: Media projection
• Android Developers: Android 15 behavior changes for all apps
• Android Developers: Android 15 features and APIs overview
• FBI IC3 PSA: "Phantom Hacker" scams target senior citizens (29 Sep 2023)
• FTC: How to spot, avoid, and report tech support scams
• OWASP Secrets Management Cheat Sheet

Last reviewed: 23 October 2026. The W3C Screen Capture specification is still a Working Draft and operating system capture controls change with each release; check the linked pages for the latest behaviour.