Skip to content
ARGUS User Manual

End-to-end encryption

ARGUS supports per-operation end-to-end encryption (E2E) on control-channel traffic and on the position-bearing fields of mission plans, polygons and flight logs. Encrypted payloads are opaque to the TACLINK fabric and to ARGUS backend services — only participants holding the operation’s key can decrypt them.

E2E is an operator trade-off, not a default. Turning it on protects against server-side compromise and against curious backend operators, but it also disables a handful of server-computed features that need to read the plaintext.

What gets encrypted

  • flight_control data-channel messages — DRC joystick, keyboard and gamepad inputs flowing through TACLINK.
  • drone_command messages — takeoff, RTH, gimbal, zoom, payload actions.
  • Mission waypoints — the waypoints[] array, plus pointAltOverrides and waypointActions, stored on Firestore as waypointsEnc blobs.
  • Polygons — ring points[] and multi-polygon paths[], stored as pointsEnc and pathsEnc.
  • Flight logs — the high-frequency breadcrumb path[] plus takeoff and landing coordinates, stored as pathEnc, takeoffLocationEnc and landingLocationEnc.
  • Selected Firestore metadata — e.g. WHIP stream keys, which otherwise would give a passive reader live-video access.

What is NOT encrypted

  • Live video tracks. TACLINK ships tracks with its own transport encryption; the SFU can still see frames. Ask support to enable TACLINK’s insertable-streams frame encryption if you need that layer too.
  • Telemetry topics (aircraft_flight_status, osd, etc.). We keep these inspectable for copilot analytics, master caution and mission reports. Flag aspirational: a toggle for telemetry E2E is planned but not available today.
  • Scalar flight-log aggregates — duration, max altitude, max speed, battery-at-start/end. These are needed for the after-action report and reveal nothing about position.

Enabling E2E

E2E is set at mission create or edit time on the Security step of the mission wizard. Tick E2E encryption, save, and every write from that point on will be encrypted.

Once the operation is active (first participant has joined) the toggle is locked. This is deliberate — flipping it mid-op would strand earlier messages in an unreadable state.

Key management

The per-operation key lives at missions/{id}.e2eKey and is lazily minted on the first encrypted write. Participants receive it through authenticated Firestore reads scoped by Firestore rules to users listed on the operation. The key never touches ARGUS backend logs and is never returned to the SFU.

Legacy documents (written before E2E was switched on) stay readable — the encrypt layer performs graceful passthrough: plaintext in, plaintext out.

The padlock indicator

The mission toolbar shows a padlock with three states:

  • Green, closed — E2E active and the local participant successfully decrypted the last N messages.
  • Amber, open — E2E is off for this operation.
  • Red, pulsing — E2E is on but decrypt is failing. Usually means your client has an old or wrong key, or the op key was rotated without you reconnecting.

If the padlock goes red, rejoin the operation from the dashboard. If it stays red, open a TACLINK debug tile and grab the key fingerprint shown in the header.

Impact on other features

  • Firestore queries that filter on encrypted fields (e.g. “waypoints inside bbox”) won’t work — the value is an AES-GCM blob server-side.
  • Server-side AI that walked the path can’t, because the path is opaque. The in-mission copilot still works — it runs inside your browser after decryption.
  • Mission export from the dashboard still works; the client decrypts before writing the ZIP.