Technology & formats
If the network loads a web page, it can probably show your slides.
Corporate and guest Wi-Fi are locked down on purpose — but they're built to let people browse the web. That one exception, ports 80 and 443, is exactly the lane a browser-based presentation tool needs.
5 min read
Jun 2026
Every claim sourced · 3 references
You arrive at a client site. Their Wi-Fi blocks Dropbox, throttles YouTube, and firewalls anything that looks unusual. Your instinct is that your wireless-presenting tool is dead on arrival. Usually, it isn't — because there's one thing every corporate network is designed to allow: loading web pages.
✕ The myth
"Locked-down networks will block my presentation tool."
If they firewall everything else, surely they'll firewall this too.
✓ The reality
They can't block the web without breaking the internet.
Web traffic rides port 443 (HTTPS) and port 80 (HTTP). Block those and nobody can reach anything — so they stay open, and a browser tool travels with them.
Ports 80 and 443 are the internet's registered lanes for web traffic.1 A presentation tool built in the browser does its signalling over a WebSocket — which is HTTP(S), i.e. those same ports — and when a direct peer-to-peer path is blocked, WebRTC falls back to a TURN relay that can run over TLS on 443, looking to the firewall like ordinary encrypted web traffic.2
Why this beats a custom app or a random port
Native apps often phone home on unusual ports that corporate firewalls quietly drop. A browser tool doesn't have that problem: it speaks the one dialect every network already trusts. WebRTC's ICE machinery tries the fastest direct route first, then gracefully degrades — direct P2P, then relay — so the connection finds a way through instead of failing outright.2
0
HTTPS — encrypted web traffic. The lane your signalling and TLS relay fallback can use.
1
0
HTTP — the other universally open web port.
1
ICE
WebRTC tries direct first, then relays — it degrades gracefully instead of dying.
2
⚖ The honest bit — "usually" is not "always"
Some networks really can stop you.
High-security environments can go further: deep packet inspection, TLS interception with a corporate proxy that mishandles WebSockets, or an explicit rule that blocks WebRTC and unknown TURN servers. Captive portals can also sit in the way until you authenticate. When a network is locked that hard, the honest fallback is the old one — an HDMI cable, or presenting from your own LTE instead of their Wi-Fi. A browser tool maximises your odds; it doesn't repeal a determined firewall.
Where SyncBy!App fits
SyncBy runs entirely in the browser and leans on ports 80/443 for signalling and its relay fallback, which is why it so often "just works" on networks that block everything else. And if you'd rather not touch their network at all, it works over your own phone hotspot too. We won't promise it defeats every corporate firewall — but it's built to take the path of least resistance every time.
TL;DR
- Ports 80/443 are the web's lanes; networks can't block them without breaking browsing.1
- A browser tool signals over WebSocket (HTTP/S) and can relay over TLS on 443 — indistinguishable from normal web traffic.2
- WebRTC's ICE tries direct first, then relay — it degrades gracefully.2
- Honest caveat: DPI, TLS interception or explicit WebRTC blocks can still win. Then: cable, or your own LTE.