Renny Household OS

Last updated 18 October 2026

Privacy notice

Renny — Household OS is a private organiser for invited household members. This notice describes the implemented data handling, including integrations that require separate activation and consent.

This public website

These public pages consist only of static HTML and CSS, prepared for hosting on Cloudflare Pages. They contain no household records, backend, login, credential upload, forms, analytics or scripts, and make no requests to the household server. The files do not set cookies. Cloudflare provides hosting and public HTTPS and may process visitor IP addresses, request metadata and security cookies under its own service practices; this notice does not promise that Cloudflare keeps no logs.

Google account data

Google access uses the member’s own browser consent; Renny does not ask for a Google password. Default permissions are limited to calendars created by the application and files created or explicitly authorised for the application. This includes the shared calendar, household folder and Google Sheets finance workbook. Per-file access does not grant access to an entire Drive.

Calendar data is used to show and manage authorised shared events. Drive metadata is used to locate authorised documents. Spreadsheet data is used for household budgeting and approved input changes. Personal-calendar detail access requires separate read-only consent and an explicit configured selection; it is not enabled by default. Bot calendar writes target only the configured joint calendar, without automatically inviting external guests.

Google remains the source of truth for events, documents and finance. The household server also stores relevant resource identifiers, action inputs, approval previews, results and delivery state for operation and duplicate prevention. It does not maintain a separate full finance ledger. OAuth tokens are encrypted before local database storage; credentials and encryption keys are held in restricted server files. Authorised household members can access shared household records.

This implementation does not sell Google user data, use it for advertising, or use it to train general-purpose AI models. Google data is used for the requested household features and the service connections described here.

WhatsApp and shared records

The dedicated bot account connects through WAHA’s unofficial linked-device bridge. WhatsApp carries the conversations, and the linked bridge can decrypt messages delivered to that bot account. Linked-device synchronisation may expose account history to the bridge before application filtering; a dedicated account is required rather than a member’s personal account.

The application admits only enrolled senders and its selected household group. Group actions require the explicit command prefix. Conversation contexts for each private chat and the group are separate. Shopping items, tasks, joint events and household finance are shared records even when requested in a private chat. The bridge is configured to disable media downloads; voice and document-content ingestion are not current household workflows.

AI and other infrastructure

Clear supported commands work without an AI model. Optional local inference may run on a private household computer; it is not assumed available. Context supplied for interpretation is bounded and separated by conversation. Model output is an untrusted proposal: the household server checks identity, permissions, inputs and required confirmations before a tool changes data.

Cloud inference is disabled and there is no automatic fallback. Any future cloud request would require a separately configured provider and authenticated, one-use approval of the exact genuinely de-identified outbound payload. A previous approval cannot authorise later requests. No current cloud model receives Google or WhatsApp credentials.

The private web application uses Cloudflare Access and validates signed identity tokens. Cloudflare terminates web HTTPS and can process application traffic. Google and WhatsApp process data in their own services. Local AI therefore does not mean that every component is offline. Phone keyboard dictation may use the keyboard provider’s cloud.

Retention, export and deletion

The configured default for local conversational text is 30 days. While the worker runs, cleanup removes old context text and redacts expired inbox/outbox message bodies, including queued messages. This is not a guarantee that every record disappears after 30 days: saved shopping and task records, action inputs and results, finance approval records, operational identifiers and encrypted backups have separate lifetimes and may retain values from earlier requests.

Export and conversation-deletion commands are available through protected operator access. An export includes shared records and only the requesting member’s private context. Conversation deletion does not delete shared records, provider copies or existing backups. Shared-record removal and backup retention require operator review. No fixed automatic backup-expiry or physical-erasure guarantee is made. SQLite pages and WAL files can retain previous data.

Google access can be revoked in the Google Account’s third-party connections settings. WhatsApp can be disconnected through the dedicated account’s Linked devices settings. Revocation stops future authorised access but does not automatically delete existing records. Google files/events, delivered messages, recipient copies and Cloudflare data remain subject to their respective controls and policies.

Contact and changes

Invited members can ask the household operator about access, export, deletion or a concern through their existing private contact channel. This site does not publish personal contact details or accept public accounts. Material changes to integrations or data handling should be reviewed with household members and reflected in this notice.