No downloads, extensions, or plugins is a useful promise. It is not a complete trust argument. You still need to know when screen capture starts, where the stream travels, what the service can observe, and what remains after the session.
Linkside has a deliberately narrow browser-native model: create a room in a supported desktop browser, send one link, and let a guest join without installing Linkside or creating an account.
What “nothing to install” means
Both host and guest use the web app. There is no Linkside desktop application, extension, plugin, or native helper to install before a room starts. The invitation and the session use the same room link.
That removes product setup, not user choice. It also does not make every browser or device equally capable. Linkside relies on the screen-capture and real-time connection features available in the browser at that moment.
The distinction matters: delivery, capture permission, media routing, identity, and retention are separate parts of the trust boundary. A “no download” label answers only the first one.
You choose when and what to share
Opening a Linkside room does not start screen capture. The host must select Start sharing. The browser then presents its own picker for a tab, window, or screen.
This is more than a Linkside interface choice. The Screen Capture specification requires a new user action and a new browser-controlled source choice for every capture request. A site cannot save a granted screen-capture permission and silently reuse it later.
Once the host chooses a source, Linkside passes that stream to a separate peer connection for each guest. It also listens for the browser to end the selected track, so stopping the share from the browser stops that source in Linkside too.
Peer-to-peer first, with an encrypted fallback
The room link does not describe the media route. Linkside first attempts a direct browser-to-browser WebRTC connection. Its signaling service helps the browsers find and negotiate with each other, but it does not receive the screen stream.
Some network conditions prevent a direct connection. In that case, the host can use an encrypted TURN relay. After a connection failure, an eligible free room automatically requests a five-minute relay trial; a license enables unlimited relay use. The relay forwards encrypted packets and does not hold the keys needed to read the screen or audio.
There is still operational information around a session. The signaling service can observe that a room exists, the rough timing of guest joins, and its duration. The relay and its edge network can observe IP-level traffic while forwarding encrypted packets. Linkside does not pair those observations with a product identity or retain them long-term.
Linkside does not record sessions, transcribe audio, analyse screen contents, or keep chat history. Those are product decisions; they do not follow automatically from running in a browser.
No account, no saved workspace
Neither host nor guest needs an account. Linkside does not require a real name, email address, or phone number to create or join a room. A guest keeps or changes a generated room nickname and joins without a signup wall, captcha, or email gate. A licensed host can require a room password, and the optional waiting room holds a guest for host approval. Neither creates an account.
The room is temporary. When the host ends the session, it cannot be reopened as a saved collaboration space. Behind the scenes, the signaling service briefly keeps an “ended” marker so a late request gets a clear terminal response. It then deletes the room record. There is no recording or session-content archive attached to it.
Browser-native does not mean every browser
Linkside checks the browser’s capabilities before deciding which role it can support. The current support boundary is straightforward:
- Desktop Chrome and Edge are the recommended way to host.
- Desktop Firefox and Safari can host with limitations.
- Supported mobile browsers can join as guests but cannot host.
- In-app browsers cannot host or join; open the link in a supported browser instead.
A desktop browser may be able to receive a WebRTC screen stream without offering the screen-capture feature needed to host. Linkside can let that browser join as a guest, but it does not install an add-on to turn it into a host.
That is the honest case for a browser-native tool: fewer setup steps and a clear handoff, within a stated support boundary. Before trusting one, ask who starts capture, whether media goes direct or through a relay, what that relay can see, and what the service keeps afterward.
Create a temporary room when you need to show your screen to a few people you trust.