QuickDesk’s security rests on one principle: the relay is untrusted. The relay moves bytes between two clients. It can drop or delay a session, but it cannot read or forge one. Confidentiality and peer authentication stay in the clients, not in the transport. All rules below follow from this design.

​
The two encryption layers

1

Hop security — transport TLS

Each client’s QUIC connection to its edge PoP is TLS-encrypted. This protects the link to the relay. The relay terminates that TLS to route bytes. If this were the only layer, the relay could see plaintext. So it is not the only layer.
2

End-to-end security — the client handshake

Over the relayed byte pipe, the two clients run their own public-key handshake. They authenticate each other and derive a session key that the relay never learns. The clients then seal all input, framebuffer, audio, and file-transfer messages with authenticated encryption under that key.
A hostile or compromised relay sees only ciphertext and connection metadata. It cannot inject keystrokes, read the screen, or change a file transfer without a broken authentication tag. The receiving client rejects a broken tag.

​
Credential handling

  • No stored passwords. Your identity provider handles sign-in. After login, the client holds a short-lived bearer token plus a device id. It never holds your account password.
  • Local files are locked down. The client writes the session token and device identity with owner-only file permissions.
  • Device gate. The account server binds a token to a device id, so a stolen token alone does not silently enrol a new machine.

​
Session permissions

The box client enforces what a controller may do, not the relay: The endpoint enforces these permissions. Thus a relay that reorders or replays frames cannot escalate what a session is allowed to do.

​
Audit trail

The account server records session events for compliance and review:
  • Connection audit — session open/close events keyed by session id: who connected to which device, and for how long.
  • File-transfer audit — direction, file names, and sizes for each transfer. The file bytes travel peer-to-peer. The clients never upload the bytes to the audit store. The server logs only the metadata.
Audit writes are loss-tolerant. The client does not block a session on them. If a record is dropped, the server does not fail the session.

​
Session recording

Recording is optional and server-side. When you enable recording, the session video is uploaded in chunks to your object storage. The video is then finalised into a single file. In the operator console, you play back recordings through expiring links. The recording store is thus never publicly listable.

​
Self-hosted posture

When you run the account server and relay yourself (see Self-host), identity, address book, audit, and recordings stay entirely on your infrastructure. The end-to-end encryption model is identical in both cases. Self-hosting changes where the metadata and recordings live. It does not change who can read a session. Only the two peers can read a session.