Privacy Notice

Google user data accessed

YAO LifeOS requests Google access only after the user starts a connection flow and approves Google OAuth consent. The service requests only the minimum Google scope needed for the feature the user starts.

For Google Drive, the app may access metadata and content for files and folders that the user selects or that the app creates using the Google Drive scope https://www.googleapis.com/auth/drive.file.

For Gmail readonly review, the app may access Gmail message metadata, headers, labels, thread membership, and message body content using the Gmail scope https://www.googleapis.com/auth/gmail.readonly. Access is limited to user-initiated, bounded workflows such as a selected Gmail thread, a user-provided Gmail reference, or a user-provided counterparty search used to find one relevant thread.

Gmail send, Gmail modify, Gmail delete, Calendar write, recurring event write, invitations, and broad mailbox scanning are not part of the public Gmail readonly review flow.

How Google user data is used

Drive data is used to confirm a user-selected Drive root, read file metadata or content summaries, create or update LifeOS-owned test files, and create LifeOS source-pointer records that refer back to the selected Drive item.

Gmail readonly data is used to show the user that a selected or bounded thread can be read, summarized, and converted into a LifeOS source-pointer or project-context preview. This is the maximum user-facing feature enabled by gmail.readonly: user-started read-only review of a bounded Gmail exchange for project context. The app does not use gmail.readonly to send, modify, archive, trash, or delete email.

Gmail metadata-only scopes are not sufficient for the Gmail source-pointer preview because the app must read the message body content transiently to create the user-requested body summary. The user-facing result is a sanitized summary and source pointer, not a raw Gmail export.

Gmail message body processing

For the submitted Gmail readonly flow, message body content is read only after a user starts a bounded review action and only for the selected or user-provided Gmail thread or exchange. The body is processed transiently to substantiate the user-facing project-context preview, sanitized summary, source pointer, and readback metrics.

Raw Gmail message bodies are not returned in public review output, committed to Git, published on public pages, or written to ordinary operational database records. If a user later saves LifeOS-managed project context, the saved record is a sanitized summary and source pointer, not the original Gmail body.

Limited Use and AI/ML processing

The use of raw or derived user data received from Workspace APIs adheres to the Google User Data Policy, including the Limited Use requirements. YAO LifeOS does not use raw, aggregated, anonymized, or derived Google Workspace API data to develop, improve, or train generalized or non-personalized AI or ML models.

The submitted Gmail readonly review flow does not transfer raw Gmail bodies to third-party AI services for generalized model training or model improvement. The review flow demonstrates deterministic, sanitized readback and source-pointer behavior.

Current and planned LifeOS AI processing is backend-controlled and must use providers and configurations that do not train generalized models on API payloads unless the user explicitly opts in outside this submitted Gmail review flow. The current repository configuration includes OpenAI API model-router placeholders for application features, with web search disabled for the submitted review flow. No third-party AI aggregator or model hub is used for the submitted Gmail readonly review flow. Cloudflare is used for hosting, access control, and deployment; Cloudflare AI model processing is not used by the submitted Gmail readonly review flow.

Sharing, transfer, and disclosure

YAO LifeOS does not sell Google user data and does not use Google user data for advertising.

Google user data is not shared with other users unless the user explicitly exports or shares LifeOS-managed output. Operational access is limited to the infrastructure and service providers needed to run the app, secure the app, store encrypted tokens, host the service, and maintain audit logs. Google user data may also be disclosed if required by law or to investigate abuse or security incidents.

Google Workspace API data is not used to develop, improve, or train generalized AI or ML models.

Data protection mechanisms

OAuth token bodies are stored only in encrypted backend vault custody. Ordinary operational records store provider name, scope reference, status, root reference, source pointer, sanitized summary, audit status, and secret references instead of token bodies.

Token bodies, client secrets, raw connection identifiers, raw message bodies, raw Gmail queries, raw email addresses, and raw provider identifiers are not committed to Git and are not returned in public review pages, fixtures, or sanitized readback payloads.

The app uses HTTPS, least-privilege OAuth scopes, Cloudflare Access for protected Owner/Admin review surfaces, bounded readback endpoints, audit events, and disconnect/revoke controls. Gmail raw message body storage is denied by default; body content is processed transiently for the user-requested summary and then excluded from ordinary storage.

Retention and deletion

OAuth tokens are retained only while the user keeps the provider connection active. When the user disconnects a provider or revokes Google access, the app invalidates future provider access and removes or disables the related secret reference according to the provider connection lifecycle.

LifeOS-managed summaries, source pointers, audit records, and operational metadata are retained while the user keeps the related LifeOS project or account active, unless the user requests deletion earlier.

Users can request export or deletion of LifeOS-managed operational data at Data export and deletion. Users can request account deletion at Account deletion. Deletion requests remove LifeOS-managed data from active systems, subject to limited backup, security, abuse-prevention, and legal-retention requirements.