How heyfood protects your data
This page covers what the CLI stores, what it sends, which permissions a session has, and what happens when a security check fails.
heyfood login --device --no-browserFour places we enforce it
- 01
Client
Credentials use the operating system's secure vault when available, with an owner-only file as a fallback. Diagnostics leave out secrets and personal data.
- 02
Transport
Remote service and authorization endpoints require verified HTTPS. Plain HTTP is restricted to exact loopback development hosts.
- 03
Permissions
The CLI asks only for the permissions a command needs. Consent, session renewal, sign-out, and account deletion remain visible to the user.
- 04
Backend
Sensitive records are encrypted with a versioned format. Services that handle protected data check their security requirements before accepting work.
How each kind of data is handled
| Data | How it is handled |
|---|---|
| Credentials | Protected local storage, limited permissions, redacted diagnostics, revocation, and credentials tied to one account. |
| Microphone audio | The planned Rust voice path keeps recordings in memory, sends them over an authenticated connection, and does not create temporary audio files. Voice is not active in v0.9.0. |
| Dietary context | Profiles sync only after consent. Sensitive records are encrypted, household access is explicit, and users can delete synced data. |
| Health integrations | Not available in heyfood v0.9.0. Future integrations must use separate consent, owner-only access, source labels, and deletion when consent is revoked. |
| Diagnostics | Request structure only. Tokens, keys, questions, profiles, phone numbers, and request bodies are excluded. |
Health is not a CLI capability in v0.9.0
The current CLI does not connect Oura, read Apple Health, request Health permissions, or store provider tokens. A future integration must keep Oura authorization separate from ordinary sign-in. Only an iPhone app—not a desktop CLI—can read Apple Health.
Any future Health data must belong only to the account owner, carry its source and freshness, stay out of operational logs, and be deleted when consent is revoked.
If a security check fails, the request stops
Protected services verify encrypted-data formats, HTTPS connections, service permissions, and runtime security settings. If a required check fails, the operation stops. It does not quietly fall back to plaintext storage or a weaker connection.
This work continues as the system evolves. We document what is deployed and observable. Internal key names, service layout, thresholds, and operational records stay private.
You should know who processes voice
A future voice interface must check microphone permission before recording and identify who processes the audio. It must not silently switch to a browser speech service. Voice capture is not active in heyfood v0.9.0; typed input remains available.
Release security
- Documented CLI behavior and JSON formats are versioned and tested against saved examples.
- Resolved dependencies are audited in CI.
- Release archives include checksums and GitHub build attestations.
- Before release, the Rust client is checked across supported platforms, dependency rules, source history, and compatibility tests.
- Security reports go through private vulnerability disclosure, not a public issue.