English | 简体中文

Tags and releases are not long-term support branches unless explicitly stated. Security fixes land on main first. Maintainers then decide whether to publish a new release.

Use this repository's private Report a vulnerability workflow. GitHub Private Vulnerability Reporting is enabled so reporters can submit a structured report directly to repository administrators without opening a public issue. Do not disclose vulnerabilities, credentials, pairing tokens, personal quota data, reusable exploit steps, or unredacted logs in a public issue, discussion, or screenshot.

Include the affected version, host and firmware environment, reproduction conditions, observed impact, and any suggested mitigation. Coordinate public disclosure only after maintainers have confirmed the issue and prepared a fix and upgrade guidance. The project does not currently promise a fixed response SLA, but maintainers will acknowledge reproducible security reports as soon as practical.

• OpenAI sign-in data, OAuth tokens, and browser cookies are never written to the ESP32. The host sends only a minimized usage snapshot to the device.
• Wi-Fi /api/device uses a nonce and HMAC-SHA256 for mutual authentication and integrity, but its HTTP payload remains plaintext. Bind it only to a trusted, private LAN.
• BLE v1 uses a challenge, mutual proof of key possession, and a snapshot HMAC, but does not currently enable BLE link-layer encryption, OS pairing, or bonding. HMAC does not provide confidentiality: a nearby observer may still see usage JSON after a connection is established.
• The pairing token is the shared secret for both Wi-Fi and BLE. Treat it like a password; never place it in issues, logs, URLs, BLE advertisements, or screenshots.
• Radio interference, denial of service, Bluetooth congestion, upstream service outages, and compromise of the trusted host computer are risks the current protocol cannot fully eliminate.

For the complete protocol and threat boundaries, see docs/transport.md.