How Browser Extension Security Reviews Work

Every extension you install passed a review. Here is what that actually means.

When you install a browser extension from the Chrome Web Store, Firefox Add-ons, or the Edge Add-ons marketplace, that extension has gone through a security review process. But what does that process actually involve? How rigorous is it? And what should you, as a user, take away from the fact that an extension is listed?

Understanding the review process helps you make informed decisions about which extensions to trust. It also explains why manyCalendars is designed the way it is: minimal permissions, no remote code, no server dependencies.

The Chrome Web Store review process

Google's review pipeline has two stages: automated and manual.

Automated scanning checks for known malware signatures, obfuscated code, and policy violations (like hidden tracking pixels or undisclosed data collection). It also verifies that the extension's declared permissions match what the code actually uses. An extension requesting "read all site data" but only using it on two specific domains will get flagged for over-permissioning.

Manual review is triggered for extensions that request sensitive permissions (like access to all URLs, browsing history, or identity information). A human reviewer examines the code, tests the extension, and verifies that the permission justification provided by the developer is legitimate. This is where most extensions get rejected or sent back for revision.

The timeline varies. Simple extensions with minimal permissions can clear review in 1-3 days. Extensions with broad permissions or complex functionality may take 1-2 weeks. Updates to existing extensions go through a lighter version of the same process.

Firefox Add-ons: a stricter approach

Mozilla's review process is generally considered more thorough than Chrome's. Every extension submission receives a human review, not just those with sensitive permissions. Reviewers examine the source code line by line for policy compliance.

Firefox also requires that all code be readable. Minification is allowed, but obfuscation is not. If a reviewer cannot understand what your code does, the extension gets rejected. This is a meaningful security guarantee: it means every listed Firefox extension has code that a human has read and approved.

The tradeoff is speed. Firefox reviews can take days to weeks, and updates often queue behind initial submissions. For developers, this means planning ahead. For users, it means a higher baseline of trust.

Edge Add-ons: the middle ground

Microsoft's Edge Add-ons store uses a process similar to Chrome's, which makes sense given that Edge is Chromium-based and many extensions are cross-listed. The automated scanning is comparable, and manual review is triggered by similar permission thresholds.

One notable difference: Microsoft applies additional enterprise-focused checks. Extensions that could affect managed device policies or interact with Microsoft 365 services receive extra scrutiny. This matters for manyCalendars because calendar syncing interacts with Outlook Web, a Microsoft 365 service.

How manyCalendars passes these reviews

manyCalendars is designed from the ground up to be review-friendly. Here is how:

Minimal permissions. manyCalendars requests only the permissions it absolutely needs: access to specific calendar domains (Google Calendar, Outlook Web) and local storage for saving your configuration. It does not request access to "all sites," browsing history, or identity information.

No remote code execution. Everything manyCalendars does runs locally. There is no fetching JavaScript from a remote server, no eval() calls, no dynamic code injection. The code in the extension package is the code that runs. Period.

No server dependency. manyCalendars does not phone home. There is no analytics endpoint, no telemetry server, no "anonymous usage data" collection. Your calendar data stays in your browser's local storage and nowhere else. This dramatically simplifies the security review because there is no data flow to audit.

Readable source code. manyCalendars's code is minified for performance but not obfuscated. Reviewers can (and do) read through the entire codebase. There are no hidden behaviors.

How users can verify extension safety

Beyond trusting the review process, there are steps you can take independently:

Check the permissions list. Before installing any extension, review the permissions it requests. Chrome, Firefox, and Edge all show these during installation. If a calendar tool is asking for access to your webcam, something is wrong.

Look at the developer's track record. How long has the extension been published? How many users does it have? Are there reviews mentioning suspicious behavior? A two-year-old extension with 10,000 users and no security complaints is a different proposition from a brand-new one with zero history.

Inspect network activity. Open your browser's developer tools, go to the Network tab, and watch what requests the extension makes. manyCalendars makes zero network requests (unless you have configured ICS feeds, in which case it fetches those specific URLs and nothing else).

Review the privacy policy. Legitimate extensions have clear, specific privacy policies that explain exactly what data they access and what they do with it. Vague language or missing policies are red flags.

Security is not a feature we bolt on. It is the architecture. manyCalendars was built local-first specifically so that the security story is simple, verifiable, and impossible to quietly undermine. See for yourself: install it, open DevTools, and watch it make exactly zero network requests. That is the kind of transparency that survives any review process.