1. At a glance

• You sign in with Google. There are no Calmora passwords, and we never see or store your Google password.
• We request the narrowest Google Calendar permission that lets the app do its job (calendar.events), and we touch only your primary calendar.
• We keep one small database, for your saved commute and — only where the operator offers travel nudges and you turn them on — for those nudges: if you save your commute setup while signed in, it is stored in a Postgres database hosted by Neon, keyed to your account’s email address, so it follows you to your other devices, and stays until you delete it. If you turn travel nudges on, the same database keeps, under the same key, the times and event IDs of your journeys for the next 36 hours and your devices’ notification subscriptions, until the journey is over or you turn nudges off; and, if you also turn on keeping travel blocks current, the ID and times of each travel block the Service added for those journeys and a record of each automatic move, until you turn that off; and, if you also turn on live location for travel, the 100 metre square you shared for a journey, for at most 30 minutes. It holds no event titles, places or descriptions, and no tokens (Sections 7 and 10). On a deployment where the operator has not switched account storage on, your commute stays in your browser only. Apart from that, the application writes no user data to disk on the server, with one exception that exists only if an operator switches it on (an address-lookup cache file, Section 3.5). What the server holds in memory is listed in this policy, item by item, with its bounds and lifetime.
• To estimate travel between your commitments, the Service uses the location of your calendar events, any commute details you enter, the places you type into the Trip room where an operator has switched it on, and — only where live location for travel is on, you turned it on and you press “Update from where I am” — the 100 metre square your device is in. It works them out on our server; the outside services involved are Open-Meteo, which receives only a coordinate rounded to about 1 km for a weather check; the MTA, whose public live train feed our server reads during live hours, naming only a group of subway lines; OpenStreetMap’s Nominatim or NYC GeoSearch, only if an operator turns address lookup on; and Google’s Routes API, only if an operator turns route checking on and then only for the operator’s own account, which receives the coordinates of a trip’s two ends and a time (Section 3.5). Where an operator has switched the map on and you open the week map, or a trip’s map in the Trip room, your browser loads the map from OpenFreeMap (Section 3.5).
• Your Google sign-in tokens are stored in an encrypted cookie in your own browser — not on our servers.
• Specific, minimized pieces of data are sent to Anthropic, our AI provider, to power the features you see (Section 5 lists every such flow). Under Anthropic’s commercial terms, API data is not used to train Anthropic’s models.
• No advertising, no analytics, no tracking pixels, no third-party scripts, no data sales, no data brokers.The Service loads all of its code and interface fonts from its own origin. The only outside host the page itself fetches anything from is OpenFreeMap — map images and map-label lettering — and only where the map is switched on and you open the week map or a trip’s map (Section 3.5).
• Signing in never asks for access to your email.The one way the Service can read your mail is an optional mail view on the Standby Board: it is off unless the operator switches it on, and even then it reads nothing until you click “Connect Gmail” and grant Google’s separate, read-only Gmail permission. What it reads, and what it keeps (nothing), is in Section 6.1.
• You can cut off all access at any time from your Google Account permissions page. Signing out of Calmora alone does not revoke the Google-side grant — Section 10 explains both steps.

2. Who we are, and what this policy covers

Calmora (the “Service”) is operated by Darwin Hu, an independent developer based in New York, United States (“we”, “us”, the “Operator”). You can reach us about anything in this policy at darwinhu64@gmail.com.

This policy covers the Calmora website and application, including its use of information received from Google APIs. It applies to everyone who visits or signs in. It does not cover Google’s own handling of your Google account and calendar (governed by the Google Privacy Policy) or Anthropic’s handling of API traffic (governed by Anthropic’s Commercial Terms), though Section 5 describes what we send to Anthropic and on what conditions.

3. Information the Service receives

4. How we use information

We use the information above to do exactly the things the interface shows:

• parse your text or image into draft events you review before anything is written;
• show your week, with busy blocks and realistic free windows;
• show the next 60 days of your calendar on the Standby Board;
• estimate travel time between your commitments, and tell you when to leave for the commute you set up (Section 3.5);
• where live location for travel is on and you turn it on, work out when to leave from where you are when you ask, and time that journey’s nudge from it (Section 3.5);
• where the week map is switched on and you open it, show where your commitments are on a map (Section 3.5);
• where the Trip room is switched on, plan a trip between two places you type — and, where the map is also on and you open it, show that trip on a map (Section 3.5);
• check proposed work shifts against your existing commitments;
• create, change and delete events in your primary Google Calendar — behind an explicit confirmation step, except for the automatic paths described below;
• keep the Service working (deduplicate retried writes, enforce rate limits, debug failures from metadata-only logs).

