Security

Security & Data Architecture

How Mailbox collects, processes, stores, and protects your data. Last updated: June 11, 2026 · www.chimelab.co

← Back to Mailbox

Data FlowStorageEncryptionAccessLogsIncidentsRenderLimitations

Data Flow Architecture

The diagram below shows every system that touches your data, from your Ring camera to the Mailbox dashboard. All vehicle detection runs on Mailbox servers — camera frames are never sent to a third-party AI API.

Ring Camera

Vehicle motion detected

→

Ring Cloud

ring.com servers

→

Ring Webhook

HTTPS POST to Mailbox

→

HMAC Verification

Signature validated

→

Vehicle Filter

Non-vehicle motion discarded

→

Watch Hours Gate

6 AM–8 PM user timezone

→

Media Fetch

~21 JPEG frames via Ring API

→

Local Detection

YOLO ONNX + color heuristics

→

ROI / Dwell Gates

Mailbox zone + stop duration

→

Render Postgres

Delivery metadata stored

→

Object Storage

Snapshot JPEG (up to 9)

→

Dashboard

Authenticated delivery history

Mailbox downloads a multi-frame motion clip (~21 JPEG samples) from the Ring media API, analyzes frames locally with YOLO11n ONNX, and stores at most one snapshot per confirmed delivery. Raw video is never stored. There is no second-pass video reclassification.

Data Storage Locations

Data TypeStorage SystemLocationRetention
User account (email)PostgreSQLRender Postgres (US)Until account deletion
Delivery metadataPostgreSQLRender Postgres (US)Max 100 records per user
Delivery snapshot imagesS3-compatible object storageSeparate provider (e.g. R2, S3, GCS)9 most recent deliveries only
Ring OAuth tokensPostgreSQL (AES-256-GCM encrypted)Render Postgres (US)Until disconnect or account deletion
Device config / mailbox ROIPostgreSQLRender Postgres (US)Until account deletion
Recent motion debug recordsPostgreSQLRender Postgres (US)Max 20 rows per user
Session cookie (JWT)User's browser onlyClient-side30 days maximum
Webhook deduplicationIn-memory cacheRender web service process24-hour rolling window (not durable)
Structured application logsstdoutRender service logsPer Render log retention policy

Encryption

In Transit

  • All user-facing traffic over HTTPS / TLS (terminated at Render)
  • Ring webhook payloads verified via HMAC-SHA256 before processing
  • Ring API and Resend email calls over TLS
  • Session cookies: HttpOnly and Secure in production (Auth.js defaults; SameSite=Lax)

At Rest

  • Database encryption at rest managed by Render Postgres
  • Ring OAuth tokens encrypted with AES-256-GCM before storage in Render Postgres
  • Object-storage encryption managed by the storage provider
  • Session JWTs signed with AUTH_SECRET (application-level)
  • No raw video or audio is ever stored by Mailbox

Access Controls

RoleAccess
End userOwn deliveries, snapshots, device settings, and preferences only. Every API query is scoped by authenticated user ID — users cannot access other accounts' data.
Application serverRender Postgres and object storage via server credentials. Delivery snapshots are served only through authenticated API routes — no public or guessable URLs.
Operator (Chimelab)Render dashboard and Render Postgres access for support, incident response, and manual DSAR fulfillment only. No third-party employees have standing database access.

Operational Logs

Mailbox writes structured JSON events to stdout (collected by Render). These are operational logs, not a separate tamper-evident audit database. Logs intentionally avoid magic links, OAuth tokens, and full webhook bodies.

Event prefixWhat is logged
webhook.*Inbound motion events, signature failures, duplicate request IDs
motion.*Detection gate reasons, deliveries recorded, processing failures
settings.device_config_updatedDevice sensitivity, ROI, and enable/disable changes
snapshot.pruned_*Snapshot retention enforcement
account.deletedVerified account deletion events

Incident & Breach Response

  1. Identify and contain — revoke affected Ring tokens, rotate compromised secrets (AUTH_SECRET, TOKEN_ENCRYPTION_KEY, RING_WEBHOOK_SIGNING_KEY).
  2. Assess scope — determine which users and data types are affected via Render Postgres and object-storage review.
  3. Notify affected users within 72 hours via their registered email address.
  4. Notify Render support for infrastructure-level incidents.
  5. Regulatory notification if required (GDPR Art. 33, CCPA).
  6. Public status update at www.chimelab.co if the incident is widespread.
  7. Post-incident review and implement corrective measures.

Security contact: contactchimelab@gmail.com

Platform-Level Security (Render)

Mailbox production runs on Render. The primary database is Render Postgres. The following infrastructure controls are managed by Render and not directly operated by Chimelab:

  • TLS termination at the Render edge
  • Render Postgres encryption at rest and managed backups
  • DDoS protection and network-level security
  • Physical data center security

Delivery snapshot images are stored in a separate S3-compatible bucket (not on Render). Contact Render for platform security documentation.

Known Limitations

The following controls are not implemented today. This list is provided for transparency:

  • No API rate limiting on login, webhooks, or settings endpoints
  • No multi-factor authentication (email magic link only)
  • No Content-Security-Policy or Strict-Transport-Security headers in application config (Render provides HTTPS)
  • Webhook deduplication is in-memory and resets on redeploy; not shared across multiple service instances
  • Authenticated POST APIs rely on same-site session cookies, not explicit CSRF tokens
  • Ring privacy-zone masks are not yet applied before inference (planned)

Privacy & Data Policy · Sign in

Mailbox · www.chimelab.co · Operated by Chimelab