Security

How taiku protects terminal traffic, what the server can see, and what access links actually grant.

Taiku encrypts terminal traffic between the host CLI and connected browsers before that terminal content crosses the network. The server still coordinates the session and enforces access rules, but it does not receive the raw terminal key and cannot read terminal bytes from the encrypted stream.

Session key

When you start a session, the CLI generates a random session secret and embeds it in the URL fragment, the part after #:

Session URL: https://taiku.live/s/abc123#e8Xk9mBzQ2pR4w
                                        ^^^^^^^^^^^^^^
                                        session secret (not sent as part of the HTTP request)

Browsers do not send URL fragments in normal HTTP requests, so the raw secret is kept client-side. The browser reads the fragment locally and derives the same encryption key as the CLI.

Taiku derives the session encryption key locally in both the CLI and the browser. The server only sees a derived verifier used to check that a client has the right secret; it does not receive the raw fragment itself.

What is encrypted

Data	Encrypted?	Notes
Terminal output	Yes	Shell stdout/stderr is encrypted before the CLI sends it.
Terminal snapshots / replay	Yes	Buffered terminal history is replayed over the same encrypted stream.
Keyboard input	Yes	Browser keystrokes are encrypted before being sent back to the host.
User names / presence	No	Needed for collaboration and presence UI.
Focus state	No	Used to show which shell each participant is looking at.
Chat messages	No	Chat is coordinated server-side and is not covered by the terminal encryption scheme.
Shell dimensions	No	Rows and columns are sent in plaintext for terminal coordination.
Device/category metadata	No	Used for connection tracking and UI labels.
Window layout	Mostly browser-local	Per-user layout is persisted in the browser, but compact layout metadata is also broadcast to other participants for workspace and peek views.

The important boundary is this: terminal bytes are encrypted; collaboration and session-coordination metadata is not.

What the server sees

The server can observe:

that a session exists
the session ID and participant count
the coordination metadata listed above
encrypted payload sizes and timing
the derived verifier values used for session-key and write/admin checks
whether viewer OAuth is required for the session

The server cannot directly read:

terminal output
browser keystrokes
the raw session secret in the URL fragment

The trust model

Taiku's terminal privacy model is "server can coordinate, but should not be able to read terminal content." The main assumptions are:

the server honestly relays encrypted terminal traffic and enforces access rules
the host CLI and participant browsers are trusted endpoints
the session URL fragment stays private to authorized participants

This helps against server-side inspection, routine server logging of terminal content, and passive network observation beyond normal TLS.

It does not help against:

compromised host or viewer devices
leaked full URLs
traffic analysis based on timing or volume
plaintext metadata leakage for chat, presence, sizing, and similar coordination messages

Write access separation

--enable-readers does not create a second terminal-encryption key. Instead it adds a second secret for elevated access.

read-only URL: #sessionSecret
write URL: #sessionSecret,writePassword
tunnel-admin URL: #sessionSecret,adminPassword

Everyone with any of those URLs can decrypt the same terminal stream because the session secret is shared. The extra password controls whether the server allows that client to send input or administer tunnels.