Automatic writes (autopilot). Autopilot is off unless it is switched on. While it is off — the state the Service ships in — nothing reaches your calendar until you confirm a preview, apart from keeping travel blocks current (below), a separate switch that is also off unless you turn it on. While it is on, the Service may create (and, within the limits below, change or remove) an event without asking you first, and only when the parse cleared every one of these gates: high confidence, nothing flagged for review, no warnings, no unresolved research questions, and a complete date and time. Anything that fails a gate still comes to you as a preview. Whatever autopilot does is reported on screen when it happens, marked as done automatically, with the way back beside it: an event it created can be removed there, an event it moved can be changed back there, and an event it removed can be put back there.

Automatic removals.Autopilot removes an event on its own only where the operator of this deployment has switched that on separately, and then only an event the Service itself created: a single event (never a repeating one), with no guests, in a routine category (work, school, or study), named exactly as your message names it, on the day your message names. Anything short of that comes to you as a preview to confirm. An automated removal happens only when the Service can send a notification to a device where you have turned notifications on, and it is then sent to every such device, naming what was removed and when it was. The removal is listed under “Autopilot did this” on the You tab for as long as this server remembers it (at most 24 hours), where it can be put back; Google Calendar’s Trash keeps the removed event for thirty days either way.

Automatic changes.Under the same separate switch and the same limits, autopilot may change the time of, or remove, an event the Service itself created. A change moves only when the event happens, to the time your message names: a message that would also change its place or anything else, or whose new start leaves the event without an end that still fits, comes to you as a preview to confirm instead, as does a repeating event. An automatic change is also refused when the event’s times are no longer the ones the Service last wrote — an event you have moved yourself in Google Calendar is never moved again on its own — or when the event was added before the Service recorded the times it wrote. A serious change — a different day, a move of thirty minutes or more, a change of place (as well as a change of length of thirty minutes or more, a switch between all-day and timed, an event other people are on, a new time that runs into something else on your calendar, or a new time the Service could not check against the rest of your calendar) — is sent as a notification to every device where you have turned notifications on; a routine one is not; an automated change, like a removal, happens only when such a device can be reached. A change is listed on the You tab with the notification naming where it was; change it back in Google Calendar.

Keeping travel blocks current. Separate from autopilot, and off unless the operator of this deployment switches it on and you then turn on “Keep my travel blocks current” on the You tab (it needs travel nudges on). When the latest plan for a journey — worked out from your route and live train times, never your location — says to leave earlier or later than the travel block the Service added for it, the Service moves that block’s start time to match, without a preview. It does so only for a single travel block the Service itself added between two of your commitments, with no guests, whose times are still the ones the Service last wrote and have not changed since the move was worked out; only by more than 5 and at most 60 minutes; only on the same day; never so that the block starts before the commitment before it ends, and never in the past. The block’s end stays at your next commitment’s start, nothing else about the event changes, and Google is told not to email anyone. Our scheduler, which holds no access to your calendar, works the move out; your browser makes it, with your own sign-in, while your week is open in the app, and the week view then says what moved. A block that fails any check is left as it is, and that move is dropped rather than tried again. To undo a move, change the block in Google Calendar: the Service never moves a block you changed. It is per account, off by default, and turning it off (or turning travel nudges off) stops it at once.

Autopilot is per account and off by default. It does nothing for your account until you switch it on from the You tab, and it applies only to the browser you turned it on in, until you sign out, sign in again, or your sign-in expires.

We do not use your information for advertising, do not build profiles for any purpose other than the features above, and do not sell or rent any of it to anyone (Section 8).

5. AI processing — what is sent to Anthropic, exactly

The intelligence in Calmora comes from AI models operated by Anthropic, PBC (api.anthropic.com). This section is the complete list of what crosses that boundary when you use the Service (one additional flow exists that never involves your data: the operator-configurable email capability of Section 6.1). Three properties hold for every flow below:

• All AI calls are made from our server.Your browser never talks to Anthropic, and the page’s security policy (Section 11) blocks it from talking to anything but the Service’s own origin — and, only where the map is switched on (the week map, and the Trip room’s map), the map-tile host (Section 3.5).
• Your data is not used to train models.Anthropic’s Commercial Terms of Service provide that Anthropic may not train models on customer content from its API services (see Anthropic Commercial Terms), and we do not opt in to any data-sharing or training program. We request provider-side prompt caching only for our own fixed instructions — never for your content.
• Untrusted content is fenced. Everything user-provided or external (your text, image contents, calendar titles, web results) is wrapped in explicit data-only delimiters and sanitized, and the instructions tell the model to treat it as data, never as commands. This is a prompt-injection defense, not a privacy control, but it shapes every request we send.

6. Google user data — access, use, storage, sharing (Limited Use)

This section restates, in Google’s required frame, how the Service handles information received from Google APIs.

