Security model / July 2026
What leaves your Mac.
Portal keeps local terminal sessions local. Remote access is opt-in, outbound-only, and end-to-end encrypted before terminal data reaches the relay.
01 / Network boundaries
Three paths. Three boundaries.
- Local sessionPortal → private Unix socket → session daemonNever leaves the Mac
- Mac ↔ iPhoneDevice → encrypted envelope → Portal relay → deviceLeaves the local network
- SSH hostPortal → system SSH client → configured hostFollows the host’s network route
A normal local session uses a per-user Unix domain socket with owner-only permissions. Portal opens no TCP port and advertises no terminal service on your LAN.
When remote access is enabled, the Mac opens an outbound secure WebSocket to Portal’s relay and uploads an encrypted session catalog over HTTPS. The iPhone uses the same relay. This happens even when both devices are on the same Wi-Fi: Portal does not attempt local peer-to-peer routing.
Separately, a configured SSH session uses macOS's system SSH client and its existing host-key and key-agent trust. That traffic reaches the host directly; it is not sent through Portal’s relay.
02 / Keys and encryption
The relay delivers ciphertext.
Portal creates a random 256-bit account root key on-device and stores it as a synchronizable iCloud Keychain item. Devices signed into the same Apple account use that shared key to derive separate keys and opaque identifiers for relay routing, relay authorization, live terminal traffic, and the session catalog.
Terminal messages and catalog snapshots are sealed with AES-256-GCM and purpose-bound authenticated data before upload. TLS protects the connection in transit as an additional layer, but the relay never receives the encryption key or plaintext terminal contents.
03 / Relay knowledge
What the service can—and cannot—see.
The relay can see
- Connection addresses, timing, and message sizes
- An opaque room identifier and the number of live peers
- An encrypted session-catalog blob
The relay cannot see
- Commands, keystrokes, output, paths, or session names
- The account root key or purpose-derived encryption keys
- Data needed to forge a new authenticated command
The relay has two storage classes, and neither contains plaintext:
- Temporary / memory only
- Each encrypted terminal frame exists only long enough to be broadcast to the other connected peers. Peer identifiers exist while their sockets are connected; opaque room and authorization state may remain until the relay process restarts.
- Durable / stored on disk
- One encrypted session-catalog blob per opaque room. Each update atomically replaces the previous blob—there is no catalog history. A blob inactive for 30 days is deleted on its next read; production billing cleanup may delete it sooner after a subscription expires.
- Never stored by the relay
- Plaintext commands, keystrokes, output, paths, session names, the account root key, and derived encryption keys. The relay implementation does not persist or log live terminal frames.
Portal defines no permanent relay record: the catalog is retained only for device discovery and is subject to deletion. Hosting and network providers may keep ordinary connection metadata under their own operational policies; that metadata is outside Portal’s end-to-end encryption boundary.
04 / Control and failure modes
Encryption is not availability.
A compromised relay can delay, drop, duplicate, reorder, or replay ciphertext and can deny service. Sequence numbers are inside the authenticated message; clients reject duplicate or stale terminal events and reconnect for a fresh canonical snapshot after a gap.
The Mac initiates every relay connection, so the service cannot open an inbound connection to it. Phone-role clients may send terminal input but cannot change PTY geometry. On iPhone, attaching to a session requires device-owner authentication.
05 / Trust and limitations
The honest boundary.
- A device that can read the synchronized root key can control Macs on which remote access is enabled. Apple-account recovery and device security are therefore part of Portal’s trust boundary.
- The current model has no per-device revocation, emergency account-wide kill switch, or forward secrecy after a later root key compromise. End affected sessions from a trusted Mac if a device is lost.
- Traffic analysis and denial of service are not prevented. Subscription checks authorize access but are not a cryptographic trust root.
- Commands and completion generators run as the signed-in user on the host Mac. Portal encrypts their transport; it does not sandbox them or prevent those processes from using the network.