dainvo

Security

Dainvo stores sensitive calendar data locally and will eventually connect to external providers. Security boundaries must be explicit from the start.

Token Handling

• OAuth tokens must be encrypted at rest.
• Renderer code must never receive access tokens, refresh tokens, auth codes, or encrypted token blobs.
• Provider errors must not leak tokens, authorization headers, auth codes, or raw provider credential payloads.
• Token-like fields must be redacted from logs and user-facing errors.

Token payloads are stored through the main-process TokenVault. The vault uses Electron safeStorage for encryption and stores only encrypted blobs in the SQLite account_tokens table. Token retrieval is main-process only; renderer APIs may expose connection status such as hasTokens, but must never expose token payloads or encrypted blobs. If encryption is unavailable in production, the vault fails closed rather than storing plaintext. No plaintext development fallback is configured.

Provider Access

• Use least-privilege provider scopes.
• Do not commit OAuth client secrets, refresh tokens, access tokens, app passwords, CalDAV passwords, local credentials, or user data.
• Provider SDK and network calls must run in the Electron main process.
• Automated tests must not call live provider APIs.

Public desktop OAuth client IDs and tenant IDs are bundled in the app so users can sign in without entering developer configuration. These identifiers are not client secrets. Do not add provider client secrets to the app or repository; installed desktop apps are public clients and cannot protect traditional secrets.

Generic CalDAV credentials are user-provided credentials rather than OAuth app configuration. They are stored only through the encrypted main-process TokenVault, never returned to the renderer after submission, and should be app passwords where the provider supports them.

Local Data

• The SQLite database must live under Electron app.getPath("userData").
• Database files, backups, exports containing user data, and provider caches must not be committed.
• Calendar events, attendee lists, document links, locations, descriptions, due dates, and sync logs may contain PII.

IPC Boundary

• All renderer-to-main inputs must be validated in the main process.
• Preload should expose a narrow typed API.
• Do not expose raw ipcRenderer, Node primitives, filesystem access, database handles, or provider clients to renderer code.
• Keep contextIsolation enabled and nodeIntegration disabled. If Electron preload sandboxing is enabled later, bundle preload code so local module imports remain compatible.
• User-facing errors should be safe and concise. Stack traces should not be shown in production.

Document Links and PII

Document URLs, event links, attendees, descriptions, and due dates can reveal private work context. Treat them as sensitive application data:

• Store only what the user intentionally provides or what provider sync requires.
• Avoid sending document links to providers unless the user creates or syncs an event that explicitly includes them.
• Keep logs free of full event descriptions and sensitive links where practical.