• Access: identity basics (openid, email, profile) and read/write access to events on your primary calendar via the calendar.eventsscope, as described in Section 3; and, only if you choose “Connect Gmail” on the Standby Board where the operator has switched its mail view on, read-only access to your Gmail (Section 6.1).
• Use: solely to provide the user-facing features that are prominent in the interface — parsing events you submit, rendering your week, your availability, and the Standby Board, estimating travel between your commitments, showing them on the week map when you open it, checking shifts, and creating, changing or deleting events on the terms set out in Section 4 (your confirmation; autopilot when it is switched on; or, if you turn it on, keeping the travel blocks the Service added current — each within the limits described there). Not for advertising. Not for credit-worthiness or lending decisions. Not to build databases about you.
• Storage:Google calendar data is not stored durably on our servers. The one piece of Google user data kept durably is your Google account’s email address, and only if you save a commute while signed in: it is the key under which that commute is stored in our database (Section 7), so it can be returned to you and to no one else. No calendar content is stored there — with one exception you choose: where travel nudges are offered and you turn them on, the same database keeps, under the same email key, the IDs of the calendar events your next journeys join and their leave-by and arrival times, until each journey is over (Section 3.5); and, if you also turn on keeping travel blocks current, the ID and start and end times of the travel block the Service added for each of those journeys (with Google’s version tag for it), and a record of each automatic move made or refused (an internal draft ID and the outcome of the checks), until you turn it off (Sections 4 and 7); and, if you also turn on live location for travel, the time to leave worked out from where you were for a journey, for at most 30 minutes (Section 3.5). Never an event’s title, place, description or guests. Beyond that, no files are written except one that exists only if an operator switches it on: the address-lookup cache of Section 3.5, which can hold event location text (in normalized form, with its coordinates) and is not tied to any account (Section 7). Transient in-process memory (for example, the per-sign-in title-category cache) is enumerated in Section 7 with its bounds and lifetimes. Your tokens live encrypted in your own browser.
• Sharing:the only transfers of Google user data to a third party are the AI flows itemized in Section 5 — narrowly scoped payloads sent to Anthropic (and, for research on public events, a query to Tavily) — and the travel lookups in Section 3.5: a coordinate rounded to about 1 km, which may be derived from an event’s location, sent to Open-Meteo for a weather check; during live hours, a request to the MTA naming only which group of subway lines’ public live feed to read, which may follow from the lines a trip between your events would use; and, only where an operator has turned address lookup on, an event’s location text sent to OpenStreetMap’s Nominatim service or to NYC GeoSearch to find its coordinates; and, only where an operator has turned route checking on and only for the operator’s own account, the coordinates of a trip’s two ends (the shift or event being checked, or the workplace, and the commitment just before or after it) and the time of the trip, sent to Google’s Routes API to check how long it takes. One further flow is indirect, and we state it so it is not missed: where the week map is switched on and you open it, your browser requests map tiles from OpenFreeMap for the area around your events, so OpenFreeMap can infer that area from which tiles were requested — though it receives no event text, times, positions, or account details. Where account storage is switched on, your email address is also held by Neon, Inc., the database host (Section 8), as the key of the commute you saved — and, if you turn travel nudges on, as the key of the event IDs and journey times they keep — stored for us, not shared for any use of Neon’s own. Each serves those same user-facing features. Google user data is never transferred to advertising platforms, data brokers, or information resellers, never sold, and never used for any purpose beyond the features you can see.
• AI/ML restriction: Google user data sent to our AI provider is used only to produce the immediate, user-visible result and is not used — by us or, per its terms, by Anthropic — to create, train, or improve any machine-learning or artificial-intelligence model.
• Human access:no one, including the Operator, reads your Google user data through the Service: no screen, route, or log line exposes one account’s calendar content to anyone else. The narrow exceptions Google’s policy contemplates apply here too — we may access data where you explicitly ask us to (for example, helping you debug with data you share), where necessary for security (investigating abuse), or where required by law.

Calmora’s use of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The use of information received from Google Workspace scopes will adhere to the Google User Data Policy, including the Limited Use requirements.

7. Where data lives, and for how long

The Service is deliberately built with as little storage as it can manage. The durable copies of your data live in systems youcontrol — your Google Calendar, your Google account, and your own browser — with three exceptions, all in our database: the commute setup you save while signed in, which lives there so it can follow you between devices; what travel nudges need, only if you turn them on where they are offered; and a single row recording that your account has signed in. Here is the complete inventory as the public Service runs (the operator email capability of Section 6.1, when an operator configures it, adds in-memory stores of the operator’s own email-derived proposals, message IDs, and extraction counters — bounded, and likewise erased on restart):

