Security

taiku encrypts your terminal traffic before it leaves your machine, so the server can coordinate the session and enforce access rules without being able to read what is in your terminals.

The server still runs the session and checks who is allowed in, but it never receives the key that unlocks your terminal stream and cannot read the terminal bytes flowing through it.

Session key

When you start a session, taiku generates a random session secret on your machine 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)

Normal page loads do not send URL fragments to the server, so the raw secret stays on the device that opened the link. That device reads the fragment locally and derives the same encryption key your machine used to start the session.

The encryption key is derived locally on every device — the host and each person who joins. The server only sees a derived check value it uses to confirm a device holds the right secret; it never receives the raw secret itself.

What is encrypted

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
• your keystrokes as a viewer
• 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 machine and participant devices 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

When you share a session with separate reader, writer, and admin access, each role gets its own standalone link with its own secret in the URL fragment.

Every role decrypts the same terminal stream — there is not a second encryption key. The difference is that each link carries a different secret, so holding the reader link does not reveal the writer or admin link. The role you connect with is what determines whether the server lets you type, or administer tunnels.

Control inside shared sessions

Write access to a session does not mean every participant can take over every terminal. Terminals have owners, and taiku checks control actions against that ownership boundary.

In normal collaboration:

• You can type into, resize, and close terminals you created.
• You can see and peek at other participants' terminals, but you cannot control their active terminals without an explicit handoff.
• Tunnel admins can control other users' terminals when administering the session.

Terminal labels and diagnostic IDs are not treated as permission by themselves. Commands that originate from inside a taiku shell are tied to that specific shell before they can affect session state. Agent status is also attached to the terminal where the agent is actually running, so one terminal cannot claim agent activity for another terminal.