A website cannot quietly decide to capture your screen. A getDisplayMedia request needs a current user action, such as selecting a button. The browser must then let you choose a tab, window, or screen, and it cannot save that approval for the next request.
That is a strong capture boundary, but it does not make a whole screen-sharing product private. Linkside still decides who can enter a room, how the browsers connect, what happens when a direct connection fails, and what remains after the session.
Four browser APIs divide that work into clear parts.
One screen share, four jobs
| Browser API | Its job in plain English | The boundary it creates |
|---|---|---|
getDisplayMedia | Opens the browser’s picker and returns the source you choose | A site cannot start capture without your action |
MediaStream | Holds the captured video and any available audio as tracks | Each captured source can be managed and stopped |
RTCPeerConnection | Sends media tracks between browsers | WebRTC encrypts media while it travels |
RTCDataChannel | Carries small application messages between browsers | App data stays separate from the screen video |
The first three make up the media path: capture, container, and connection. The Data Channel is a side path for small messages. In Linkside, it carries Live Overlay positions and in-session chat, not the screen video.
getDisplayMedia: the permission gate
navigator.mediaDevices.getDisplayMedia() is available only in a secure context, such as an HTTPS page, and it requires a fresh user action. Each call opens a browser-controlled choice. The page cannot silently reuse an earlier screen-capture grant.
In Linkside, selecting Start sharing calls getDisplayMedia({ video: true, audio: true }). A successful request returns one video track. It can also return an audio track when audio is available for the selected source. Requesting audio does not guarantee that the browser will provide it.
Linkside listens for the ended event on every track the browser returns. If the current capture ends, Linkside clears that Display Stream and stops any tracks still running. The browser’s own stop control and Linkside’s Stop sharing control therefore reach the same cleanup path.
The picker controls what capture may begin; Linkside’s cleanup controls what happens after it ends. For a closer look at that permission, read what screen-sharing permission grants.
MediaStream: the track container
A MediaStream is a container. Its MediaStreamTrack objects are the individual video and audio sources inside it. Removing the stream from Linkside’s interface would not be enough; the captured tracks themselves need to be stopped.
Linkside keeps the Host’s Display Stream separate from the microphone stream because they have different lifecycles. It adds the Display Stream tracks to each Guest connection and adds the microphone separately when it is active. On the Guest side, Linkside ignores duplicate track IDs and assembles the arriving tracks into one stable Remote Stream for playback.
This is why cleanup happens track by track. When a Host stops sharing, Linkside calls stop() on every captured track rather than merely hiding the preview.
RTCPeerConnection: the transport engine
RTCPeerConnection represents a WebRTC connection between two browsers. addTrack() makes a local media track available to send. The other browser receives a track event when the corresponding receiver is added.
Linkside creates one Peer Connection from the Host for each Guest, while each Guest keeps one connection to the Host. Linkside’s Signal Worker passes setup messages—offers, answers, and network candidates—between them. It manages the introduction and live room state, but it does not receive the Display Stream.
Linkside tries a direct browser-to-browser media path first. If restrictive networks block that path, it can fall back to an encrypted TURN relay. The WebRTC security rules prohibit plain RTP or RTCP media: implementations must use SRTP and SRTCP and support DTLS-SRTP. The relay forwards encrypted packets but does not hold the keys needed to decrypt the screen or audio.
Encryption protects the media in transit. It is not a promise about what an admitted Guest may do on their own device. For the complete setup sequence, read how peer-to-peer screen sharing works, or start with what WebRTC means for screen sharing.
RTCDataChannel: the lightweight side path
RTCDataChannel exchanges application data in both directions over a Peer Connection. A channel can require messages to arrive in order or limit how often a missing message is retried.
Linkside creates two Data Channels for each Peer Connection:
- Live Overlay positions use
{ ordered: false, maxRetransmits: 0 }. If one update is lost, Linkside does not retry it. - Chat uses
{ ordered: true }. The Host assigns each message a sequence number before sending it to the room.
Neither channel becomes persistent history. Linkside does not retain chat after the room ends.
The support contract is narrower than API availability
Linkside does not treat an API name as a support promise. Its runtime check combines RTCPeerConnection, mediaDevices, getDisplayMedia, secure-context state, mobile detection, and browser family.
| Browser | Hosting a Linkside room | Joining as a Guest | Linkside guidance |
|---|---|---|---|
| Chrome on desktop | Supported when getDisplayMedia is available | Supported when RTCPeerConnection is present | Recommended for Hosts |
| Edge on desktop | Supported when getDisplayMedia is available | Supported when RTCPeerConnection is present | Recommended for Hosts |
| Firefox on desktop | Limited when capture is available | Supported when RTCPeerConnection is present | Prefer Chrome or Edge for hosting |
| Safari on desktop | Limited when capture is available | Supported when RTCPeerConnection is present | Prefer Chrome or Edge for hosting |
| Other Chromium desktop browsers | Capability-dependent | Supported when RTCPeerConnection is present | Likely compatible, but not a tested path |
| Mobile and iPad browsers | Not supported | Requires RTCPeerConnection and mediaDevices | Guest-only |
| In-app browsers | Not supported | Not supported | Open the link in a full browser |
This is Linkside’s product policy, not a browser-industry compatibility table. Desktop Chrome and Edge are the recommended Host path. Firefox and Safari hosting remains limited, other Chromium browsers are untested, and mobile stays Guest-only when its runtime checks pass.
What the browser does not decide
Linkside can host and join rooms without an installer, extension, or plugin because the browser supplies these APIs. The application still has to make the product decisions around them.
Those choices are explicit: media is peer-to-peer first, TURN is an encrypted fallback, sessions are not recorded, chat is not retained, and rooms disappear after the session. Linkside also requires no account.
Some operational information still exists while a session is live. The Signal Worker can observe that a room exists, the rough timing of Guest joins, and the session duration. A TURN relay can observe the routing of encrypted packets. Neither receives the media content, and Linkside does not retain those observations long-term or pair them with an identity.
To judge a browser screen-sharing product, ask four concrete questions: who presents the capture picker, where the media travels, what happens when a direct connection fails, and what remains after the room ends. API availability alone does not answer them.
If Linkside’s division of responsibility fits your session, create a room.