• Google tokens and identity — your browser. Stored in the session cookie, encrypted with a server-held key, marked HttpOnly and Secure, expiring after about 30 days of inactivity or when you sign out. The server never persists them.
• Your calendar — your Google account. The Service reads it per-request and keeps no copy. Events it creates (with the properties described in Section 3.2.1) live in your calendar under your control.
• Rejected-category titles — your browser.One localStorage entry, the 50 most recent titles, kept until you clear your browser’s site data for the Service. It is not tied to an account, and signing out does not clear it.
• Confirmed guesses — your browser.One localStorage entry: of the titles you confirmed, the 100 most recently answered or on a week you viewed, each with the category you confirmed. Sent with that browser’s requests (Section 3.3) and kept on none of our servers. Removed when you sign out on that browser or clear its site data for the Service.
• Commute setup — our database, and your browser.Where account storage is switched on and you save your commute while signed in, one row in a Postgres database hosted by Neon, Inc. (Section 8) holds your commute answers (Section 3.3), your account’s email address as the row’s key, and the time it was last saved — nothing else. It is kept until you delete it with the commute setup’s “Delete my saved commute” button or ask us to (Section 10); saving again replaces it, and a server restart does not erase it. Your browser also keeps a localStorage copy (Section 9), kept until you change it, delete it, sign out (for a copy that came from your account), or clear your browser’s site data for the Service. Where account storage is not switched on, the browser copy is the only one.
• That your account signed in — our database. Where account storage is switched on, one row per account holds your email address, the first and last time the Service saw you, and how many times you have signed in. It holds nothing about what you did, no calendar data, and no tokens. It is written when you sign in and kept until you ask us to delete it (Section 10); deleting your commute setup does not remove it, because it is a different row answering a different question.
• How often the Service was used — our database, with no link to you. Daily totals of four things: sentences parsed, schedule photos read, events added, and automatic writes. The table storing them has no column for an account, so there is nothing in it to connect a count to a person — not your address, not an identifier, not an IP. Kept indefinitely as aggregate numbers, because once recorded there is nothing personal left in them to expire.
• Typed text and uploaded images — request lifetime only. Processed in memory, never written to disk, gone when the response is sent.
• Push subscriptions — server memory, only if you enable notifications. When you turn on push, your browser’s subscription (a device endpoint URL and the two keys needed to encrypt a message to it) is held in the server’s in-process memory so it can be reached when the Service writes an event, removes one automatically, or makes a serious change to one (Section 4), and when you press “Send a test notification”. No name or calendar content is stored with it; it is dropped when the server restarts or when the push service reports the subscription is gone, and you can end it by turning notifications off. Signing out also ends notifications on that browser: the Service asks the server to forget its subscription and tells the browser to drop it. If you have turned travel nudges on, a copy is also kept in our database (next item).
• Travel nudges — our database, only if you turn them on.Where the operator offers travel nudges and you turn them on, the Postgres database hosted by Neon, Inc. (Section 8) keeps, keyed to your account’s email address: that you turned them on; for each journey your week view showed arriving in the next 36 hours, the IDs of the two calendar events it joins, when you need to leave, when you arrive, the time zone, whether you are the operator, and which nudges have been sent; and a copy of the push subscription (endpoint URL, the two encryption keys, and a device name such as “iPhone”) of each device, at most 10, where you have turned notifications on. No event title, place, description or guest is kept, and no location of yours unless you also turn on live location for travel (below). A journey is deleted once it is over, or when your week view no longer shows it. A device copy is kept until you turn nudges off, turn notifications off on that device or sign out there, or its push service reports it gone. Turning nudges off deletes all of it at once (Section 10); a server restart does not erase it.
• Keeping travel blocks current — our database, only if you turn it on. Beside each journey above: the event ID of the travel block the Service added for it, the block’s start and end times, Google’s version tag for it (so a block you edited in any way since is left alone), when the commitment before it ends, when that was read, and the move waiting to be made (the new start and end, the minutes, and when it was worked out). These go with the journey. And, keyed to your account’s email address, a record of each automatic move made or refused: an internal draft ID (made of event IDs and a time), that it was this kind of automation, whether it was allowed and which checks stopped it, and when — never a title, place, description or guest. The records are kept until you turn keeping travel blocks current or travel nudges off (Section 10); if one cannot be written there, it goes to the server-memory buffer below instead.
• Live location for travel — our database, 30 minutes at most, only if you turn it on.Beside a journey that travel nudges are watching, when you press “Update from where I am”: the 100 metre square your device was in (two whole numbers naming the square, never a latitude or longitude), when you sent it, and the time to leave worked out from it. Each is deleted 30 minutes after it was sent at the latest — every read of it refuses an older one and our scheduler clears older ones — and at once when you press “Stop sharing”, turn live location for travel or travel nudges off, or the journey is over. Nothing is kept for a journey nudges are not watching, and, on the operator’s own account, nothing near the home the operator configured. Never written to a log.
• Title-category cache — server memory.Capped at roughly 500 entries per server process, keyed to an identifier issued at each sign-in, holding a title, its inferred category, and the model’s one-line reason. No fixed expiry: at the cap the oldest entry is dropped for each new one, and everything is erased on server restart.
• Write-deduplication records — server memory, 10 minutes.After a confirmed write, the created event’s ID and its Google Calendar link are remembered briefly (at most 10 minutes) so a retried request cannot create a duplicate.
• Write-decision records — server memory. Each confirmed, automatic, or refused calendar write adds a small content-free record (internal draft ID, the kind of write, decision, for an automatic change or removal how serious it was judged, and timestamp — never event details) to a buffer capped at 200 entries, kept for debugging the confirmation safeguards. For keeping travel blocks current, these records are kept in our database instead (previous items).
• Autopilot activity — server memory, 24 hours. The IDs of events autopilot changed or removed for your account, at most 20, with no titles or times, so the You tab can list what happened and offer to put a removed event back. Each entry is dropped after 24 hours or when the server restarts, whichever comes first; no other account can read it.
• Travel estimates and map positions — request lifetime only.Location text, the travel times worked out from it, and the rounded positions sent to your browser for the week map and the Trip room’s map (Section 3.5) are held while a request runs and discarded when the response is sent — apart from checked routes, below.
• Weather forecasts — server memory, 10 minutes.Up to 200 hourly forecasts, each keyed by a coordinate rounded to about 1 km, with no account, name, or event attached. Each expires after 10 minutes.
• Checked routes — server memory, an hour (seven days with no set time), only where an operator turns route checking on.For the operator’s own account only: each checked trip’s travel time and the kinds of travel it used, as numbers (never Google’s description of the route), keyed to the account’s email address, to the trip’s two places on a 100-metre grid, and to its time in 15-minute steps; bounded in number, and each is not used after an hour (seven days for a trip with no set time; a failed check after one minute) and is deleted the next time route checking runs, or when the server restarts. Alongside, each server instance keeps a count of each account’s trips checked for the current day (UTC), to enforce the daily limit; a past day’s count is deleted the next time a trip is checked, or when the instance restarts.
• Live train feed — server memory, 5 minutes. Where live train times are on (Section 3.5), the last answer read from each of the MTA’s subway feeds is kept, keyed by that feed’s address, so every trip planned in that span shares one request. It is the MTA’s public data: no account, event, time, or place of yours is attached to it. Each copy expires after 5 minutes.
• Address-lookup cache file — server disk, only if an operator configures it. Where address lookup is on and a cache file is configured (Section 3.5), looked-up location text, in normalized form, is stored with its coordinates and place name, not tied to any account. Found places stay until the file is deleted; not-found ones expire after 30 days.
• Rate-limit counters — server memory.Request counts for the parsing, trip-planning, and week-map endpoints, keyed by your account’s email address when you are signed in and by IP address otherwise, swept opportunistically and cleared on restart.
• Server restart clears everything server-side. Every structure above that lives in server memory is erased whenever the server process restarts. Nothing user-derived survives on our side, apart from your saved commute in the database, your travel-nudge data there if you turned nudges on (including, for at most 30 minutes, a square you shared with live location for travel), and the address-lookup cache file above where an operator has configured one.
• Provider-side handling.Data sent to Anthropic under Section 5 is processed by Anthropic under its Commercial Terms and Data Processing Addendum and is not used for model training; retention on Anthropic’s side is governed by Anthropic’s published practices, not by us. The same structure applies to Tavily for the research queries described in Section 5.4, to Google for API traffic, to Open-Meteo and (where address lookup is on) the OpenStreetMap Foundation or the New York City Department of City Planning for the travel lookups in Section 3.5, to Google for the route checks in Section 3.5 (where an operator turns them on), to the MTA for the live-feed reads in Section 3.5 (which carry nothing about you), and (where the map is on) to OpenFreeMap for the map requests your browser makes. Neon, Inc. stores the database on our behalf; deleting your saved commute, or turning travel nudges off, deletes the rows, and Neon’s own backups of the database are retained and expire under Neon’s published practices.

