cloudcal-bridge
Privacy Policy
This policy explains how cloudcal-bridge accesses, uses, stores, and shares information when you connect a Google account to a self-hosted deployment.
1. About cloudcal-bridge
cloudcal-bridge is a self-hosted homelab application that reads selected Google Calendar data and makes it available through private ICS subscription URLs. Its primary purpose is to let a user subscribe to Google calendars from software such as Nextcloud without giving that subscription client direct access to the user's Google account.
This privacy policy applies to the cloudcal-bridge application and to the specific deployment on which it is published. A self-hosted operator controls the server, network, database, backups, reverse proxy, and domain used for that deployment.
2. Google data cloudcal-bridge accesses
When you choose to connect Google, cloudcal-bridge uses Google OAuth 2.0 and requests only the permissions needed for its current features. These permissions allow the app to receive a stable Google account identifier and verified email address, read the list of calendars available to your account, and read events from calendars that you choose to expose through a feed.
Calendar event information returned by Google can include event titles, descriptions, locations, start and end times, all-day dates, status, transparency, sequence information, update timestamps, calendar names, calendar identifiers, and timezone information. cloudcal-bridge does not request permission to create, modify, delete, or share Google Calendar events.
3. How Google data is used
Google account information is used to authenticate you to the management interface and associate stored OAuth credentials and feed settings with the correct account. Calendar-list information is used to show the calendars available to you. Calendar event information is requested when a private feed is refreshed and is transformed into standard ICS calendar content for that feed.
cloudcal-bridge does not use Google user data for advertising, profiling, credit decisions, surveillance, or unrelated analytics. It does not sell Google user data. It does not use Google Calendar content to train generalized artificial-intelligence or machine-learning models.
4. Storage and protection of data
The deployment stores account and feed configuration in a local SQLite database so the service can continue to work between restarts. Sensitive fields such as the Google email address, access and refresh tokens, selected calendar identifiers and names, account timezone, and private feed token are encrypted by the application before being stored. Keyed blind indexes are used where the application needs to look up certain encrypted identifiers.
Google access tokens may be stored temporarily until they expire. A Google refresh token may be stored so cloudcal-bridge can obtain new access tokens and keep calendar subscriptions working without requiring you to interactively sign in each time a feed refreshes. The encryption password and session secret are supplied by the deployment operator and are not stored in the database as plaintext application configuration.
No security mechanism can guarantee absolute protection. The operator of a self-hosted deployment is responsible for securing the host, HTTPS termination, environment variables, database files, backups, logs, and network access.
5. Private ICS feed URLs
A generated ICS URL is a bearer secret. Anyone who obtains that URL can request the associated calendar feed until the URL is revoked. The feed itself can contain Google Calendar event information such as titles, descriptions, locations, and times. You should treat a feed URL like a password, share it only with calendar clients or people you trust, and revoke it if you believe it has been exposed.
cloudcal-bridge does not require an interactive login when a valid feed URL is requested because unattended calendar clients need to refresh subscriptions automatically. Revoking a feed disables the old URL; creating it again generates a different private token.
6. Sharing and transfers
cloudcal-bridge does not sell Google user data or intentionally provide it to data brokers, advertisers, or unrelated third parties. Google Calendar data is returned through a private ICS URL only as part of the user-requested bridge functionality. A calendar client such as Nextcloud receives that data when you configure the private feed URL in that client.
The application communicates with Google services as necessary for OAuth authentication, token refresh, identity verification, and Google Calendar API requests. Your self-hosted infrastructure providers, DNS provider, reverse proxy, hosting provider, backup system, or network operator may also process technical information according to how you configure your environment; those services are controlled by the deployment operator rather than by cloudcal-bridge itself.
7. Logs and technical information
The cloudcal-bridge application is designed not to emit routine per-request access logs containing private feed URLs. However, the surrounding web server, container platform, ingress controller, reverse proxy, firewall, or hosting provider may log IP addresses, request paths, timestamps, user agents, and other connection metadata. The deployment operator should configure those systems appropriately because a logged feed URL can provide access to the associated calendar while that feed remains active.
8. Retention, deletion, and revocation
Account configuration and encrypted credentials remain in the deployment database for as long as the operator retains that database. Feed records remain until removed by the operator, although revoking a feed makes its URL inactive. Calendar events are fetched from Google to construct feed responses; cloudcal-bridge is not intended to maintain a separate long-term archive of Google event content.
You can revoke individual feed URLs from the cloudcal-bridge management interface. You can also revoke the application's Google access from your Google Account permissions. To fully remove locally stored account information, the operator of the self-hosted deployment must delete the corresponding application data or database records and any retained backups according to the operator's backup practices.
9. Cookies and browser sessions
The management interface uses a signed, HttpOnly session cookie to maintain your authenticated browser session and OAuth flow state. The application also uses a per-session CSRF token to protect state-changing management requests. These mechanisms are used for security and application functionality rather than advertising or cross-site tracking.
10. Google API Services User Data Policy
cloudcal-bridge's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements.
The application requests narrowly scoped, read-only Calendar access for the functionality described on the cloudcal-bridge homepage. If the application changes the Google data it requests or the purposes for which that data is used, this policy should be updated before those changes are made available to users.
11. Children
cloudcal-bridge is a technical self-hosted utility and is not directed to children. The operator of a deployment is responsible for deciding who may use that deployment and for complying with any laws that apply to the operator or its users.
12. Changes to this policy
This policy may be updated when cloudcal-bridge functionality or data practices change. The effective date at the top of this page should be updated when material changes are published. Continued use of a deployment after an updated policy is published is subject to the updated disclosure.
13. Contact
For privacy questions, data-removal requests, or questions about a specific cloudcal-bridge deployment, contact the administrator of the domain on which that deployment is hosted. Because cloudcal-bridge is self-hosted, that administrator controls the deployment's database, backups, server logs, OAuth credentials, and infrastructure.