Security, Encryption & Data Protection
Relevant source files
The following files were used as context for generating this wiki page:
Introduction
Omi implements a multi-layered security and data protection architecture designed to safeguard personal conversations, screen context, and integration secrets across wearable, mobile, desktop, and cloud environments. The project prioritizes user privacy by ensuring that data, by default, remains on the user's local machine, while providing encrypted private cloud storage for cross-device synchronization.
The scope of security measures includes broken authentication/authorization prevention, cross-account data access restrictions, and the protection of sensitive artifacts such as transcripts, recordings, and API keys. The system leverages industry-standard protocols like OAuth 2.0 and Firebase Auth to manage identity and access control across all supported platforms.
Sources: SECURITY.md:3-5, SECURITY.md:32-40, desktop/macos/Desktop/Sources/Chat/ChatPrompts.swift:377-380
Authentication and Access Control
Authentication is primarily managed through Firebase Auth, supporting Google and Apple Sign-In providers. The system implements strict token lifecycle management to prevent unauthorized access.
Identity Management Flow
The mobile and desktop applications utilize platform-specific auth implementations:
- Mobile: Uses native
google_sign_inandsign_in_with_apple(including PKCE via nonce+sha256). - Desktop: Utilizes a backend OAuth flow (
/v1/auth/authorize) and a shared Apple Services ID (me.omi.web). - Backend: Validates Firebase ID tokens for WebSocket proxying and REST API access.
Sources: app/AGENTS.md:95-97, desktop/macos/AGENTS.md:73-77, AGENTS.md:155-156
Token Lifecycle & Headers
All API requests are secured via specific headers and bearer tokens:
- Automatic Refresh: The system checks token expiry with a 5-minute buffer. If expired, it triggers a Firebase refresh.
- Retry Logic: 401 responses trigger an automatic token refresh followed by a request retry.
- Request Metadata: Headers include
X-Request-Start-Time,X-App-Platform,X-Device-Id-Hash, andX-App-Version.
Sources: app/AGENTS.md:88-93, app/AGENTS.md:104-106
Logging Security and PII Sanitization
To prevent accidental exposure of sensitive information in system logs, the backend employs specialized sanitization utilities. Developers are strictly prohibited from logging raw sensitive data.
Sanitization Procedures
The system distinguishes between general response data and Personally Identifiable Information (PII):
| Function | Targeted Data | Retained Data (Visible) |
|---|---|---|
sanitize() | response.text, API responses, error bodies | UIDs, IPs, status codes |
sanitize_pii() | Names, emails, user text | Debugging identifiers |
Sources: AGENTS.md:104-109
This diagram illustrates the logic for scrubbing sensitive data before it reaches log files or exception messages.
Sources: AGENTS.md:104-110
Data Protection and Encryption
Omi follows a "Local First" data ownership model. Information captured by the Omi wearable or desktop app is stored locally unless the user opts for cloud synchronization.
Storage Architecture
- Local Storage: Data stays on the user's machine by default. The user owns their data.
- Private Cloud: For mobile and web access, data is encrypted and stored in a private cloud, accessible only by the user.
- Database Access: Desktop apps interact with local SQLite databases for memories and conversations, while cloud sync utilizes Firestore subcollections organized by UID.
Sources: desktop/macos/Desktop/Sources/Chat/ChatPrompts.swift:377-380, desktop/macos/AGENTS.md:80-84
Firmware Security
Wearable security involves signed firmware images and encrypted communication protocols:
- RSA-2048 Signing: All firmware images (Application and Network cores) are cryptographically signed.
- Secure Boot: MCUboot verifies signatures before execution to prevent unauthorized code execution.
- Encrypted BLE: The MCUmgr protocol uses encrypted Bluetooth Low Energy (BLE) transport for OTA (Over-the-Air) updates.
- Rollback Protection: Prevents downgrading to older, potentially vulnerable firmware versions.
Sources: omi/firmware/BUILD_AND_OTA_FLASH.md:278-283
Security Policy and Vulnerability Reporting
The project maintains a formal security policy to handle vulnerabilities in production releases across mobile, desktop, backend, and firmware components.
Reporting Process
Maintainers prioritize fixes for the latest main branch and current production releases. The preferred reporting path is via GitHub's private vulnerability reporting flow.
Sources: SECURITY.md:7-12, SECURITY.md:17-30
Policy Scope
- In-Scope: Authentication bypass, cross-account data access, exposure of conversation transcripts, unsafe file handling, and vulnerabilities in OAuth or Firebase handling.
- Safe Harbor: Good-faith research is encouraged as long as researchers avoid disrupting services, do not persist data that is not theirs, and use their own accounts for testing.
Sources: SECURITY.md:32-40, SECURITY.md:46-53
Summary
The Omi security architecture relies on platform-native authentication, strict backend log sanitization, and hardware-level firmware signing. By combining a "local-first" data model with encrypted cloud synchronization, Omi ensures user-owned data remains protected while maintaining cross-device functionality. Security fixes are handled through a coordinated disclosure process to protect the user base from unpatched vulnerabilities.
Sources: SECURITY.md:55-56, desktop/macos/Desktop/Sources/Chat/ChatPrompts.swift:377-380, omi/firmware/BUILD_AND_OTA_FLASH.md:278-283