Security & Privacy Architecture

SyncingBoard was engineered under a strict privacy-first principle: zero permanent database storage.

When syncing confidential, unreleased product designs across tools, enterprise design teams cannot risk storing vector buffers or screen bitmaps on third-party databases. SyncingBoard acts exclusively as an ephemeral, encrypted peer-relay conduit between your design editor and your whiteboard.

The Security & Privacy Stack

+-----------------------------------------------------------------------------+
| 1. ZERO-RETENTION PEER RELAY (Stateless In-Memory Streaming)                |
| Payloads stream in-memory over WebSockets, single-read 180s Redis TTL + DEL |
+--------------------------------------┬--------------------------------------+
                                       |
                                       v
+-----------------------------------------------------------------------------+
| 2. CRYPTOGRAPHIC PAIRING & MASKING (Browser-Native Entropy)                 |
| 16-char unguessable keys (window.crypto), UI masking, and instant rotation  |
+--------------------------------------┬--------------------------------------+
                                       |
                                       v
+-----------------------------------------------------------------------------+
| 3. DISTRIBUTED SESSION INTEGRITY & PIN CHALLENGE                            |
| Per-user WebSocket channel isolation and planned remote PIN verification    |
+--------------------------------------┬--------------------------------------+
                                       |
                                       v
+-----------------------------------------------------------------------------+
| 4. CREDENTIAL ISOLATION & HEADER-BASED AUTH                                 |
| Access tokens transmitted in encrypted HTTP headers, zero log exposure      |
+-----------------------------------------------------------------------------+

1. Zero-Retention Ephemeral Relay & Single-Read TTL

Traditional sync tools store design assets on cloud storage buckets (AWS S3, Google Cloud Storage) or relational databases (PostgreSQL), creating permanent attack surfaces and compliance burdens.

SyncingBoard eliminates this risk entirely:

• In-Memory Streaming: Screen payloads and active selection events stream directly in-memory across encrypted Ably WebSocket channels (relayAbly.ts).
• Single-Read Ephemeral Storage: When large vector renders or high-DPI buffers exceed WebSocket payload limits, they are temporarily cached in Upstash Redis (relayRedis.ts) with a strict 180-second hard time-to-live (SETEX).
• Immediate Consumption Purge: The target whiteboard client fetches the image payload with a single GET request and immediately triggers a DEL command. Once consumed, or after 180 seconds have elapsed, zero bytes remain on any server.
• No Database Backend: SyncingBoard has no PostgreSQL, MySQL, or document database attached. Zero customer design screens or personal data can ever be leaked from cold storage.

2. Cryptographically Secure Pairing & UI Masking

SyncingBoard connects your design editor tab to your whiteboard session using deterministic, unguessable pairing keys:

• Browser-Native Entropy: Pairing IDs are generated in pairingId.ts using cryptographically secure random values (window.crypto.getRandomValues()), producing 16-character alphanumeric keys (sb_ + 16 random characters).
• Password-Style UI Masking: In the Miro and FigJam settings panels, pairing IDs are masked (●●●●●●●●) by default. This protects your connection tokens from shoulder-surfing during screen shares, live video meetings, and recorded Loom walkthroughs.
• Instant One-Click Rotation: Users can rotate their pairing ID at any time with a single click (rotatePairingId()), instantly invalidating existing WebSocket channels and terminating active companion sessions.

3. Remote Session Integrity & PIN Handshake

Because SyncingBoard decouples design editors from whiteboards over cloud WebSockets, browser tabs can run on completely different machines (e.g., a studio workstation acting as a distributed render node for a lightweight laptop in a client presentation).

To protect distributed setups across open networks:

• Per-User Channel Namespacing: Each pairing session operates on its own isolated Ably channel (penpot:${pairingId} / figma:${pairingId}), preventing cross-talk between different users or teams.
• Planned Remote PIN Challenge: To prevent unauthorized users from detecting or pulling active selections if a pairing ID is accidentally shared, the architectural roadmap introduces an optional PIN challenge handshake before bridging remote cross-machine sessions.

4. Credential Isolation & Header-Based Auth

Handling third-party OAuth access tokens for Figma and Miro requires strict transport hygiene:

• Header-Based Transmission: Access tokens are transmitted exclusively via standard HTTP Authorization request headers (X-Figma-Token, X-Miro-Token) rather than URL query parameters or JSON body payloads.
• Log Leakage Prevention: Query parameters and request bodies are frequently logged by reverse proxies, API gateways, Cloudflare WAFs, and CDN access logs. Passing tokens strictly in request headers ensures credentials never appear in serverless access logs.
• AES-256-GCM State Encryption: OAuth handshakes use AES-256-GCM authenticated encryption and cryptographically secure state parameters to protect against cross-site request forgery (CSRF).

5. Security & Privacy Architecture Matrix

Explore the rest of the architecture: Serverless Relay Architecture or return to SyncingBoard Overview.