8. Who we share data with — the complete list

We share data with no one except the service providers required to run the product, each receiving only what its role requires:

• Google LLC— sign-in (OAuth) and the Calendar API itself. Google necessarily processes your requests to your own calendar. And, only on a deployment where the operator has turned route checking on, which is off unless explicitly configured (Section 3.5), and then only for the operator’s own account, its Routes API (routes.googleapis.com): the coordinates of a trip’s two ends — the shift or event being checked (or the workplace) and the commitment just before or after it — and the time of the trip, to check how long it takes. Never your identity, an event’s title, or address text.
• Anthropic, PBC— the AI flows itemized in Section 5 (plus, on a deployment where an operator has configured the Section 6.1 email capability, the operator’s own email excerpts), under terms that prohibit training on the data.
• Tavily, Inc. — only when the public-event research feature runs (Section 5.4): a search query derived from the draft event (title, location name, date). Never your identity, tokens, calendar contents, or images.
• Open-Meteo(weather forecasts) — only when a live trip plan includes a Citi Bike leg (Section 3.5): a coordinate rounded to about 1 km, to get the hourly forecast there. Never your identity, the time of your trip, or any calendar text. On by default; an operator can switch it off.
• OpenStreetMap Foundation(its Nominatim address-lookup service) — only on a deployment where the operator has turned address lookup on, which is off unless explicitly configured (Section 3.5): location text that matched no place the Service already knows — from your calendar, your commute setup, or the Trip room where that is on — to find its coordinates. Never your identity, or an event’s title or time.
• New York City Department of City Planning (its NYC GeoSearch address-lookup service, geosearch.planninglabs.nyc) — only on a deployment where the operator has chosen it for address lookup, which is off unless explicitly configured (Section 3.5): location text that matched no place the Service already knows — from your calendar, your commute setup, or the Trip room where that is on — to find its coordinates, sent from our server. Never your identity, or an event’s title or time.
• OpenFreeMap(Hyperknot Software Kft., Hungary; map tiles built from OpenStreetMap data) — only on a deployment where the operator has switched the week map on (the same switch lets the Trip room show a trip on a map), and only while you have the week map or a trip’s map open (Section 3.5). Your browser requests the map from tiles.openfreemap.orgdirectly, so OpenFreeMap receives your IP address, your browser’s user agent, our site’s address, and which map tiles you view — which reveals the area around your events, or around a trip you planned. Never your identity, calendar text, event times, event positions, or the places you typed into the Trip room or their positions. Its privacy policy states that it uses no cookies or tracking, keeps server logs without IP addresses except temporarily during a security incident, and may deliver content through Cloudflare.
• Our hosting provider (currently Vercel, Inc. for the hosted Service) — runs the servers, terminates HTTPS, and keeps standard infrastructure access logs (Section 3.4). It also provides the page-view counting described in Section 12, and so receives, for each page opened: the path, the referrer, a coarse device type and country, and a visitor identifier it derives on its own servers and rotates daily. It receives no calendar data, no account, and no cookie — there is none to send.
• Neon, Inc.(database hosting) — only where account storage is switched on: hosts the Postgres database, in the United States, that stores the commute setup you save while signed in (Section 7) — your commute answers and your account’s email address as their key — and, only if you turn travel nudges on where they are offered, the nudge data in Section 7 (event IDs and journey times, and your devices’ push subscriptions, and — if you turn live location for travel on — a 100 metre square for at most 30 minutes) — together with the sign-in record and the anonymous daily counters described in Section 7. Neon stores those on our behalf and receives nothing else: no event titles or places, no tokens, and none of your other requests.
• The operator’s own scheduler— only on a deployment where travel nudges are switched on: a script in the operator’s own Google account (Google Apps Script) calls our server every few minutes with a shared password, and our server answers with counts (how many nudges were due and sent). Nothing about you is sent to it or through it.
• The operator’s own scanner— only on a deployment where the Section 6.1 email capability is configured: the server exchanges a shared secret and message IDs with the scanner web app in the operator’s own Google account. Not applicable to the public Service.
• Your browser’s push service(Apple, Google, or Mozilla, whichever your browser uses) — only if you turn on push notifications: after the Service writes an event, removes one automatically, or makes a serious change to one (Section 4), it hands that push service one message containing the event’s title and time — and, for a move, the time it was at and, if the place changed, the new place, plus, where they apply, how many guests can see it and the names of anything on your calendar the new time runs into — addressed to your device alone; and, when you press “Send a test notification”, one test message to each of your devices that says only that notifications are working, with nothing from your calendar. Where the operator offers travel nudges and you turn them on, it also carries each nudge: only that it is time to get ready or to leave, and the time to leave by. Every message is encrypted for your device, so the push service cannot read it. Off unless you enable it; the push service delivers it to you and to no one else.

