SECURITY ARCHITECTURE

Access QUTRIT
Anywhere Securely

QUTRIT Remote Access securely controls QUTRIT Desktop while your PC is online. Chat history, local RAG, API keys, and the entry point for AI processing remain on the PC.

Overview

QUTRIT Remote Access
Four Security Foundations

No inbound PC port

QUTRIT Desktop opens an outbound connection to Cloudflare. You do not expose your PC through router port forwarding or a public listening port.

End-to-end encrypted content

Questions, answers, conversation titles, and whiteboards are encrypted on one endpoint and decrypted only on the paired endpoint.

Sign-in is not enough

A Firebase sign-in must be combined with QR pairing and a device-specific cryptographic key before the phone can communicate with the PC.

The PC makes the final decision

The Relay and phone are not trusted blindly. QUTRIT Desktop checks the paired device and command allowlist before executing an operation.

In plain English

Cloudflare acts like a switchboard that cannot open the envelope

Cloudflare Workers and Durable Objects provide the path between your phone and PC. Before chat content enters that path, it has already been sealed by encryption.

The Relay handles delivery information, such as which PC should receive a message and whether its size is allowed. It does not possess the cryptographic keys required to read the question or answer inside.

Core principle: Relay does not store your chat data temporarily or permanently. Also, it cannot read or decrypt your chat data.
Smartphone Encrypts and decrypts
Ciphertext Unreadable in transit
QUTRIT Desktop Decrypts and processes
Data path

From a phone command to an AI response

The Relay does not process your chat. It only forwards an encrypted command to the PC and returns the encrypted result to the phone.

Firebase Auth / Firestore

Stores authentication and metadata such as pairing state, public keys, device names, and expiration dates. It does not store chat content or private keys.

Data visibility

What each component can see

Component Primary role Can decrypt chat content? Persistently stores chat content?
Smartphone Display, input, encryption, decryption Yes No
Cloudflare Worker / Durable Object Authenticated WebSocket routing, status, size checks No No
QUTRIT Desktop Decryption, authorization, AI processing, history Yes Yes, stored locally on the PC
Firebase Auth / Firestore Authentication and device/pairing metadata No No

Routing and operational metadata remains visible to the Relay, including user, host, device and job IDs, message type, ciphertext size, timestamps, and error codes.

Technical detail

Defense in depth

1. Outbound WebSocket

QUTRIT Desktop initiates a WSS connection to the Cloudflare Relay. The PC does not expose a listening port, so the design does not create a direct inbound route from the internet into the home or office network.

  • Outbound connection from the PC only
  • Low-frequency liveness check every 90 seconds
  • PC considered offline after 180 seconds without a response
  • Encrypted envelopes are limited to 512 KiB
  • Durable Objects WebSocket Hibernation API

2. WebSocket authentication

The PC and phone send a Firebase ID token as the first message after the WebSocket opens. The token is not placed in the URL query string, reducing exposure through URL logs and browser history.

  • Relay verifies signature, issuer, audience, and expiry
  • The socket remains unauthorized until authentication succeeds
  • Connections that fail to authenticate within a few seconds are closed
  • The WebSocket URL contains the host ID, not the auth token

3. QR pairing and public-key verification

The QR code shown by QUTRIT Desktop contains the PC public key, its fingerprint, and a pairing token that expires after five minutes. The phone recomputes the fingerprint and rejects the pairing if it does not match.

  • Pairing token ownership is checked against the Firebase user
  • Five-minute expiry and consumed state are checked
  • Device registration and token consumption are committed atomically in Firestore
  • Every phone receives a unique device ID and key pair
  • The pairing expires after a period of inactivity
  • Paired devices can be revoked from QUTRIT Desktop

4. End-to-end encryption

Cryptographic keys remain on the phone and PC and are never sent to the Relay. Canonical JSON command and response payloads are encrypted before they enter the WebSocket.

Key agreementECDH P-256
Key derivationHKDF-SHA-256
Payload cipherAES-256-GCM
NonceRandom 12 bytes
Authentication tag128 bit
Additional authenticated dataIDs, type, sequence, and more

5. Key storage

The phone creates a non-extractable Web Crypto key and stores the CryptoKey in IndexedDB. On the PC, QUTRIT protects its private key with Electron's OS-backed encryption when that capability is available.

  • Only the phone public key is stored in Firestore
  • Private keys, shared secrets, and API keys are not stored in Firestore
  • Firestore Security Rules restrict accepted metadata fields
  • The local PIN is never sent to a server

6. PC-side command restrictions

Unknown and high-risk commands are rejected by QUTRIT Desktop after decryption.

  • Allowed: list/view chats, create a chat, send, model settings, view whiteboard
  • Rejected: credential access, settings changes, file attachment or path reads
  • Rejected: chat deletion/rename, whiteboard editing, cross-chat search
  • Job IDs reduce duplicate execution of the same operation
  • Revocation closes the matching WebSocket and irreversible rules block future authentication
Local-first

Remote access does not move QUTRIT's center of gravity to the cloud

Remains on the PC

  • Chat history and generated results
  • Local RAG indexes and source material
  • Self-Serve Mode API keys
  • Credentials for integrations such as Notion
  • Final authorization for AI and tool execution

Handled by cloud services

  • Firebase account authentication
  • Host ID, device ID, public key, and device name
  • Pairing expiry and consumed state
  • Encrypted traffic and its size
  • Connection status, timestamps, and content-free errors
Scope and limitations

E2E encryption protects the phone-to-PC Relay path

After the PC decrypts a message, QUTRIT sends the necessary data to the selected AI service in the same way as a normal desktop session. Self-Serve Mode connects from the PC to the AI provider. Managed Mode uses QUTRIT's cloud proxy. Data handling by each AI provider also depends on the user's contract, plan, and settings.

  • This design cannot protect plaintext already decrypted on a PC compromised by malware.
  • OS locking, browser updates, and device management remain important on a paired phone.
  • The local PIN is an additional screen lock, not a replacement for a strong device passcode or biometrics.
  • No design can completely eliminate outages involving networks, Cloudflare, Firebase, or AI providers.