Security

This app can start and stop real services on a real Mac, sometimes from the other side of the world. That only makes sense if a stolen phone, a sniffed network or a guessed token can't be turned into control of your servers. FrontierStack is built so that none of those, on their own, is enough. This chapter explains the layers — and why they let you reach your Mac safely through a Cloudflare tunnel from anywhere.

3.1Every request is signed

The strongest protection is invisible. When this device was paired, it generated its own private key and stored it in the iOS Keychain — it never leaves the phone, and even this app cannot read it back out as plain text. Every request the app sends to your Mac is signed with that key. The Mac keeps an allow-list of the devices you approved, each by its public key, and checks the signature on every request against the device that claims to be sending it.

This is the FS1 per-device model: it uses Ed25519 signatures, and each signed request also carries a timestamp and a one-time nonce, so a captured request can't be replayed even seconds later. The practical consequence is the important part: a bearer token on its own — the kind of shared secret that older apps rely on — cannot control anything here. Without this device's private key, a copied token is inert.

3.2Encrypted, pinned connections

Signatures prove who is talking; encryption protects what they say. When your Mac advertises an HTTPS address, this app talks to it over TLS like any secure connection. But there is a twist: the Mac uses a self-signed certificate it generates itself, so there is no public authority to vouch for it.

Instead, the app uses certificate pinning. The pairing QR code carried the exact fingerprint of the Mac's certificate. From then on, the app accepts only a connection presenting that exact certificate — nothing else. An attacker who sits in the middle and offers their own certificate, even a "valid" one, is rejected, because its fingerprint won't match the one you pinned at pairing.

3.3Why this is safe from anywhere

Put the two together and you can see why reaching your Mac over a public path — a Cloudflare tunnel, for instance — is safe rather than reckless. The tunnel only carries traffic; it can't forge it.

• The connection is encrypted and pinned, so the tunnel (and anyone along the way) sees ciphertext to a certificate they can't impersonate.
• Every request is signed by this device's key, so even something that reached the Mac couldn't issue a command it would honour.
• Replay is blocked by the per-request timestamp and nonce, so re-sending a captured request fails.

The Mac decides whether the public path even exists, and you can close it. Nothing here depends on the network being private — the protections travel with each request.

3.4App lock

Network security can't help if someone simply picks up your unlocked phone. The app lock closes that gap. In Settings, turn on a passcode; from then on the app is locked until you enter it, and you can add Face ID or Touch ID for one-tap unlock. The app re-locks whenever you leave it — switch apps or lock the phone, and it asks again on your return.

The passcode itself is never stored. The app keeps only a salted hash of it in the device Keychain, so even with the phone in hand there is no passcode to read back — an attempt either hashes to the stored value or it doesn't. Biometric unlock is handled by iOS, which only tells the app yes or no.

Mirroring the Mac's lock. If the Mac itself has an App Lock password, this app adopts it at pairing: it locks and requires the same password. The password never travels — only its salted hash is delivered over the pinned pairing connection, and the phone verifies your entry against it locally (the identical scheme both use). While mirrored you can't change or remove the lock from the phone; it follows the Mac.

3.5What this device is allowed to do

Authentication answers "is this really my phone?"; permission scopes answer "and how much may it do?". That decision lives on the Mac, not here. Each paired device is assigned one of four levels — Read-only, Restart, Operate or Full control — and the Mac enforces it on every signed request. A phone you carry everywhere can stay safely at a low level even though it is fully paired.

If a button is disabled or an action is refused, this device's level doesn't permit it — raise it on the Mac, or use a device that already has the rights. The four levels and what each unlocks are set out in Pairing.

Two grants sit alongside the level, both set on the Mac. Allow AI Administrator (on by default) decides whether this phone may use the AI tab at all — a way to let one device chat while blocking another. Allow remote shell is offered only at Full control and is off by default; it is what lets this device open the Shell tab and reach your servers directly. Neither is a bypass: even with AI allowed, any change still needs Full control's "Allow changes" and the app unlocked.

3.6If you lose a device

Because each phone has its own key, you never have to change anything else to cut one off. On the Mac, open Paired Devices (in the Overview group), find the device by name, and revoke it. Its key is removed from the allow-list at once: the moment it tries to talk to the Mac again, its signature is rejected. Your other devices are untouched and keep working.

Revoking on the Mac is the authoritative step — it stops the device even if you can't reach the phone itself. "Unpair this device" inside the app only forgets the connection on a phone you still hold; for a lost one, revoke on the Mac.

For a phone that is genuinely gone, the Mac offers a stronger one-click action: Secure lost phone. Beyond revoking the key, it immediately cancels the device's older queued actions, closes its open sessions, removes any SSH keys it installed on your servers for direct access, and deactivates its push notifications. Servers that are offline at that moment stay listed so you can finish removing the keys when they come back.