For completeness: live trip plans, and the bike estimates between your events where those are switched on, also download Citi Bike’s public station feeds (Section 3.5). That is a read of public data — nothing about you is sent — so Citi Bike is not a recipient of your data. Subway schedule estimates (Section 3.5) likewise use a copy of the MTA’s public timetable kept on our server and send nothing. Live train times are different, and we list them so they are not missed: by default, during live hours (on weekdays, 7 AM–9 AM, 11 AM–1 PM and 3 PM–6 PM, New York time), a live trip plan with a subway ride makes our server read the MTA’s public live feed (api-endpoint.mta.info). The request names only which group of subway lines’ feed to read — which follows from the trip’s lines — and carries no identity, event text, times or places; each server instance reads a feed at most once every 5 minutes and shares that answer across the trips it plans. An operator can switch it off (Section 3.5). Live location for travel, where it is on and you use it, sends your position to no one but our server, and only as a 100 metre square: your browser finds where you are its own way — on some devices by asking the browser maker’s or device maker’s location service, under their own terms — and the Service receives only the square (Section 3.5).

We do not sell personal information, do not share it for advertising of any kind, and do not provide it to data brokers. If a legal demand for user data ever arrives, we will disclose only what the law compels after reviewing the demand’s validity, and — unless legally forbidden — will tell the affected user. If the Service is ever acquired or merged, Google user data would be transferred only with your explicit prior consent, as Google’s policy requires; for all other data, this policy would continue to apply and you would be notified before any new policy takes effect.

