Click Start sharing in Linkside and one action sets several systems in motion. Linkside asks for screen capture. Your browser asks you what to share. After you choose, the browser captures, encrypts, and sends the result through WebRTC.
The most important boundary is simple: Linkside does not get a list of your open windows, build the chooser, or receive screen content before you approve a choice. The chooser belongs to your browser, even when part of it looks like operating-system UI.
Who controls what?
| Layer | Its job |
|---|---|
| Linkside | Checks that the room is active, asks for capture, connects the returned tracks to each viewer, and handles the Stop control. |
| Your browser | Requires your current action, presents the choices, captures the selected surface, and handles WebRTC encoding and encryption. |
| Browser and OS internals | Divide the platform-specific capture work. That internal split varies and is not exposed to Linkside through the browser’s API. |
1. Linkside asks the browser for permission
Linkside starts with the browser’s Screen Capture API:
const stream = await navigator.mediaDevices.getDisplayMedia({
video: true,
audio: true,
});Only the host’s Start sharing action reaches this call. Linkside first prevents a duplicate request and confirms that the room is still active. Loading a room, joining as a guest, or waiting in a room does not start screen capture.
The browser allows this API only in a secure context and requires a current user action, such as your click. Screen-capture permission cannot be saved for later. Every new request requires a new choice.
2. Your browser presents the chooser
The chooser is browser-controlled UI, not a Linkside page. It lets you choose an available browser tab, application window, or monitor for every request. Its design varies by browser and operating system, but Linkside cannot replace it with a silent or preselected choice.
Sites can pass hints that influence the chooser or the handling of the selected track, but those hints cannot silently choose a surface for you. Linkside makes a basic request—{ video: true, audio: true }—without naming or preselecting a tab, window, or monitor.
If you approve the request, the browser returns a live media stream. If you cancel or deny it, Linkside receives no stream. Asking again brings the choice back.
For the practical permission model, including why approval cannot be saved, read what screen-sharing permissions mean. If you want to minimize what can appear, see how to share one browser tab.
3. Your choice becomes a live stream
After approval, getDisplayMedia() returns a MediaStream: a browser object that groups live media tracks. It contains one video track and may also contain an audio track, depending on what the browser returns for your selection.
This is a live feed, not a screenshot or a file upload. Linkside keeps the stream in client-side state while you share it. There is no recording or upload-to-storage step: Linkside does not record sessions, transcribe audio, or analyse screen contents.
Linkside also listens for the browser to say that capture has ended. Stopping through the browser or selecting Linkside’s Stop control triggers the same cleanup: the captured tracks stop, the client-side stream is cleared, and the host’s peer connections close.
4. WebRTC carries the stream to each viewer
Capture and delivery are separate jobs. For each active guest, Linkside creates a WebRTC peer connection and attaches the captured video and audio tracks. Linkside’s signaling service helps the two browsers exchange the connection details they need, but it does not carry the screen media itself.
The browser then encodes and sends each track. WebRTC requires encrypted media: it uses SRTP for the media and DTLS-SRTP to establish the keys. The browsers handle those keys; Linkside’s application code does not receive them.
Linkside tries a direct browser-to-browser route first. If restrictive networks or NAT prevent a direct connection, it can fall back to a TURN relay. The relay forwards encrypted packets, but it cannot decrypt the screen or audio. The route changes; the browser-to-browser encryption does not. How peer-to-peer screen sharing works explains that negotiation in more detail.
At the other end, the viewer’s browser receives and decodes the tracks. Linkside places them into a client-side stream for the viewer to watch.
Chat and annotations take a separate lane
The screen is not the only data moving between the browsers. Linkside also supports chat and on-screen annotations, but those messages do not get mixed into the video.
Screen and audio use WebRTC media tracks. Cursor, laser, stroke, and clear messages use a separate data channel configured not to retry stale movements. Chat uses another, ordered data channel. Linkside validates those application messages when they arrive.
The browser encrypts and transports these data-channel messages with DTLS. Linkside defines what the messages mean and how the interface displays them. It does not keep persistent chat logs after the session.
What Linkside can—and cannot—observe
Encryption protects the content, but running a live service still exposes limited operational information. Linkside’s signaling worker can observe that a room exists, roughly when guests join, and how long the session lasts. If a relay is needed, it can observe the routing of encrypted packets. The network edge also sees the IP-level traffic needed to deliver those packets.
None of those systems can read the screen or audio. Linkside does not retain this operational information long-term or pair it with an account identity, and it does not require an account, email address, or phone number. Rooms are temporary and disappear when the session ends.
What to check before you trust a screen-sharing app
Browser protections are only part of the answer. Before trusting any screen-sharing product, check both the browser boundary and the product’s own choices:
- Choice: Did you initiate the request, and did your browser let you choose the exact tab, window, or monitor?
- Control: Can you see that capture is active and stop it from the browser or the app?
- Route: Does the product explain whether media is direct, relayed, and encrypted?
- Afterward: Does it keep recordings, transcripts, chat logs, or session history?
For Linkside, the answers are explicit: browser-controlled selection, peer-to-peer-first media, encrypted relay fallback when needed, no recordings or content analysis, no persistent chat logs, and temporary rooms.
You can test the boundary in a new Linkside room: select Start sharing, cancel the chooser, and select Start sharing again. Linkside receives no stream from the canceled request, and your browser asks you to choose again.