Your calendar is yours.
We could not read it if we wanted to.
What we cannot do
- We cannot see your events. Your calendars stay in your browser. There is no manyCalendars server with your calendar on it.
- We cannot sell what we never receive. No event titles, attendees, or calendar names reach us. The only things that cross the wire are your account email and license status, only when you sign in for a trial or paid plan.
- We cannot lose your calendar in a breach. We do not have it. A breach of us exposes the emails and license records of customers who signed in or paid. That is the entire list.
- We cannot hand it to an acquirer or a subpoena. There is no copy to hand over.
1. What "local" actually means
Where your calendar data lives
When people say a tool is "in the cloud," they mean your data gets copied to the company's computers. manyCalendars does not do that. Your merged calendar lives in your browser's storage, on your computer. Think of it like a notebook on your own desk instead of a filing cabinet at someone else's office.
What we can see: nothing
Your events, meeting titles, client names, and attendees never travel to us. There is no manyCalendars server that stores calendars, so there is nothing for us to look at even if we wanted to.
What crosses the network
| Situation | What connects | What it carries |
|---|---|---|
| Free plan, no account | Nothing to us | Zero requests to manyCalendars infrastructure. Not one. |
| Signed in or paid | License and trial checks to our backend | Your account email and your license status. Never event titles, calendar names, attendees, tab URLs, or usage data. |
| At purchase | Stripe checkout; license email via Stripe and Resend | Payment handled by Stripe; we never see your card number. Stripe processes billing, Resend delivers the license email, and Supabase runs the license API. None of them ever receive calendar data. |
| .ics feeds you added | Your own browser fetches URLs you chose | Direct from your calendar provider. We do not proxy, intercept, or see these requests. |
Subprocessors for calendar data: none. There is no calendar data to subprocess.
What a breach of us would expose
An attacker who fully compromised our backend would find the email addresses and license records of customers who signed in or paid. No calendars, no OAuth tokens, no credentials, because we hold none.
What happens when you cancel
Your calendar data does not go anywhere, because it was never with us. It stays in your browser, on your device, yours. We keep only your email and license record, deleted on request. And if this product ever shuts down, your merged view degrades gracefully: your source calendars were never moved or modified, so you lose a lens, not your data.
2. Permissions, decoded
You may have seen the Chrome warning "Read and change all your data on all websites" on other extensions. manyCalendars does not trigger it, because it requests no blanket host access at install. Here is the manifest, exactly:
"permissions": ["activeTab", "tabs", "scripting", "storage", "alarms", "notifications"]"optional_host_permissions": ["<all_urls>"]
At install, the extension cannot read any website. When you add a calendar, your browser asks permission for that specific site, in context, at the moment you add it. You can revoke any site's access at any time in your browser's extension settings. Because host access is optional and per-site, Chrome does not show the all-websites install warning.
activeTab: temporary access to the tab you are looking at when you invoke the extension, instead of standing access everywhere.tabs: lets Tab Sync find the calendar tabs you added by their URL and title. It acts only on those.scripting: injects the script that reads events from a calendar page, only on sites where you granted access.storage: keeps your calendars, events, and settings on your device.alarms: schedules feed refreshes and the periodic license check.notifications: shows event reminders as native browser notifications. With Privacy Mode on, reminders are restyled to a neutral look instead of branded manyCalendars notifications.
Not requested: history, bookmarks, cookies, webRequest.
Verify it yourself
The code ships unobfuscated: open the package and read it, what you see is what runs. The only minified files are the stock FullCalendar and ical.js libraries, identical to their published releases. Manifest V3 forbids remote code, and our content security policy allows scripts from the extension package only, so nothing can execute that was not in the store-reviewed bundle. To check the network claims: open chrome://extensions, enable Developer mode, click "Inspect views: service worker" under manyCalendars, open the Network tab, and use the app. You will see zero outbound requests to us on the free tier and a license check on paid. Do not take the store's word or ours. Check.
The famous extension scandals, Honey and The Great Suspender, depended on behavior hidden in code nobody could read. We removed that hiding place on purpose. If a release ever added host access or a permission that carries a Chrome warning, the browser would disable the extension until you re-approved it, it could not activate silently; if it added a network endpoint, it would show up in the Network tab within minutes. We designed this so that if we ever turned bad, you would catch us fast.
3. The questions people actually ask
Do I have to give an app full access to my calendar?
No. manyCalendars never shows you that screen. No OAuth grant, no API token, no standing access on Google's or Microsoft's side to steal, revoke, or abuse. Tab Sync reads the calendar tabs you are already signed into, inside your own browser, plus any .ics feeds you choose to add. The free tier does not even need an account.
It has a free tier. Am I the product? What does it send home?
manyCalendars makes money one way: subscriptions. No ads, no analytics, no telemetry, no affiliate injection, no data sales. The free tier is a limited version of the paid product, not a data-collection funnel. And this is not a policy promise: it is an architecture you can check. Free tier: zero network requests to us. Signed in for a trial or paid: the license check described in the table above. Data brokers routinely offer extension developers money for installed user bases. Our subscriptions are worth more per user than any such offer, so selling you out would be bad business as well as wrong.
Does using this violate my NDA or client confidentiality?
An NDA problem starts when client information is disclosed to a third party. Cloud calendar tools transmit your client's meeting titles and attendees to the vendor's servers. That is the disclosure your contract restricts. manyCalendars discloses nothing to anyone, including us: the extension reads the calendar tab your client's systems already show you, and the merged view lives in local storage on your machine. It is the same category as reading your own screen or keeping notes on your own laptop.
For lawyers: the Rule 1.6 "reasonable efforts" analysis for cloud tools centers on supervising the vendor who holds client data. Here there is no third-party custody to supervise. The surface that matters is the one your firm already secures: your device and your login.
Honest caveats: we are not your counsel, read your engagement letter. Local storage is only as safe as the device it sits on, so keep disk encryption and your lock screen on. We do not change your device-security obligations either way.
Will my company's IT block this? What do they need to approve?
On the calendar side, nothing, because manyCalendars never connects to your company's or your client's calendar system. No OAuth app, no API token, no admin consent screen, no connected-app entry for anyone to find, revoke, or audit. It reads the calendar tab your own logged-in browser already displays to you, and everything stays on your machine.
Honest caveat: your employer's or client's policy on installed browser extensions still applies. If your environment requires approval for extensions, get it. This page, and the one-pager below, are written to make that approval easy.
4. Compliance, honestly
SOC 2
No, manyCalendars is not SOC 2 certified. Here is why the question mostly does not apply: SOC 2 audits how a company safeguards customer data stored in the company's systems, its data centers, databases, and employee access. manyCalendars stores no customer calendar data. There is no manyCalendars cloud of your events and no employee who could access them. An audit of our calendar-data controls would be an audit of an empty room.
What we can offer your security team instead: the architecture on this page, the complete network table above, unobfuscated code you can read, a one-minute DevTools check, and a completed security questionnaire on request. For this architecture, most questions answer "not applicable, no data held." SOC 2 is planned if and when team size and revenue justify it. We will not pretend it is imminent.
GDPR and DPA
Your calendar contents are never processed on our servers, so for calendar data there is no hosting location, no international transfer, and no processor relationship. The processing happens on your device, under your control. What we do process server-side: the account email and license status of customers who sign in for a trial or pay. For that data we are a controller, lawful basis contract, retained while your subscription is active and deleted on request.
Will we sign a DPA? Yes. It covers the only personal data we process and cannot cover your calendar data, because we never receive it. It may be the shortest DPA your legal team reads all year. Details and the signable document: DPA / GDPR.
HIPAA and BAAs
We do not sign BAAs, and here is why that is the right answer rather than a gap: a business associate creates, receives, maintains, or transmits PHI on your behalf. We never receive or transmit your calendar contents, so there is no PHI custody to put under a BAA. Note that nothing is "HIPAA certified"; HIPAA has no certification. If your compliance office requires a BAA from every vendor regardless of data flow, this tool will not fit that checklist and we would rather say so than fake it.
CMMC, FedRAMP, government environments
We have not undergone a NIST 800-171 assessment and are not FedRAMP authorized. Nothing leaves your machine, but if your environment requires formal attestation, use a tool that carries it.
AI training
No AI trains on your events, because there is no server holding your events. Nothing is available to train on.
5. For your IT team
If your employer or client reviews extensions, hand them the facts in their format: exact permission list, complete network table, storage locations, zero marketing.
Hand this to your IT team → (printable one-pager)
6. Responsible disclosure and contact
Found a vulnerability in the extension, this site, or the license API? Email security@manycalendars.com with reproduction steps. We acknowledge within 48 hours, ask for a 90-day disclosure window, will not pursue researchers acting in good faith, and credit you in the patch notes with your permission.
General security questions: support@manycalendars.com · Data protection: dpa@manycalendars.com · Policies: Privacy, DPA / GDPR, Changelog