How Browser Extensions Handle Permissions (And Why Ours Are Minimal)

The manifest.json permission model

Every browser extension declares its permissions in a file called manifest.json. This is the contract between the extension and the browser. It lists exactly what the extension can access, and the browser enforces those boundaries. An extension cannot read a webpage it does not have permission for, cannot access cookies for domains it did not declare, and cannot use browser APIs it did not request.

There are two categories of permissions. Required permissions are granted at install time. The user sees them in the install dialog and must accept all of them to proceed. Optional permissions can be requested later, at runtime, and the user can accept or deny each one individually.

The problem is that most users do not read the permission list during installation. They click "Add to Chrome" and move on. That is understandable, but it means the permission model only works as a safety mechanism if someone reviews what was declared.

Common permissions and what they mean

tabs: Allows the extension to see the URLs and titles of open tabs. This sounds invasive, but it is necessary for any extension that needs to know which websites you have open. manyCalendars uses this to detect when you have a calendar tab open.

storage: Allows the extension to save data locally in the browser. This is how manyCalendars stores your calendar configuration and cached event data. The data stays on your device.

host permissions (specific domains): Allows the extension to read content from specific websites. manyCalendars requests access to calendar domains like calendar.google.com and outlook.office.com. This is narrowly scoped. The extension cannot read content from any other website.

<all_urls>: This is the nuclear option. It grants the extension access to every website you visit. manyCalendars does not request this. If you see an extension requesting <all_urls>, ask yourself why it needs access to your banking site, your email, and every other page you open.

cookies: Allows the extension to read and modify cookies for declared domains. This can include session tokens. manyCalendars does not request cookie access.

history: Allows the extension to read your complete browsing history. manyCalendars does not request this.

webRequest: Allows the extension to intercept, modify, or block network requests. This is used by ad blockers and privacy tools. manyCalendars does not request this.

What manyCalendars requests and why

manyCalendars's permission footprint is deliberately small. Here is the complete list:

tabs: To detect open calendar tabs and read their content for event syncing.

storage: To persist your calendar configuration and cached events between browser sessions.

Host permissions for calendar domains: To inject content scripts that can read the calendar DOM on Google Calendar, Outlook Web, and other supported calendar platforms.

That is the full list. No <all_urls>, no cookies, no history, no webRequest, no identity (which is used for OAuth flows). Every permission maps directly to a feature. Nothing is requested "just in case."

How to audit any extension's permissions yourself

You do not need to take any extension developer's word for it. Here is how to verify permissions yourself:

Chrome: Go to chrome://extensions, find the extension, and click "Details." Scroll down to see the full permissions list. You can also click "View in Chrome Web Store" to see the permissions listed on the store page before installing.

Firefox: Go to about:addons, click on the extension, and review the permissions tab. Firefox shows permissions in plain language, which is helpful.

Edge: Go to edge://extensions, click "Details" on the extension. The format is identical to Chrome.

Source code inspection: For any Chromium extension, you can view the actual source code. Navigate to the extension's installation directory (listed on the details page) and open manifest.json in a text editor. Every permission the extension can use is declared there. If it is not in the manifest, the browser will not allow it.

For extensions distributed through the Chrome Web Store, you can also use tools like Chrome Extension Source Viewer to read the source code before installing. This is the gold standard for verifying that an extension does what it claims.

The principle of least privilege

In security, there is a concept called "least privilege." It means that every component of a system should only have access to the resources it needs to do its job, and nothing more. It is simple in theory and rarely practiced in browser extensions.

Most extensions over-request permissions because it is easier. Requesting <all_urls> means the developer never has to update the manifest when they add support for a new site. Requesting cookies "just in case" saves a future optional permission prompt. These are convenience decisions that come at the user's expense.

manyCalendars follows least privilege strictly. If we add support for a new calendar platform, we add that specific domain to our host permissions and publish an update. Users see the new permission and can decide whether to accept it. It is more work for us, but it means you always know exactly what the extension can access.

Your calendar data is sensitive. The tool that reads it should ask for as little access as possible. Install manyCalendars and check the permissions yourself. We think you will be pleasantly surprised by how short the list is.