# {{name}} on a company network A guide for IT and security teams. {{name}} runs in a web browser. Nothing to install. The presenter's laptop shows the slides. People answer on their phones. > **The short version.** Allow `https://{{domain}}` on port 443. That is all a > talk needs. WebSockets make it a little faster, and they are optional: where > they are blocked, everything works over plain HTTPS, by itself. Fonts, > videos and libraries from other sites matter only when a deck uses them. --- ## What to allow | What | Where | Needed? | | --- | --- | --- | | The app, the stage, the console, phones joining, the API | `https://{{domain}}`, port 443 | Yes | | Live updates over WebSockets | `wss://{{domain}}`, port 443 | No. Without them, HTTPS carries the room. | | Fonts a deck asks for | `fonts.googleapis.com`, `fonts.gstatic.com`, `fonts.bunny.net`, `api.fontshare.com`, `cdn.fontshare.com`, `use.typekit.net` | Only if a deck uses them. Blocked, the deck shows its own fonts. | | Videos and pages a deck shows | That site: YouTube, Vimeo and so on | Only for those slides. | | Libraries a coded deck loads from elsewhere | That deck's CDN, such as `cdn.jsdelivr.net` | Only for that deck. The library kit (three.js, GSAP and more) comes from {{domain}} itself. | | Going live online, and a phone as the presenter's camera | Video calls (WebRTC) over UDP, helped by `stun.cloudflare.com` and `turn.cloudflare.com` (on port 443 too, where UDP is blocked) | Only for those two. The talk itself needs neither. | Nothing else. No other ports, no extension, no plugin. Only the two video calls above use UDP. Phones join at `https://{{domain}}/CODE`, with the code on the screen. On your Wi-Fi they need the first row too. --- ## WebSockets are optional {{name}} likes a WebSocket: one connection, kept open, the quickest way to keep a room in step. Many company networks refuse them, or break them. Nothing needs setting up for that. - **The stage and the console** try a WebSocket and plain HTTPS side by side, and keep whichever works. Where WebSockets are refused, they are ready in a second or two. If a working one drops, HTTPS carries on without a gap. - **Phones** try a WebSocket first. If it fails, or sits open in silence for six seconds, they move to HTTPS. The person holding the phone sees nothing. - On HTTPS, a WebSocket is tried again now and then, less often each time, up to every five minutes. A try that fails changes nothing on screen. Over HTTPS, each screen keeps one request open, and the room answers it as soon as something happens, or after 25 seconds. So a proxy should let a response take 30 seconds. Most allow far longer. Everything works over HTTPS: slides, coded and 3D slides, clicks, live results, reactions, the console, and cues between the phones and the stage. --- ## HTTPS only For a network that must not see a WebSocket at all, the presenter can make the stage and the console use HTTPS only. They never try one. - **For every talk:** Settings, **The big screen**, **HTTPS only, never a WebSocket**. - **For one deck:** the editor, **Room**, **The big screen**. - **For one screen:** add `?safe` to the stage link, or use the HTTPS only link from the console (**More**, **Open on a second screen**). It looks like `https://{{domain}}/stage/safe/SESSION`. Phones still try a WebSocket first. Most are on mobile data, not your network. On a network that refuses it, they move to HTTPS in seconds. --- ## Showing it inside your intranet The big screen can sit inside a page on your own site: an intranet, a screen in the lobby, a meeting room display. 1. The presenter names your site in Settings, under **Sites that may show your big screen inside their pages**: `https://intranet.example.com`, or `https://*.example.com` for all of its subdomains. HTTPS only, up to ten. 2. Your page shows the HTTPS only link for a second screen in an iframe. It needs no sign in. It follows the talk and can never change it. A site that is not named cannot show it. The browser refuses. --- ## What runs on the laptop - Every page runs only {{name}}'s own scripts. Each page has a strict Content Security Policy: no inline script, no eval. - Presenters can write slides in code: 3D, animation, games. That code runs in a sandboxed frame with no origin of its own. It cannot read the sign in, call {{name}} as the presenter, touch the page around it, open windows, download files, or use the camera, the microphone or the location. - The big screen asks for no permissions. If the presenter shows their own camera on the slides, the browser asks them first, as for any video call. Nothing is installed. --- ## What people share - Joining needs no app and no account. A name only if the presenter asks. - An answer goes to that presenter's room, and nowhere else. - Phone screens written in code run sealed: they can send nothing anywhere but the room, and the room refuses card numbers. - Bad words wait for the presenter's OK, and so does every photo and voice note. - No ads, no tracking cookies, no analytics. Nobody's answers train AI models. - An audience member's IP address is not kept with their answers. --- ## Accounts and keys - Passwords are kept only as salted hashes (PBKDF2). - The sign in cookie is HttpOnly, Secure and SameSite=Lax. Wrong passwords typed somewhere else never lock a presenter out. - Keys for AI agents are kept only as hashes. A presenter can withdraw one at any time. - Only the presenter can change where their big screen may be shown, or turn on HTTPS only for their account. A key cannot. --- ## Where data lives {{name}} runs on Cloudflare: the site, the database, the files and the live rooms. Everything travels over HTTPS. Request logs are kept for a short time, then deleted. A deck deleted for good takes its sessions, answers, photos and voice notes with it. The [privacy page](/privacy/) has the rest. --- ## Check it from your network 1. Open `https://{{domain}}/api/health`. It answers `{"ok":true, ...}`. 2. Open a stage and press **?**. The last line says how it is connected: over a WebSocket, or over HTTPS. 3. Join from a phone on your Wi-Fi, with the code on the screen. --- ## Questions ### Does {{name}} need WebSockets? No. The stage, the console and phones all work over plain HTTPS. They use a WebSocket only where your network allows one, and never when the presenter chooses HTTPS only. ### Which sites must we allow for {{name}}? Only `https://{{domain}}`, on port 443. Font services, video sites and CDNs matter only for decks that use them. ### Can a presenter's slides run code on our laptops? Only inside a sandboxed frame with no origin of its own. That code cannot read cookies or the sign in, call {{name}} as the presenter, open windows, download files, or use the camera, the microphone or the location. ### Can we show {{name}} inside our intranet? Yes. The presenter names your site in Settings, and your page shows the view-only HTTPS only link in an iframe. Sites that are not named cannot. ### Does {{name}} work behind a proxy that inspects TLS? Yes. It is ordinary HTTPS, and nothing pins certificates. The proxy should let a response take 30 seconds. ### What does the audience share? Only what they choose to answer, and a name if the presenter asks. No account, no app, no tracking cookies, and their IP address is not kept with their answers. ### Who do we talk to about security? Write to hello@{{domain}}. We answer.