If your work laptop refuses to run a screen-sharing app, you have learned one useful thing: the installed application is blocked. You have not yet learned whether your company also blocks browser capture, Linkside’s web services, or the media connection.
Linkside removes the installer from the equation. It runs in the browser with no download, extension, or plugin. It cannot override a blocked destination, a managed browser setting, or a network rule. The practical next step is to find the exact point where sharing stops.
First, identify what your company blocked
“Blocked by work” can mean four different things. Test them separately.
| Control | Boundary to test | What Linkside changes |
|---|---|---|
| Application allowlist | Whether an installed executable may run | Uses the existing browser |
| URL or domain policy | Access to the app and its separate signaling service | Both destinations still need access |
| Browser capture policy | Whether the browser may request display capture | The managed browser policy still applies |
| Network media policy | Whether WebRTC can establish a usable media path | Tries direct first, then an encrypted relay |
On Windows, App Control for Business and AppLocker control which applications may run. If that is the only restriction, opening Linkside in an approved browser avoids adding another executable. Microsoft Intune can deploy App Control policies, but that finding still does not test the browser or network rules below.
Browser delivery is not a general escape hatch. A managed browser can use a
URLBlocklist
to prevent a destination from loading. An administrator can also disable web screen
capture with a policy such as Edge’s
ScreenCaptureAllowed.
Neither rule disappears when you change from an installed app to a browser tab.
What a corporate firewall can still block
Encryption protects data while it travels. It does not give that traffic permission to cross a company network. TLS 1.3, for example, uses authenticated encryption for application data, but a network policy can still block the destination.
For example, a DNS filtering policy can allow or block domain queries. If it blocks a required Linkside domain, that connection cannot start. A browser URL policy can stop the page even earlier.
A Linkside session has three network stages with different jobs:
- The app loads from
linkside.io. - Room creation, joining, and session events use
signal.linkside.io. - The media connection first tries a direct browser-to-browser WebRTC route. If that fails, it can use an encrypted TURN relay.
Loading the app proves only that the first stage worked. If the signaling service is blocked, the room cannot start. If neither the direct route nor the relay is available, the stream cannot connect. Our network test guide explains the Direct peer-to-peer and Relayed through server labels shown in Linkside.
Try a browser screen share at work
Use this sequence to locate the failed boundary. It does not require an install or attempt to work around an explicit policy.
- Use desktop Chrome or Edge. Those are Linkside’s recommended host browsers.
- Load the create page. Open Linkside’s create-room page. If it is blocked, record the URL and policy message. You now know the problem occurs before room creation or media setup.
- Create the room. This step contacts
signal.linkside.io. If the app loaded but room creation failed, save the error and ask IT whether the signaling destination is approved. - Start sharing. Linkside calls the browser’s display-capture API. The
screen-capture standard requires the
browser to ask you to choose what to share each time; permission cannot be saved
as permanently granted. If capture does not start, note whether you dismissed
the picker and record the exact browser message. On managed Edge, ask whether
ScreenCaptureAllowedis disabled. Our browser-permissions guide explains the permission in detail. - Have the viewer open the room link. Joining Linkside requires no account or download. If capture started but the stream did not connect, open Connection details, choose Show advanced diagnostics, and then Copy diagnostics. The copied report includes connection states, transport types, browser details, and the signaling URL. Review it before giving it to IT.
Do not switch to a personal hotspot or another service to defeat a stated company rule. A useful test establishes where the failure occurs; it does not grant permission to send work material through an unapproved tool.
What we built Linkside to remove
We built Linkside in the browser so a quick screen share does not begin with an installer, an extension request, or a signup. The host creates a room, sends a link, and starts capture through the browser’s own picker. For the shorter walkthrough, see how to share without installing anything.
After capture starts, Linkside prefers a direct browser-to-browser WebRTC connection. When that route fails, the host client in an eligible free room automatically requests one five-minute trial of the encrypted TURN relay. A licence removes that relay time limit. The relay changes the media route; it does not change the browser’s capture permission or the company’s domain policy. Media remains encrypted in transit on either route, as our WebRTC encryption explainer details.
Linkside does not record sessions, keep chat history, or preserve rooms after their session lifecycle ends. Operating the service still exposes limited connection information: signaling observes that a room exists, approximate guest-join timing, and session duration. A relay sees the routing of encrypted packets, and the network edge operated by Cloudflare sees IP-level traffic. They do not see the media content. We do not retain those observations long term or pair them with an identity.
That boundary limits what Linkside retains. It does not exempt Linkside from your employer’s rules.
When browser-only is the right answer
Browser sharing is a good fit when the blocked step is running a separate application and your company permits Linkside’s app, signaling, capture, and media connections. In that case, “nothing to install” removes the failed step.
Browser-only will not help when the company explicitly bans unapproved screen-sharing services, blocks Linkside’s web destinations, disables browser screen capture, or denies every usable direct and relay network path. Ask IT for an approved option rather than treating the browser as a loophole.
Browser delivery removes an executable from the path; it does not confer approval. If any later boundary is blocked, record the URL, policy message, or connection diagnostics and ask IT for the approved route.