Skip to Content
Security & PrivacyEncryption & Data Flow

Encryption & Data Flow

How Screenshots Are Protected

Device → Encrypt (AES-256-GCM) → Upload (HTTPS) → Store (encrypted blob) → Decrypt (on view)

1. Capture

The agent captures a screenshot as a JPEG image in memory.

2. Encryption

Before leaving the device, the screenshot is encrypted using AES-256-GCM:

  • A unique encryption key and nonce are generated per screenshot
  • The image is encrypted in memory
  • Only the encrypted blob is written to disk or sent over the network

3. Upload

The encrypted blob is uploaded to the API over HTTPS (TLS 1.2+). The encryption key and nonce are sent alongside the blob as form fields (also over HTTPS).

4. Storage

The encrypted blob is stored in Azure Blob Storage. The encryption key reference is stored in the PostgreSQL database. The blob itself is unreadable without the key.

5. Viewing

When a parent views a screenshot in the portal:

  1. The API retrieves the encrypted blob from storage
  2. Decrypts it using the stored key reference
  3. Streams the decrypted image over HTTPS
  4. The decrypted image is never stored on disk — it’s streamed directly

Device Authentication

Each device authenticates using a unique API key pair:

  • X-Device-Id — The device’s UUID, assigned during enrolment
  • X-Device-Key — A random API key generated during enrolment

The API key is hashed (bcrypt) before storage. The plain-text key is only shown once during enrolment and stored locally on the device. If the key is lost, the device must be re-enrolled.

API Authentication

Parent portal authentication uses JWT tokens:

  • Tokens include a unique jti (JWT ID) for revocation support
  • Tokens include the family_id for data scoping
  • Logging out adds the token’s jti to a blocklist, immediately invalidating it
  • Token expiry is configurable (default: session-based)
Last updated on