What this policy covers
This policy describes the current Google Calendar connection used by Janelle.OS and these public information pages. Janelle.OS is a private, local-first personal application, not a public multi-user service.
The Calendar connection is configured, but the external event-execution capability is still being integrated and qualified. This policy does not represent that a production Calendar action has been completed.
Google data and permissions
The connection requests exactly these Google permissions, in separate read and execution grants:
https://www.googleapis.com/auth/calendar.freebusy: permits reading calendar availability. The integration being built limits reads to one selected calendar and at most fourteen days. It does not request the contents of existing events.https://www.googleapis.com/auth/calendar.app.created: permits creating app-owned secondary calendars and managing their events. Google’s scope includes more operations than the intended v1 adapter. The current candidate is being limited to one dedicated focus calendar, explicitly approved event creation and readback. No general calendar-editing scope is requested.openid: provides a stable Google account subject for identity verification and account binding. Both grants are checked against the same account subject. No email or profile permission is requested. If Google supplies an optional email claim, it is checked against the account selected for this installation.
At the current stage, the app has processed OAuth authorization responses and account identity claims and stored the grants. It has not created a dedicated calendar or event. Once enabled and qualified, availability intervals and the exact approved focus-event fields will be processed for scheduling and verification.
How information is used
Account identity is used to prevent mixing read and execution grants from different Google accounts. OAuth credentials are used to authenticate only the corresponding Calendar operations.
The intended Calendar workflow uses observed busy intervals with selected local goals or actions to prepare a focus proposal. Any availability-based recommendation is an inference, not a guarantee that a time is suitable. External creation must be authorized for the exact proposed action and independently reread before it is reported as verified.
Google user data is not sold, used for advertising, or used to train a generalized AI or machine-learning model. The current Calendar connection does not send Google user data to an external model service. These permissions do not authorize unrelated providers or additional uses.
Janelle.OS’s use and transfer of information received from Google APIs will adhere to the Google API Services User Data Policy, including its Limited Use requirements.
Storage and security
OAuth client registration secrets, access tokens and refresh tokens are held in separate macOS Keychain services with access restricted to the signed native application. Provider credentials are not Secure Enclave private keys. The existing Secure Enclave authority key and passkey registry are separate and have not been replaced by the Calendar connection.
Authorization codes and identity tokens are processed in native memory during the consent flow. The connection does not put provider secrets in the Janelle.OS browser page, ordinary application state, source files, Obsidian, logs, receipts or these public pages. The Google authorization response is requested using form-post delivery rather than placing its code in a callback URL.
Non-secret connection evidence stored locally includes the grant’s role, exact scopes, a digest of the verified Google account subject and verification time. It does not contain access or refresh tokens.
When external execution is enabled, local proposals and receipts will include the exact approved event fields, relevant provider object identifiers, timestamps, result and verification evidence. They must not contain provider credentials.
Retention and removal
Keychain credentials remain on the local Mac until removed or replaced through an explicitly supported credential-lifecycle operation. Google may expire or revoke a grant independently. The Google OAuth project is now In production. The existing grants are being renewed and qualified under that setting. Production mode removes the Testing-specific lifetime rule; it does not guarantee that Google access can never expire or be revoked.
Local records, approval evidence, authoritative history and backups have different purposes. Removing content from the current application view does not erase historical revisions, signed approval receipts or backups. Previously accepted authority history is preserved during recovery.
As Calendar execution is completed, proposal and provider-verification records will follow that disclosed historical-retention model. There is no claim of automatic permanent erasure or a fixed deletion period. Revoking Google access does not automatically delete local records, Keychain entries, historical receipts or backups.
Your choices and revocation
You can decline Google consent or deny an individual action. Granting Calendar access is not blanket permission for external mutations. A connection alone does not create an event.
You can review or revoke the app’s Google access in Google Account connections. Google’s revocation behavior can affect multiple OAuth clients within the same Cloud project. Separate read and execution grants are not a promise that Google will revoke them independently.
A dedicated in-app Calendar disconnect control is not yet available. After revocation or expiry, provider requests must fail closed rather than silently switch to another credential or provider. Revocation does not alter historical receipts or the local authority passkey.
This public website
These pages are static information. They contain no analytics, advertising, third-party scripts, embedded services, account login, contact form or application-storage code. They do not request Calendar authorization or receive Calendar credentials.
This information site is hosted using OpenAI Sites and delivered through Cloudflare infrastructure. The hosting services may process IP addresses, requested URLs, request times, browser information and security or diagnostic logs to deliver and protect the site. No fixed provider-log deletion period is promised here. Provider processing and retention are governed by their applicable policies: OpenAI privacy policy and Cloudflare privacy policy. The site contains no application-added analytics or advertising code. Calendar data and credentials are not sent to the public hosting infrastructure.
Questions and changes
For questions about the private installation or its Google access, use the support email displayed on the application’s Google consent screen. A personal account address is not reproduced on this public review site.
This policy will be updated when the integration’s deployed behavior or data handling changes. Material changes to permissions or uses require the relevant additional authorization. This policy is effective November 3, 2026.