Security architecture
A remote session should be obvious to the person being controlled.
The design begins with device identity, explicit grants, a visible host, bounded messages, and a service that does not hold session content or endpoint private keys.
From request to an authenticated media path
- 01
Enroll a device identity
A native endpoint generates its asymmetric identity locally and uploads only the public key and necessary metadata.
- 02
Authorize exact intent
A request names both devices, display, role, expiry, mode, and each permission. The target accepts, narrows, rejects, or uses a narrowly scoped trust rule.
- 03
Bind the peer handshake
Short-lived authorization is designed to bind the session, device fingerprints, protocol version, nonce, permissions, and WebRTC identity.
- 04
Stay visible and revocable
Permissions can change during the session; the host can stop immediately without asking the service.
Control plane
Metadata and authorization
Accounts, enrollment, device public keys, entitlements, request authorization, signaling, short-lived relay credentials, and content-free audit metadata.
Endpoint data plane
Session content
Screen, audio, clipboard, files, chat, transient input, device private keys, session private keys, and local recordings stay between participating devices.
Boundaries we will not blur
- No stealth installation, capture, or input.
- No keylogging, remote shell, arbitrary proxy, or unrestricted port forwarding.
- No operating-system security-dialog, secure desktop, antivirus, firewall, or store-policy bypass.
- No administrator function to watch customer screens or decrypt session content.
- No “same account means permanent full control” shortcut.
- No absolute security claim; testing gaps and residual risk remain documented.
Evidence before adjectives
This project is in active development. A third-party security audit has not occurred, production TURN has not been verified, and platform signing gates remain open. Those facts block stronger claims.
Report a security concern