Privacy Policy

Last updated: August 31, 2026

Overview

LumaOS is a personal, open-source Linux distribution (GPL-2.0), and its component applications are developed and maintained by the same individual. This policy covers LumaOS as a whole and, in particular, luma-calendar — the calendar module that can optionally connect to your Google Calendar, Microsoft/Outlook Calendar, and/or iCloud Calendar. If you don't link any account, none of the provider-specific sections below apply to you.

What luma-calendar accesses, and why

When you choose to link a Google account from luma-calendar's popup, it requests two Google OAuth scopes:

  • https://www.googleapis.com/auth/calendar.calendarlist — to list which of your Google Calendars are available, so you can choose which ones to show in luma-calendar, and to sync a calendar's display color back to Google when you change it from luma-calendar's UI.
  • https://www.googleapis.com/auth/calendar.events — to read your calendar events and, since luma-calendar supports two-way sync, to create, edit, and delete events you manage through it.
  • https://www.googleapis.com/auth/userinfo.email — solely to show your own email address as the linked account's label in the popup's UI. It is never used for anything else.

When you choose to link a Microsoft/Outlook account instead (or in addition), it requests these Microsoft Graph delegated permissions:

  • Calendars.ReadWrite — to read your calendar events and, since luma-calendar supports two-way sync, to create, edit, and delete events you manage through it.
  • User.Read — solely to show your own email/display name as the linked account's label in the popup's UI. It is never used for anything else.
  • offline_access, openid, profile — standard scopes needed to keep the sign-in valid without requiring you to re-authenticate constantly, and to complete the sign-in itself.

When you choose to link an iCloud account, there's no OAuth consent screen — Apple doesn't offer one for third-party Calendar access. Instead you enter your Apple ID email and an app-specific password (generated at appleid.apple.com, not your actual Apple ID password) directly into luma-calendar's own UI. That username and app-specific password are used solely to authenticate to Apple's CalDAV calendar service (caldav.icloud.com and your account's assigned per-user host) — to list your calendars, read events for display, and, since luma-calendar supports two-way sync, create/edit/delete events you manage through it.

No other Google, Microsoft, or Apple data is requested, read, or stored.

Where your data goes — and where it doesn't

luma-calendar runs entirely on your own machine. The sign-in flow (OAuth for Google and Microsoft; direct CalDAV authentication for iCloud) and every subsequent Calendar API/CalDAV request happen directly between your computer and Google's, Microsoft's, or Apple's own servers, whichever provider(s) you linked. There is no LumaOS server in between — the people who develop LumaOS never receive, see, log, or have any access to your account credentials, your calendar events, or your stored tokens/passwords. Nothing is transmitted to any third party.

Locally, on your own machine:

  • Your Google/Microsoft OAuth refresh token, or your iCloud Apple ID email and app-specific password, is stored in your desktop's Secret Service keyring (typically GNOME Keyring), the same secure storage other desktop apps use for passwords and tokens — not in a plaintext config file.
  • A local cache of your calendar events is kept under $XDG_STATE_HOME/luma-calendar/events/ in your own home directory, so the calendar popup can render your events without a network round trip every time it opens.

How this data is protected

Your Google/Microsoft/iCloud calendar data and account credentials are sensitive, so luma-calendar protects them at every point they exist:

  • In transit: every request — sign-in, calendar list, event sync, event create/edit/delete — goes over HTTPS/TLS directly to Google's, Microsoft's, or Apple's own servers (for iCloud, sent as HTTP Basic Auth over TLS, the standard CalDAV authentication method). Nothing is ever sent in plaintext, and nothing passes through a LumaOS-operated server, because there isn't one.
  • Refresh token / app-specific password, at rest: stored exclusively in your desktop's OS Secret Service keyring (typically GNOME Keyring), the same encrypted, access-controlled storage the OS uses for saved passwords. It is never written to a plaintext config file, database, or log.
  • Cached calendar events / linked accounts, at rest: stored as regular files under $XDG_STATE_HOME/luma-calendar/ in your own home directory. luma-calendar explicitly sets that directory's permissions to owner-only (0700) every time it writes to it — this is enforced by the app itself, not left to your distro's default directory permissions (which, on some distros/configurations, would otherwise leave it group- or world-readable). It's further protected by full-disk encryption if you have that enabled, same as any other file in your home directory.
  • Access control: only processes running as your own OS user account can read either the keyring entry or the files above. Since luma-calendar has no server component, there is no centralized copy of your data anywhere else that could be exposed in a breach.

Data retention and removal

Your data stays on your machine for as long as luma-calendar is installed and the account remains linked. You can revoke access at any time:

  • Google — from Google's own Third-party apps & services page, which immediately invalidates the stored refresh token.
  • Microsoft/Outlook — from Microsoft's own Apps and services page, which immediately invalidates the stored refresh token.
  • iCloud — Apple has no equivalent third-party-access page, since there's no OAuth grant to revoke. Instead, delete the app-specific password from the "App-Specific Passwords" section of appleid.apple.com, which immediately invalidates it.

Either way, also unlinking the account from luma-calendar's own UI removes the stored credential from your keyring right away. Uninstalling luma-calendar, or manually deleting the files under $XDG_STATE_HOME/luma-calendar/ and the corresponding keyring entry, removes everything stored locally.

No analytics, no advertising, nothing sold

LumaOS and luma-calendar contain no analytics, telemetry, tracking, or advertising code. Your data is never sold, rented, or shared with any third party for any purpose.

Google API Services User Data Policy

LumaOS's use and transfer of information received from Google APIs adheres to the Google API Services User Data Policy, including the Limited Use requirements.

Microsoft Graph data use

LumaOS's use of information received from Microsoft Graph is limited to what's described above — reading and, for two-way sync, writing your calendar events, and reading your basic profile solely to label the linked account in the UI. Nothing received from Microsoft Graph is transmitted to any LumaOS-operated service, shared with any third party, or used for advertising, profiling, or any purpose beyond luma-calendar's own calendar sync feature.

iCloud data use

LumaOS's use of information received from Apple's iCloud CalDAV service is limited to what's described above — reading and, for two-way sync, writing your calendar events. luma-calendar itself never requests or touches any other iCloud data (Photos, Mail, Notes, Contacts, Find My, etc.) — it only ever speaks the CalDAV calendar protocol. Note that Apple's app-specific passwords aren't scoped to a single service by Apple itself, so the same password could technically authenticate to other iCloud protocols (e.g. IMAP for Mail) if entered elsewhere; luma-calendar simply never does that, and you can generate a separate app-specific password used only for luma-calendar if you'd rather keep it isolated. Nothing received from iCloud is transmitted to any LumaOS-operated service, shared with any third party, or used for advertising, profiling, or any purpose beyond luma-calendar's own calendar sync feature.

Other LumaOS components

LumaOS itself, and its other components, do not collect or transmit personal data to any LumaOS-operated service — there isn't one. Standard Ubuntu/Debian package management (APT) and any third-party repositories or services you choose to use (e.g. Google's or Microsoft's own servers, if you link an account) are governed by their own privacy policies, not this one.

Changes to this policy

If this policy changes, the update will be posted on this page with a revised "Last updated" date above.

Contact

Questions about this policy or how luma-calendar handles data can be sent to lucianomagri.std@gmail.com, or raised as an issue on GitLab.