9. Cookies and local storage

The Service sets only the cookies that sign-in requires — there are no advertising, analytics, or tracking cookies of any kind. That stays true now that page views are counted (Section 12): the counting stores no identifier in your browser at all, so it has nothing to keep in a cookie. The complete list:

• a session cookie (authjs.session-token, with a __Secure- prefix over HTTPS) — the encrypted container for your session and Google tokens; HttpOnly, SameSite=Lax, up to ~30 days;
• a CSRF-protection cookie and a callback-URL cookie used by the sign-in flow, with the same protections;
• short-lived (15-minute) cookies that exist only during the OAuth handshake itself.

Local storage holds at most five entries: the rejected-titles list and the confirmed-guesses list, both described in Section 3.3; if you complete commute setup, your commute answers (which may include an address you typed), also described there; when that commute came from or was saved to your account, a note of which account it belongs to (your email address), so the Service never shows one account’s commute to another account signed in on the same browser; and, if you save a place in the Trip room, your saved trip places (calmora.trip.places.v1: a short name and the text you typed for each, which may be an address, Section 3.3). If you turn on push notifications, your browser also installs the Service’s small background worker, which keeps a copy of the app’s own static files — code, icons, and an offline page — in your browser’s cache; none of that is personal. If you open the week map or a trip’s map, your browser’s ordinary web cache may also keep the map images and lettering it downloaded from OpenFreeMap, as it would for any website; neither map sets cookies or writes local storage. That is the entire client-side footprint.

10. Your choices and controls

• Revoke Google access (the master switch). Visit myaccount.google.com/permissions and remove Calmora. This invalidates the Service’s ability to touch your calendar even if a session cookie still exists somewhere. We say this explicitly because signing out alone clears your cookie but does not revoke the Google-side grant; for a complete disconnect, do both.
• Sign out.Destroys the session cookie in your browser — the only copy of your tokens — and removes the confirmed-guesses list from that browser. The rejected-titles list stays until you clear the browser’s site data.
• Delete events. Events the Service just created can be removed in-app through its preview-and-confirm flow; any event it created can always be deleted directly in Google Calendar, which you control.
• Delete your saved commute.Open the commute planner, press Change, then “Delete my saved commute”. That deletes it from your account (the database row, Section 7) and from this browser; your other devices lose their copy the next time they load. You can also change it at any time the same way. Signing out removes this browser’s copy of an account-saved commute but keeps it in your account, and revoking Google access does not delete it either — to remove it from our database, use the delete button (signed in) or email us.
• Turn travel nudges off.Where they are offered, switching “Travel nudges” off on the You tab deletes, at once, everything they kept in our database for your account: your upcoming journeys, the copies of your devices’ push subscriptions, and the record that you turned them on (Section 7). Turning notifications off on a device, or signing out there, deletes that device’s copy. Turning nudges off also turns off keeping travel blocks current and deletes its records. There is no separate account-deletion button; to have everything deleted, use these switches or email us.
• Turn off keeping travel blocks current.Where it is offered, switching “Keep my travel blocks current” off on the You tab stops it at once — no further move is worked out or made — and deletes the travel-block times, the moves waiting to be made and the record of past moves it kept for your account (Section 7). A block it already moved stays where it is; change it in Google Calendar if you want.
• Stop sharing your location.Where live location for travel is offered, “Stop sharing” on the journey deletes, at once, every square and time to leave kept for your account; switching “Live location for travel” (or travel nudges) off on the You tab does the same and stops the button being offered. You can also block location for this site in your browser’s settings; then nothing can be sent.
• Delete saved trip places.In the Trip tab, “Remove” deletes one saved place and “Remove all” deletes them all, from this browser — the only place they are kept. Signing out does not remove them.
• Clear corrections and browser copies.Clearing the Service’s site data in your browser removes the rejected-titles list, the confirmed-guesses list, this browser’s copy of your commute, and your saved trip places. It does not touch a commute saved to your account.
• Ask us. Email darwinhu64@gmail.com for access, deletion, or questions. The durable user data the server keeps is your saved commute, if you saved one, and your travel-nudge data, if you turned nudges on (we will send you a copy or delete them on request, from the address on your account), and the address-lookup cache file of Section 3.5, which, where one is in use, we will delete on request. Every other server-side trace of your use expires on its own or is erased when the server process restarts (Section 7); we will confirm, and will restart the server process to flush transient memory on request. For AI-provider-side data, we will relay requests to Anthropic where applicable.
• Export. The durable copy of your calendar stays in your Google account, so Google Takeout exports everything, including events the Service created.

