“Is it encrypted?” is the right question, but it is rarely the only one. For a browser-based screen share like Linkside, the short answer is yes: the media stream between browsers is encrypted in transit by WebRTC. That encryption is required by the standard. Linkside does not add a switch to disable it.
The more useful answer is about the boundary. WebRTC protects the media path between browsers. It does not make the viewer’s device trustworthy, stop someone from recording what they can see, or remove every trust decision from the service that helps the browsers connect.
What gets encrypted, and how
WebRTC is the browser API for real-time audio, video, screen capture, and peer-to-peer connections. For media, the WebRTC security architecture requires DTLS-SRTP:
- DTLS handles the handshake between the two browsers and establishes keying material.
- SRTP uses keys derived from that DTLS handshake to encrypt the media packets: audio, video, and screen share.
For a screen share, that has three practical consequences:
- Cleartext media is not an option. A compliant browser will not negotiate an unencrypted WebRTC media session.
- The page does not get the media keys. JavaScript uses
RTCPeerConnection; the browser handles DTLS, SRTP, and the media encryption keys. - This is transit encryption. It protects media packets after the browser starts sending them and before the other browser displays them. It does not encrypt the pixels while they are visible on your screen, or after they are decoded in the viewer’s browser.
Direct vs relayed: still encrypted either way
Linkside is peer-to-peer first. It tries to establish a direct browser-to-browser WebRTC path. When that works, encrypted packets flow from the host browser to the viewer browser without a Linkside media server in the middle.
Sometimes the direct path fails: restrictive networks, corporate firewalls, or double NAT can block it. In that case, Linkside can fall back to an encrypted TURN relay.
That relay does not become a third viewer. The DTLS-SRTP keys are negotiated between the two browsers, not with the relay. The relay forwards encrypted packets. It does not hold the SRTP keys and cannot read your screen content from the packets it forwards.
That is a strong property, but it is not the same as “no one in the network can observe anything.” A relay can still:
- Observe routing and traffic patterns.
- Drop, delay, or degrade packets.
- Know that a relay session exists and roughly how long it lasts.
What it should not be able to do is decrypt the media without breaking the browser-to-browser DTLS-SRTP protection.
Signaling: TLS, but a different threat model
Before the two browsers can exchange media, they have to find each other. They do that by exchanging setup messages: SDP offers and answers, plus ICE candidates. Linkside sends those messages through its signaling service.
The signaling channel uses WebSocket over TLS, the same security layer used by HTTPS. That protects the setup messages from passive eavesdropping on the network.
Signaling is not media encryption, though. DTLS-SRTP protects the media packets after the peers are connected. It does not make an actively hostile signaling service impossible. A compromised or malicious signaling service could:
- See connection metadata, such as which room exists and when a guest joins.
- Perform a man-in-the-middle attack by rewriting SDP fingerprints before they reach the other peer. Without a separate identity or fingerprint verification step, the peers may not detect that swap.
RFC 8826 discusses this threat model directly. WebRTC is designed to protect the media path from passive network eavesdropping. It does not remove the need to trust the service that introduces the peers to each other.
For Linkside, the signaling service handles room creation, joins, and setup-message relay. It does not receive or process media frames. That is an important product boundary, but it is a product boundary, not an extra cryptographic guarantee.
What encryption doesn’t cover
Transport encryption answers one question: can someone on the network read the media packets? It does not answer every privacy question around a screen share.
- The viewer’s device. Once the media arrives and is decrypted for display, it is visible in the viewer’s browser. The viewer can record the screen, take a screenshot, or film the monitor with another device.
- The host’s device. Anything that can already read your screen, such as malware or another screen-sharing tool, can see what you are capturing before WebRTC sends it.
- The browser itself. WebRTC trusts the browser. If the browser process or a powerful extension is compromised, transport encryption between browsers cannot fix that.
- The other person. They can take notes, repeat what they saw, or remember it. Encryption does not change their incentives or judgment.
The plain-English version: DTLS-SRTP protects the network path. The endpoints are still endpoints.
How Linkside relies on the standard
Linkside does not roll its own crypto. It uses the browser’s standard RTCPeerConnection API. The encryption choices, key handling, and protocol details come from the browser implementation, following the W3C WebRTC spec and the IETF RFCs above.
For a Linkside session, that means:
- Linkside’s media encryption is WebRTC’s media encryption, not a separate Linkside crypto scheme.
- There is no “encryption setting” because there is nothing useful to turn on. DTLS-SRTP is already required for WebRTC media.
- Linkside is peer-to-peer first. If the direct path fails, media can use an encrypted TURN relay fallback. In both cases, the media remains encrypted in transit.
- Linkside does not record sessions. Rooms are temporary, and there are no persistent chat logs or media-content logs.
- The signaling service observes operational metadata such as room existence, rough join timing, and session duration. A TURN relay observes the routing of encrypted packets. Neither sees the media content.
What “end-to-end” really means here
Different products use “end-to-end encryption” to mean different things. For a browser screen share, the useful definition is narrow: media is encrypted from the host browser to the viewer browser, with keys that the signaling service and any TURN relay do not receive.
That is what WebRTC gives you, and it is what Linkside relies on. It does not mean the viewer cannot see what you share. That is the point of sharing. It does not mean their device is clean, or that privacy is automatic. It means the media is protected on the network path, with the endpoint limits above.
If that fits your use case, open a room and try it. If you need protection against the viewer, their device, or a fully hostile signaling provider, you need more than a browser tab can promise.