Security

1. The threat model

Phoenix assumes it is running on a machine the operator controls, on a network the operator trusts, serving a household. The assets worth protecting are the household's account credentials, the robot's credentials, and the personal data described in the privacy policy — photographs, messages, locations and voice.

The design does not assume a hostile local network, and it is not built to withstand an attacker who already has a shell on the host. If the machine is compromised, the data on it is compromised.

2. How access is controlled

• People sign in with an email address and password against the instance's own account store. Passwords are stored hashed, never in plain text. A successful sign-in issues a session cookie which every console API route checks.
• Robots connect over TLS and authenticate with their own genuine credentials. Requests from a robot are signed, and the signature is verified before the request is served.
• The console talks to the services it fronts using the signed-in account's own keys, rather than a shared administrative credential, so a session can only reach what that account could reach.
• The admin surface is gated separately by a password held in the instance's environment configuration, not by an ordinary account.

3. Deploying it safely

If you are running an instance, these are the things that actually matter:

• Terminate TLS in front of the service. A reverse-proxy configuration is included with the source; use a real certificate rather than a self-signed one wherever the robot will accept it.
• Set a strong, unique admin password in the environment configuration, and do not reuse a password from anywhere else.
• Keep the environment file, the data directory and any credential material readable only by the account the service runs as.
• Run the service as an unprivileged user, not as root.
• Back up the data directory yourself. Nobody else has a copy, and a lost disk is lost photographs.
• Keep the host patched. Most realistic compromises of a home server are not application bugs.

4. Exposing it to the internet

Many people will want to reach their robot's console from outside the house. If you do:

• Put a TLS-terminating reverse proxy in front of it and never expose the service port directly.
• Restrict the admin surface by source address at the proxy, in addition to its password.
• Consider putting the whole console behind a VPN or a private tunnel instead. For a household service this is both easier and stronger than hardening a public endpoint.
• Rate-limit authentication endpoints at the proxy.

The shipped reverse-proxy configuration sets sensible security headers, separates the static site from the proxied API, and is commented so you can see what each directive is for.

5. What is not hardened

Stated plainly, because a security page that only lists strengths is not a security page:

• Phoenix has not undergone an independent security audit or penetration test.
• There is no built-in rate limiting or brute-force lockout on sign-in; that belongs at your proxy.
• There is no multi-factor authentication.
• Some compatibility surfaces reproduce the behaviour of a service designed around 2016, and those behaviours cannot be modernised without breaking the robot that depends on them.
• Several console surfaces are read-only or partial, and are labelled as such in the interface.

6. Supply chain

The project deliberately carries a very small dependency footprint — a single external runtime dependency — which keeps the amount of third-party code running beside your household data small enough to reason about.

Front-end libraries are vendored into the repository and served from your own instance rather than loaded from a CDN, so no outside host can inject code into a page that has access to your session. This website loads no third-party scripts, styles or fonts at all.

7. Reporting a vulnerability

If you believe you have found a security problem, please report it privately first, to the maintainer of the repository the software came from, and give a reasonable period for a fix before disclosing it publicly.

A useful report includes what you found, where, how to reproduce it, and what an attacker could achieve with it. There is no bug-bounty programme and no money behind this project; there is genuine gratitude, and credit if you would like it.

Please do not test against an instance that is not yours. Someone's photographs of their family are on the other side of it.

8. Scope

In scope: the Phoenix source code, its default configuration, and the console and website it serves.

Out of scope: individual people's deployments and the networks they run on, the original robot firmware and hardware, and third-party data services an operator has chosen to configure.

See also: Terms of use and Privacy policy.