User guide · Installation · Privacy policy
ListMyDay is designed to keep everyday schedules private while allowing a trusted caregiver to manage a household's display devices. Its security model does not rely on a shared household password or on hiding an API address. It uses independent household boundaries, device-specific credentials, explicit enrollment approval, encryption, and a restricted public server configuration.
Household separation
Each household is a separate tenant. API requests are checked against tenant-scoped authorization records; a credential for one household must not grant access to another. Household-specific recovery authority and encryption keys are stored separately from the application source code.
Device authorization
- Caregiver and care-receiver devices have different privileges. A display receives a restricted credential rather than the household recovery key.
- New display enrollment requires a short-lived caregiver-opened window, a pairing code, a separate verification code, and explicit caregiver approval.
- Device credentials are independently revocable and can expire. The server stores credential hashes rather than plaintext bearer tokens.
- Recovery authority is separate from normal device access, so a receiver does not need to hold the household's owner secret.
Data protection
- Household board content is encrypted with a separate 256-bit tenant key. A database copy alone is not sufficient to read encrypted board content.
- Recovery and board-encryption keys require restricted filesystem permissions and separate protected backups. Database metadata and any exported JSON need their own protections.
- Revocation and household deletion are enforced on the server; an offline device may retain previously cached information until it reconnects.
Transport and network boundaries
- The public deployment is designed for HTTPS with TLS 1.3 through Nginx. The Python API binds to loopback, not a public network interface.
- The deployment uses firewall restrictions, SSH public-key authentication, and bounded server connections and request limits as additional defenses.
- Local HTTP is permitted only for explicitly configured private-network development installations; it is not encrypted and must never be exposed by port forwarding.
- Server installation support is limited to Ubuntu 24.04 LTS.
Operational controls and limitations
Operators are responsible for security updates, certificate renewal, secure backups, recovery testing, monitoring, and deployment configuration. Rate limiting and bounded connections help reduce abuse but are not a guarantee against denial-of-service attacks. A successful API health check does not prove that backups or every feature are working.
For technical reviewers
The source repository contains more detailed implementation and operational guidance, including server security operations and device enrollment and review procedures. These documents distinguish shipped functionality from future work. Security concerns can be reported through support; please avoid posting credentials or private household data in public issues.