We appreciate responsible security reports. If you discover an exploitable vulnerability, please report it privately before disclosing it publicly.

1. Do not create a public GitHub issue for security vulnerabilities
2. Send an email to the maintainers or use GitHub's private vulnerability reporting feature
3. Include a description, reproduction steps, potential impact, and suggested fix if available

• We will acknowledge your report within 48 hours
• We will provide an initial response within 7 days
• We will keep you informed of our progress
• We request that you allow us reasonable time to fix the issue before public disclosure

Open Babyphone is designed for local-network use in a trusted home environment. The supported product model is same Wi-Fi or same LAN. Advanced users may connect across a trusted VPN by entering the child device address manually.

The app does not require user accounts or project-operated servers for normal operation. Internet-based remote monitoring and hosted relay infrastructure are outside the current product scope.

Current security-relevant behavior:

• An 8-character pairing code is generated by default, and valid codes require 8–64 alphanumeric characters
• A valid pairing code and mutual challenge-response authentication are required; the pairing code itself is not sent over the connection
• Audio frames and heartbeats use ChaCha20-Poly1305 authenticated encryption
• The child pairing code stays in app-private preferences. On a parent, trusted-child credentials are stored separately from profile metadata and wrapped with an Android Keystore AES-GCM key; transient first-pair credentials remain only in bounded process memory until authentication succeeds
• Trusted profiles and credentials are excluded from Android cloud backup and device transfer in both current and legacy backup rules
• Listen notification actions target a non-exported internal activity. The app exposes no listen URI or deep link that another app can use to start a stored- credential connection
• OBP4 protocol and capability validation reject incompatible clients cleanly
• Key derivation uses Argon2id via Bouncy Castle with a per-installation random salt
• Separate authentication and stream keys are derived from the Argon2id result
• The salt is generated once per child installation, persisted locally, and sent in clear text in the handshake; it is not secret
• The salt ensures identical pairing codes on different installations derive different keys, preventing precomputation attacks across installations
• The protocol does not provide forward secrecy: anyone who later learns the pairing code and has captured a session can decrypt that recorded session

For design discussions or hardening ideas, please open a normal issue unless there is an exploitable vulnerability that needs private handling.

Security patches will be released as soon as possible. Depending on severity, we may:

• Release an immediate patch version
• Coordinate with F-Droid for rapid inclusion
• Publish a security advisory on GitHub

Thank you for helping keep Open Babyphone secure.