Security

Satura Space runs on your machine. The one part that goes online for your work is Satura Remote, the phone app, and everything between your phone and your computer is end-to-end encrypted. This page explains what that covers, what our relay still sees, and how to report a security problem.

#Satura Remote is end-to-end encrypted

Everything between your phone and your computer is encrypted and authenticated on your devices. Our relay passes sealed frames along and holds no keys. It can't read, change or replay what goes through it: not your terminals, code, files or prompts, and not the game stream. We can't see or analyze your work.

• Keys are made on your devices. The phone makes its key in the browser as non-extractable, so even the page that uses it can't read it out. Your computer keeps its own key. Neither ever reaches our servers.
• Every frame is sealed. Calls, replies, terminal output and file contents travel as AES-256-GCM frames with a counter. A replayed, reordered, changed or injected frame fails, and the session closes.
• Each connection gets fresh keys. Every connection starts with a signed key exchange, so a key stolen later doesn't open sessions recorded earlier. Keys also rotate during long sessions.
• Standard building blocks. P-256 ECDSA and ECDH, HKDF-SHA-256, HMAC-SHA-256 and AES-256-GCM, from the browser's WebCrypto and Node's built-in crypto. No third-party crypto libraries.

#Pairing a phone

Your computer shows a one-time code and a QR code in Settings → Mobile. The code works once and for 10 minutes. The phone never sends the code: both sides use it to prove they're talking to each other and not to someone in the middle, and the QR code also pins your computer's key. Then your computer asks you to allow the phone, and only after you allow it does it remember that phone.

A relay that swaps keys during pairing can't produce the proof that the code covers, and a phone can't pair without a code shown on your computer.

#The game stream

Video, game input and terminal fast paths go peer-to-peer over WebRTC when the network allows, encrypted with DTLS. The offer, answer and fingerprints travel inside the end-to-end encrypted channel, so each side checks the other's real fingerprint, not one the relay hands it. When a TURN server has to carry the stream, it only sees DTLS.

#Removing phones and pairing again

Paired phones are listed in Settings → Mobile on your computer. Remove any you don't recognize: the phone disconnects at once, its key can't start a session again, and it has to pair anew with a fresh code. Remove all phones does the same for every phone.

Each install is its own device: on iOS, a Safari tab and the Home Screen app are separate phones. If the browser clears the phone's storage, the phone says it has to pair again. Phones paired before end-to-end encryption show as needing to pair again; remove them and pair with a new code.

#What the relay still sees

The relay routes traffic, so it still sees routing metadata: your account email, IP addresses, your computer's name, connection times, and the size, count and timing of messages. It also sees when the game stream starts and which ICE servers it handed out for it. It doesn't see your calls, replies, terminal data, file contents, prompts, the pairing code or the session keys.

#What you still trust

The relay serves the phone app's code, so that code is the remaining trust point. A tampered app could act on what you tap while it's open. It still couldn't copy the phone's key off the phone, and it couldn't pair a new phone without a code shown on your computer. Phone pages are sent with a strict Content-Security-Policy that blocks injected scripts and framing. Serving the phone app from a separate origin, or as a native app, would close this fully.

The details in the Allow dialog on your computer (device name, place, IP and email) come from the relay and the phone and aren't proven. The code is what proves the phone was in front of you.

#Reporting a vulnerability

Please don't open a public issue for a security problem. Report it privately instead:

• Through GitHub's private vulnerability reporting: github.com/saturadev/satura-space/security/advisories/new
• Or by email to [email protected]

Tell us the Satura Space version, your OS, what an attacker gains and how to reproduce it. We'll confirm we got the report and keep you posted on the fix.

#Supported versions

Only the latest release gets security fixes. The app updates itself from GitHub Releases, so a restart is usually all it takes to get the fix.

#Scope

In scope:

• the desktop app (apps/orchestrator),
• the Unity packages (packages/saturaspace-engine, packages/saturaspace-sdk),
• the MCP server (packages/mcp),
• Satura Remote (packages/companion-app, the relay and its phone web app).

In Satura Remote, reading, changing, replaying or injecting phone traffic, or pairing a phone or a computer through the relay without the pairing code, is in scope. The relay can always stop forwarding; that alone isn't a vulnerability.

#Open only projects you trust

Adding a folder to Satura Space runs the code it carries:

• dashboard alerts start right away,
• widgets and reports run when shown,
• report actions run on a click,
• and the Unity editor runs the project's editor scripts.

A project that makes Satura Space run its code is not a vulnerability. Escaping the report frame, the phone allowlist or a project's folder is.

The full policy is SECURITY.md.