Skip to content

Security and privacy

AnyTTY’s central security rule is that the daemon is the final authority for terminals, files, history, device identity, and client access. A route controls reachability but cannot expand a daemon-issued grant.

Responsibility boundary

Component Responsible for Does not control
daemon processes, history, file policy, identity, grants, authorization Cloud account, plans, public routing capacity
client its endpoint and credential material, daemon verification, user requests granting another client or changing local OS permissions
route Local, SSH, Direct, or Cloud reachability bypassing identity, authentication, or grants
Cloud registration, discovery, P2P/Relay, usage, subscription automatic app pairing or terminal/file permission
Relay forwarding protected traffic terminal/file authority
Trust boundary diagram separating client reachability from endpoint daemon authorization
Routes establish reachability; the endpoint daemon remains the authorization authority.

Identity and transport protection

Remote routes verify daemon identity and protect terminal and file traffic in transit. SSH routes should also pin and verify the SSH host key. Direct and Cloud use the paired client credential and daemon identity.

Identity, authentication, and authorization failures must be rejected. Fallback may select another configured trusted route, but cannot skip a pin or weaken verification.

The public security boundary promises encryption in transit. This documentation does not broaden that promise into unverified claims of anonymous, zero-knowledge, or universal end-to-end service properties.

Claims, grants, and revocation

  • A claim is short-lived, one-time secret material.
  • A grant is bound to a specific client identity.
  • A grant can be terminal-scoped and expire.
  • anytty access list inspects grants and anytty access revoke revokes one.
  • Removing endpoint metadata from a client does not revoke access on the daemon.

Use a short claim TTL and minimum grant scope. Revoke lost, retired, or unknown clients at every daemon they could access.

File permission

Terminal and file capabilities are separate. A file path must be covered by both grant and local daemon policy. Confirm endpoint and full path before recursive deletion, overwrite upload, or overwrite move.

Relay and metadata

Relay forwards protected traffic and receives no terminal/file authority. A hosted service may still process metadata needed to operate the connection, including account and device identifiers or labels, IP/network information, route diagnostics, timestamps, subscription, and usage.

Local, SSH, and Direct routes do not route terminal/file content through the hosted AnyTTY service. For Cloud data categories, purposes, sharing, and deletion rights, read the privacy policy.

Local data and credentials

  • Terminal history remains on the daemon machine and may contain commands, output, paths, and business data.
  • Clients store endpoint and credential material needed for their authorized access.
  • Mobile uses protected platform storage. iOS uses Keychain and Secure Enclave for SSH signing keys where available.
  • Logs, screenshots, issues, and fixtures must not include private keys, claims, grants, terminal/file content, or personal data.
  • Clipboard history may contain secrets and should have a bounded retention policy.

Security checklist

  1. Run the daemon as the current unprivileged user.
  2. Listen only on required addresses; do not expose Direct indiscriminately.
  3. Pin SSH host keys and retain daemon identity pins.
  4. Use short-lived claims and narrow, expiring grants.
  5. Review and revoke stale or unknown client access.
  6. Limit file paths and retain destructive-operation confirmation.
  7. Protect history, backups, logs, and diagnostics.
  8. Apply security updates and retest daemon and endpoint state.

Cloud account security

Cloud password, persistent sessions, daemon registrations, and daemon-local grants are separate controls. On suspected compromise, review all of them. Password changes stop other persistent credentials from renewing; already issued short-lived access can remain valid until its current lifetime ends.

Report a vulnerability

Do not open a public issue. Use GitHub private vulnerability reporting with the affected commit, prerequisites, minimal reproduction using fresh test credentials, impact, and known mitigation.

Never submit real keys, claims, grants, terminal/file content, personal data, or production service identifiers. AnyTTY is currently Beta and has no bug bounty or guaranteed response time.