11. Security

What protects your data here, concretely:

• all traffic is encrypted in transit (HTTPS, terminated and enforced by our hosting provider’s edge);
• your Google tokens exist only inside an encrypted (JWE), HttpOnly, Secure cookie — there is no server-side token store to breach;
• the database is reachable only from our server, over an encrypted connection, and each request can read or change only the signed-in account’s own rows — the key comes from your session, never from anything the browser sends; the one part of the server that reads across accounts is the travel-nudge scheduler, which answers only to a shared password sent in a request header, and reads only the journeys of accounts that turned nudges on;
• a strict, per-request Content-Security-Policy confines the browser to the Service’s own origin: no third-party scripts can load (the map library, too, is served from our own origin), scripted requests can reach only the Service itself — plus, only on a deployment where the week map is switched on (the same switch serves the Trip room’s map), the map-tile host tiles.openfreemap.org — and the one off-origin form action the policy permits is the sign-in form submission to accounts.google.com;
• security headers deny framing, MIME sniffing, and access to camera, microphone, and geolocation — the Service never asks your browser for any of those;
• our application logs are structurally incapable of carrying your content (Section 3.4), and calendar titles are never placed in request URLs, so the host’s standard access logs do not record them either;
• all user-provided and external text entering AI prompts is sanitized and fenced as untrusted data, and AI calls run with no tools and no ability to write to your calendar;
• every write to your calendar requires your explicit confirmation, except where autopilot has been switched on and the draft cleared every safety gate (Section 4); a change or removal, confirmed or automatic, refuses to touch anything the Service did not itself create, and an automatic one additionally needs the operator’s separate switch and a device of yours to notify.

No internet service can promise perfect security, and we do not. What we can promise: the attack surface here is unusually small because so little is stored, and if we ever learn of a breach affecting your personal information we will notify you and the relevant authorities as applicable law (including New York’s SHIELD Act) requires, promptly and plainly.

12. Do Not Track, and tracking generally

The Service shows no advertising, does not follow you across other websites, and does not allow other parties to collect information about your activities through it. It does count page views, and this section says exactly what that is rather than leaving it to the word “analytics”.

What is counted. For each page you open: which page it was, the site you arrived from if any, a coarse device type and country, and a visitor identifier that Vercel (Section 8) works out on its own servers and changes every day— so visits on two different days cannot be joined together, and none of it names you. It reads nothing from the page in front of you: no event, no title, no place, no address, no account. It sets no cookie and stores nothing in your browser (Section 9). The script and the measurement it sends both come from this site’s own address, so your browser contacts no other host to do it.

Do Not Track does something here. If your browser sends a Do Not Track header or a Global Privacy Control signal, the measurement is discarded in your browser before anything is sent — not reduced, not anonymised further: not sent. That check runs for every page view rather than once when the page loads, so a signal you switch on mid-visit takes effect immediately.

Counting page views therefore adds no other party to the list: the script and its measurement are our own address, so your browser still speaks to nobody else — with one disclosed exception, unchanged by any of the above. Where the map is switched on and you open the week map or a trip’s map, the map-tile host (OpenFreeMap, Section 8) necessarily receives your browser’s requests for map tiles, as any web server receives the requests sent to it; by its own privacy policy it sets no cookies and uses no tracking technologies.

13. Children

The Service is not directed to children under 13, and we do not knowingly collect personal information from children under 13. If you believe a child has used the Service, contact us at darwinhu64@gmail.com and we will delete what little may exist (Section 7 describes why that is at most a saved commute).

14. United States processing, and regional notes

The Service is operated from the United States and its servers process data in the United States; the providers in Section 8 may process data in other locations under their own terms. If you use the Service from elsewhere, you are sending your data to the U.S.

California:we honor CalOPPA’s disclosure requirements throughout this policy (categories collected: identifiers, calendar/schedule content, and location information — event locations and the commute details you enter — Section 3; third parties: Section 8; change process: Section 15; effective date: above). We are an individual developer and believe we are far below every threshold that makes the CCPA/CPRA’s obligations apply — but as a matter of practice we honor access and deletion requests from anyone, from anywhere (Section 10), and we do not sell or share personal information as those laws define those terms.

15. Changes to this policy

When our practices change, this page changes first: we will update the policy and its effective date before the new practice takes effect, and material changes (a new data category, a new third party, a new use) will be called out prominently on this page. If a change would expand how Google user data is used beyond what this policy discloses, it will not ship until this policy — and where required, our Google verification — has been updated to cover it. Continued use after the effective date constitutes acceptance of the updated policy.

16. Contact

Darwin Hu — Operator, Calmora
darwinhu64@gmail.com
New York, United States

See also our Terms of Service.