Latenz

Security model

Latenz gives someone a live view of — and input into — a real desktop. That only works if the security model is explicit. This page describes exactly what is encrypted, who holds which keys, what our servers can and cannot see, and how access is granted and revoked. Where a guarantee has a caveat, the caveat is stated.

Media is encrypted peer-to-peer

Every session is a standard WebRTC connection between the host agent and the viewer. The two peers run a DTLS handshake directly with each other and derive the media keys from it; video and audio travel as SRTP, and keyboard/mouse/gamepad input and file transfer travel over a DataChannel inside the same DTLS session. The Latenz cloud is not a party to that handshake and never holds the media keys.

host ── DTLS handshake, SRTP media, DataChannel ──► viewer
          (keys exist only at the two endpoints)

platform: auth + host registry + SDP/ICE signaling only

The honest caveat that applies to all WebRTC systems: the peers verify each other by certificate fingerprints exchanged through the signaling channel, so you are trusting the signaling server to relay those fingerprints faithfully. Signaling runs over TLS (WSS), and the platform relays SDP between authenticated parties without rewriting fingerprints. What the platform cannot do, by construction, is decrypt media after setup — the keys were never sent to it.

There is no relay running right now

No TURN relay is currently deployed. Every session is therefore direct or it does not happen: on a network that blocks the direct path — a corporate firewall, a hotel, some mobile carriers — the connection fails rather than falling back. Nothing about relay bandwidth is metered or billed while this is the case.

When a relay is running again, this is what it can and cannot do, and it does not change: TURN forwards already-encrypted SRTP/DTLS packets, so it terminates no encryption and holds no keys. It learns IP addresses and byte counts — never content. Relay credentials are ephemeral: short-TTL, HMAC-derived per session, useless once expired.

The host never listens

The host agent opens a single outbound TLS WebSocket to the platform and waits. No inbound ports, no port-forwarding, no UPnP, nothing for an internet scanner to find. Sessions are established by the platform telling the host — over that authenticated channel — that an authorized viewer wants to connect; the host then negotiates WebRTC outward.

Access control

  • Accounts authenticate with Firebase Authentication; the platform verifies Firebase ID tokens on every request.
  • Hosts authenticate with per-host tokens minted at enrollment. Tokens are individually revocable from the dashboard; a revoked host is cut off at the next message.
  • Only the owner connects.A host is bound to the account that enrolled it. There is no lateral path from one account's viewer to another account's host.
  • Guest links are deliberately narrow bearer tokens: one host, view-only or co-op (input) mode fixed at mint time, optionally pinned to specific monitors, with optional expiry and use limits, and revocable at any time. A view-only link is enforced on the host side — input from a view-only guest is dropped by the agent itself, not just hidden in the UI.

What our servers store

Because media never terminates on our infrastructure, there is no screen content, audio, keystroke or clipboard data to store — at rest we hold account records, host metadata (name, hardware/codec capabilities, last-seen), a session audit log (who connected to which host, when, and as what — owner or guest link), and relay byte counters for as long as a relay exists to count. The full inventory is in the privacy policy.

Abuse resistance

  • Rate limiting on authentication, enrollment and guest-link endpoints.
  • Enrollment keys are single-use and expire: each one enrolls exactly one host, then is dead.
  • Paid-plan gates (multi-monitor, concurrent sessions, file transfer) are enforced server-side and on the host agent — not in client UI.

Reporting a vulnerability

If you believe you've found a security issue, email [email protected]. Include steps to reproduce; we'll acknowledge within 72 hours. Please don't access data that isn't yours or degrade the service while testing — good-faith research reported this way will not be met with legal action.