What Poket PC's Relay Can and Cannot See
2026-09-26 · Godwin Agbane
When your iPhone and Mac are not on the same Wi-Fi, Poket PC connects them through a small service we call the relay. The relay’s job is narrow: bring two connections together that present the same random rendezvous token, then copy bytes in both directions without parsing them. This post explains that design in engineer-facing detail. The shorter consumer version lives on /security/.
Why a relay exists at all
Most home networks block inbound connections. You could open a port on the router, run a VPN, or park both devices on a mesh network—but each option adds setup, cost, or trust in a third party with broader network access than “forward this one encrypted stream.”
Poket PC instead tries local first: if the phone can reach the Mac on the LAN, they talk directly. If not, the phone dials out to the relay, where the Mac helper already keeps an outbound connection waiting for each paired phone. Outbound connections work on typical home and mobile networks without router changes.
The security goal is not “trust our relay with your desktop.” It is never give the relay the keys.
Rendezvous by random token
Neither device knows the other’s IP address in advance when you are on cellular or a different Wi-Fi. Pairing already established long-term identity keys on the phone and Mac. Away from home, the devices still need a way to find each other on the relay without publishing an address book.
The pattern:
- The Mac helper opens a connection to the relay and presents a random rendezvous token: 16 random bytes it minted when you paired that phone.
- The phone opens its own connection and presents the same token, which it received in the pairing QR code (not typed by the user).
- The relay matches the two connections that present equal tokens and splices them into a byte pipe.
The relay code path that forwards traffic does not import cryptography. Tests enforce that separation so a careless refactor cannot accidentally decrypt in the forwarder.
Matching is blind: the relay learns that two clients want to talk, their IP addresses, the token they share, and how much data moves and when, not what the data means.
What happens after the splice
Matching only creates a byte bridge between two WebSocket connections. The first bytes on that bridge are still a Noise IK handshake between the phone and Mac:
- They authenticate with the paired identity keys; the Mac admits only phones it has paired and not revoked.
- On the first handshake after you scan, the six-digit pairing code and the token are mixed into the handshake, so a wrong code fails at the first message. The relay sees the token but never the six digits, so it cannot pair itself in. Three wrong codes close the pairing window.
- They derive session keys with forward secrecy.
After the handshake, every frame is ChaCha20-Poly1305 with monotonic counters. Replay and tamper attempts fail at the endpoints, not at the relay.
So even a relay operator who actively manipulated the byte stream could not inject clicks or keystrokes without breaking authentication at the Mac or phone. They could only drop or delay traffic—a denial of service.
If the relay is compromised
Assume an attacker runs the relay software or sits on the relay host. Split what they gain from what they do not.
They can
- See metadata: when sessions start and end, source and destination IP addresses, the rendezvous token, packet sizes and timing patterns (traffic analysis).
- Refuse to match or drop connections, making remote access unavailable.
- Correlate that a particular phone and a particular Mac are talking at the same time, even if they cannot read the payload.
They cannot
- Decrypt screen video, keyboard events, or Ask task content. Keys never leave the endpoints.
- Forge input events that the Mac would accept. Forged records fail Poly1305 tags.
- Impersonate a revoked or never-paired phone past the Noise handshake.
This is the same trade most encrypted messengers make: content confidentiality and integrity at the ends, metadata visible to the infrastructure that carries the bits.
What we did not solve
Metadata is still sensitive. A global observer might learn that you use remote desktop from a phone IP to a home IP on weekday evenings. We do not claim metadata hiding or Tor-style anonymity.
Availability is not security. A relay outage feels like an attack to users even when no one read their screen. We design for failover between LAN and relay paths, but we cannot promise uptime in this post—only the trust model.
The unlocked phone remains the weak link. Encryption protects the wire. If someone has your unlocked iPhone, they have whatever Poket PC your phone can do. Revoke the device from the Mac menu bar to kill the live session; Face ID before opening a session is planned.
Ask expands blast radius on the Mac. The relay does not see Ask prompts, but the model provider you pick does: your prompts, and the screenshots Ask needs, go to that provider (with Ollama they stay on the Mac). And a task you send acts on the Mac without stopping for approval, within the reach you picked; at Tools reach that includes every tool set up on the Mac, including any that can run commands or send mail. That risk is bounded by reach settings, not by the relay.
Comparison to “fully encrypted” marketing
Some products say “encrypted” when they mean TLS to the vendor’s server, where the vendor holds keys or can log sessions. Poket PC’s relay is closer to a TURN-like dumb pipe for Noise records: match, copy, never decrypt.
We run the relay ourselves, and its code is not public, so today you rely on our description of it on the /security/ page and in this post.
Operating notes for users
- You do not need to configure the relay. The apps choose LAN or relay automatically.
- You do configure macOS permissions on the Mac and pairing once per phone.
- Revoking a phone is immediate; it is the fastest way to cut access if a device is lost.
Further reading
- Security: How Poket PC Protects Your Mac
- Glossary: zero-knowledge relay
- Glossary: Noise protocol IK
- Access Mac remotely from anywhere
If you find a gap between this post and the implementation, email support@poketpc.com before publishing exploit details.
Frequently asked questions
Does Poket PC use a VPN?
No. The relay forwards encrypted bytes between your devices. It is not a VPN tunnel.
Can Poket PC read my screen on the server?
No. Only your paired iPhone and Mac hold session keys. The relay copies ciphertext.
What metadata does the relay see?
Connection timing, IP addresses, traffic sizes and the random routing token that matches two connections—not screen pixels or keystrokes.