Free and paid member access is currently at capacity. Approved members receive the current extension build. The waitlist is open for the next release of spots.
A browser warning tells you what an extension could do with a granted capability. It does not prove why the extension wants it, whether it uses that access narrowly, or what it sends elsewhere.
The useful review has three parts: read the manifest, match every permission to a visible feature, and compare actual data handling with the privacy policy.
Current manifest at a glance
The table below is based on the manyCalendars Manifest V3 file reviewed on August 25, 2026. Browser wording can vary by browser and version, so this article uses the manifest names rather than promising an exact prompt.
| Manifest entry | Current purpose | When it applies |
|---|---|---|
activeTab | Works with the tab the user deliberately chooses. | After a user action involving that tab. |
tabs | Finds and manages the chosen calendar tab and reads tab metadata needed to return to it. | While connecting or refreshing a selected source. |
scripting | Runs the calendar reader inside a chosen page. | Only where the extension has page access. |
storage | Keeps source configuration, recent results, health state, and preferences in browser storage. | For local extension operation. |
alarms | Schedules background refresh and maintenance work. | When an enabled feature needs a timed wake up. |
notifications | Shows browser or operating system notices for extension activity. | When the product needs to report a background result. |
The broad looking line is optional site access
The manifest includes https://*/* under optional_host_permissions. That declaration lets the extension ask for an HTTPS origin discovered at runtime. It does not grant every HTTPS site automatically.
manyCalendars uses runtime requests because calendar feeds and browser calendar sessions can live on different domains. When a user connects a source, the extension can ask for the relevant origin. If access is declined, that source cannot be read through that route.
This is still powerful access. On a granted origin, host access can support script injection and extension initiated requests. That is why the origin, purpose, and timing of the request should make sense to the person granting it.
One optional API permission
The current manifest lists idle as optional. The current code requests it only when the optional activity helper is enabled, so away time can stop counting. Declining it does not disable the core calendar view.
What the current manifest does not declare
As reviewed on August 25, 2026, the manifest does not declare the browser APIs named cookies, history, downloads, or identity. It also does not declare contextualIdentities.
That does not make page access harmless. A script running on an authorized calendar page can read information rendered in that page. It does mean the current extension has not requested those separate APIs. This distinction is more useful than a blanket claim that an extension “cannot access anything.”
How the signed in calendar bridge works
The extension reads a supported calendar page inside the browser profile where the user is already signed in. The provider password and authentication cookies remain in that browser context. In Firefox, the selected tab can also retain its existing Multi Account Container context without manyCalendars declaring the separate container management API.
Calendar information stays on the device unless the user enables Cloud Sync for selected sources. Cloud Sync sends selected calendar copies to the private web calendar. Busy only is the default; Full details is a separate source level choice. Cloud Sync is not end to end encrypted, so users should enable it only when they are allowed to copy that information to manyCalendars.
A short audit for any extension
- Start with the feature list. Write down what the extension says it does.
- Match every permission. If a permission has no clear feature, ask why it exists.
- Separate required from optional. Optional access should appear near the feature that needs it.
- Check the destination. Find out what stays in browser storage and what crosses to a server.
- Test removal. Confirm how to revoke site access, remove a source, clear local storage, and delete any cloud account.
- Respect managed policy. An employer can block installation or site access. Do not bypass that control.
A narrow product can still need strong page access. The responsible question is whether the access is requested at the right time, used for the stated feature, and paired with an accurate data boundary.
Browser vendor references
Want access when another spot opens?
Join the waitlist for the next free or paid opening. No extension access is granted by joining the list.
Join the waitlistManifest and product behavior checked August 25, 2026. Browser permission behavior can change, so verify the current store prompt, manifest, and browser vendor documentation before installation.