Security
Security & Data Architecture
Data Flow Architecture
The diagram below shows each system that touches your data, from your Ring camera to the Chimelab dashboard. Detection details (frame fetch, gates, and model inference) are summarized in the note below.
Ring Camera
Vehicle motion
Ring
Webhook + media API
Chimelab
HMAC verify + on-server detection
Postgres
Delivery metadata
Object Storage
Snapshot JPEGs
Dashboard
Authenticated access
Chimelab verifies Ring webhook signatures, downloads a multi-frame motion clip (~21 JPEG samples) from the Ring media API, and analyzes frames locally with YOLO11n ONNX and light-body color heuristics — never a third-party AI API. At most one snapshot JPEG is stored per confirmed delivery (nine most recent on the dashboard). Raw video is never stored.
Data Storage Locations
| Data Type | Storage System | Location | Retention |
|---|---|---|---|
| User account (email) | PostgreSQL | Render Postgres (US) | Until account deletion |
| Delivery metadata | PostgreSQL | Render Postgres (US) | Max 100 records per user |
| Delivery snapshot images | S3-compatible object storage | Separate provider (e.g. R2, S3, GCS) | 9 most recent deliveries only |
| Ring OAuth tokens | PostgreSQL (AES-256-GCM encrypted) | Render Postgres (US) | Until account deletion or authenticated Ring disconnect |
| Device config / mailbox ROI | PostgreSQL | Render Postgres (US) | Until account deletion |
| Recent motion debug records | PostgreSQL | Render Postgres (US) | Max 20 rows per user |
| Session cookie (JWT) | User's browser only | Client-side | 30 days maximum |
| Structured application logs | stdout | Render service logs | Per Render log retention policy |
Encryption
In Transit
- All user-facing traffic over HTTPS / TLS (terminated at Render)
- Strict-Transport-Security (HSTS) and Content-Security-Policy headers on all responses in production
- 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 an application-level encryption key
- No raw video or audio is ever stored by Chimelab
Access Controls
Mutating API routes enforce session authentication and per-user tenant scoping. Postgres-backed rate limits protect abuse-prone endpoints. Exact thresholds are not published; clients receive HTTP 429 responses when limits are exceeded.
| Endpoint / action | Abuse control |
|---|---|
| Magic-link sign-in | Rolling limits per email address and per client IP address |
| Account deletion | Strict rolling limits per authenticated user |
| Settings updates (device config, timezone, preferences) | Rolling limits per authenticated user |
| Ring webhook ingress | HMAC signature verification and durable request_id deduplication (see Known Limitations) |
| Role | Access |
|---|---|
| End user | Own deliveries, snapshots, device settings, and preferences only. Every API query is scoped by authenticated user ID — users cannot access other accounts' data. |
| Application server | Render 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
Chimelab 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 prefix | What is logged |
|---|---|
webhook.* | Inbound motion events, signature failures, duplicate request IDs |
rate_limit.* | Rate limit denials (magic link, settings, account deletion) |
webhook.dedupe_cleanup | Expired webhook idempotency row cleanup |
motion.* | Detection gate reasons, deliveries recorded, processing failures |
settings.device_config_updated | Device sensitivity and MailDrop Zone (ROI) updates |
snapshot.pruned_* | Snapshot retention enforcement |
account.deleted | Verified account deletion events |
Incident & Breach Response
- Identify and contain — revoke affected Ring tokens, rotate compromised secrets.
- Assess scope — determine which users and data types are affected via Render Postgres and object-storage review.
- Notify affected users within 72 hours via their registered email address.
- Notify Render support for infrastructure-level incidents.
- Regulatory notification if required (GDPR Art. 33, CCPA).
- Public status update at www.chimelab.co if the incident is widespread.
- Post-incident review and implement corrective measures.
Security contact: contactchimelab@gmail.com
Platform-Level Security (Render)
Chimelab 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 multi-factor authentication (email magic link only)