Session relay decryption
How the browser can render live session plaintext without the relay or platform database storing the transcript.
The /sessions page can show plaintext because the browser becomes an active runtime endpoint for that live session. The plaintext is not read from a platform transcript table. It is streamed from the daemon over an encrypted relay channel and decrypted in the browser's memory.
That is a useful protection boundary, but it is not the same as daemon-only decryption. The browser can render the session, so the JavaScript running in the browser can see it.
Where the key comes from
The browser derives a fresh relay session key after it connects to a paired machine.
After the handshake, both endpoints have the same temporary symmetric key:
- the daemon keeps it in its relay session state
- the browser keeps it in JavaScript memory for the active connection
- the relay does not get the key
- the platform database does not store the key
What each token/key does
| Material | Where it lives | What it does |
|---|---|---|
| Relay token | Browser, relay | Authenticates routing to a runtime target. It is not the decrypt key. |
| Daemon public key | API/browser | Lets the browser start an authenticated handshake with the daemon. It is public. |
| Daemon private key | Local daemon | Lets the daemon complete the handshake. It should not leave the daemon machine. |
| Browser ECDH private keys | Browser memory | Used to derive the relay session key. Fresh per connection. |
| Relay session key | Browser memory + daemon memory | Encrypts/decrypts frames with AES-GCM for this relay session. |
How frames move
The relay can route frames because it sees envelope metadata such as workspace, runtime target, frame type, and connection state. It should not see payload plaintext.
The honest trust boundary
This protects against:
- relay operators reading frame payloads
- backend logs containing session frames
- database leaks exposing session transcripts
- a stale server-side transcript table existing by accident
This does not protect against:
- malicious hosted web JavaScript reading what it renders
- browser extensions that can inspect page content
- compromised user devices
- screenshots or local browser memory inspection
If you use the hosted web app, you are trusting the JavaScript delivered by Viewport for live session rendering. That is a narrower trust boundary than server-side plaintext storage, but it is still trust.
Stronger deployment options
For environments that need Viewport-the-service to be unable to read live session plaintext even through shipped web code, use or build toward one of these models:
| Model | What changes |
|---|---|
| Open-source runtime UI | The session decrypt/rendering code lives in the open-source viewport repo and can be audited or self-built. |
| Local daemon-served UI | The browser loads the session UI from localhost, not the hosted app. |
| Native desktop app | Session decrypt/render happens in a signed local app. |
| Self-hosted web app | The customer controls the deployed web bundle. |
| Signed/verifiable frontend bundles | Users can verify the hosted bundle matches reviewed source. |
The immediate priority is to move the session runtime UI and relay decryption client into the open-source viewport surface so the sensitive decrypt/render path is auditable outside the closed platform app.