Before You Install a Chrome Extension, Check Site Access
A Chrome extension's details page has two separate sections, Permissions and Site access. Across our own seven extensions the Permissions section was empty every time, so the only thing left to read was Site access. How to judge the reach by whether the feature needs it, rather than by counting permission names.
On this page
When you are deciding whether to install a Chrome extension, its details page offers two separate sections: Permissions and Site access. I checked all seven of the extensions we build, and the Permissions section was empty in every one of them. Everything worth reading was in Site access, further down.
The Permissions section is empty more often than not
At the top right of Chrome, select More, then Extensions, then Manage extensions, and open Details on the extension you care about. Opening chrome://extensions directly gets you to the same screen.
Between them, the seven extensions declare storage, scripting, contextMenus and activeTab. Not one of those produced a line in the Permissions section. Chrome's own documentation explains why that is unremarkable: activeTab "serves as an alternative for many uses of <all_urls>, but displays no warning message during installation."
So "the permissions list is blank, this one must be harmless" does not hold. A blank list is ordinary, not reassuring.
The same sentence can mean opposite things
Site access produced two wordings in this sample. Quoted as they appeared:
A — "Allow this extension to read and change all your data on websites you visit." The extension can run on every page you open. Four of the seven showed this.
B — "This extension can read and change your data on sites. You can control which sites the extension can access." This one is followed by a list of sites.
The three extensions showing B had nothing in common once you read that list:
- Safe Privacy Mask — fifteen sites, and it runs automatically on those
- Safe Night Check — one entry,
https://mail.google.com/* - Copy & Prep — the list is empty, because it uses
activeTaband ships no always-on content script
Reading the sentence is not enough. The list underneath is the part that carries the meaning.
Ask whether the reach fits the job, not whether it is large
Broad access is not evidence of bad behaviour. Anything that inspects what you are about to send has to be able to run on the page you are sending from, and four of our own extensions are in group A for exactly that reason.
The reverse is the useful signal: an extension with little to do with the page contents that still shows wording A is worth a look at the publisher's description and privacy policy. Does this feature need that reach? is a faster question than learning permission names one by one.
If you only need an extension in one place, you can narrow it before you start. Google's help says site access can be set to On select, On specific sites, or On all sites from the Details page. The same page carries a caveat worth keeping: granting or cancelling these permissions only affects sites matching the extension's host permissions, and extensions that change lower-level network access through VPNs or proxy settings are not affected by the change.
Notes: what I tested, and what the manifest will not tell you
What I tested on
- Chromium (the build bundled with Playwright, chromium-1234). Not Google Chrome itself
- Linux (WSL2), interface language set to Japanese
- The extensions were side-loaded as unpacked extensions. I did not check how a store-installed extension displays
- Screens collected on 2026-08-04, across seven of our own extensions. Comparing the screen against the manifest only works if you already know what the manifest says
- Because the test profile ran in Japanese, the English strings above are the ones Google's own help page and Chrome's documentation use, checked on 2026-09-12 — not text I read off my screen
The manifest will not tell you either
Safe Attachment Check declares no host_permissions at all, and it still showed wording A — character for character the same as Safe Privacy Gate, which does declare <all_urls> explicitly. The cause is the matches patterns in content_scripts; Chrome's documentation lists both host_permissions and content_scripts.matches as fields whose match patterns trigger a warning. How the two divide the work inside the manifest is something I laid out in a separate note on Manifest V3 structure.
Also, the count is not the count. Safe Privacy Mask declares thirty match patterns and fifteen appeared on screen: writing both https://chatgpt.com/* and https://*.chatgpt.com/* shows only the broader one. A short list does not mean narrow coverage.
What this does not tell you
- Whether the extension actually sends anything anywhere. Permissions describe what it is allowed to do, not what it does. Checking traffic is a separate exercise, and I wrote that one up in a note on the three things you can check
- The permission summary on a store listing, or the confirmation dialog shown at install time
- Seven extensions we wrote ourselves is not a sample to generalise from, so this is not a rule for which permissions are safe
References
- Google Chrome Help, "Install and manage extensions" (external) — how to manage extensions, the three site access settings, and the limit of what changing permissions affects. support.google.com/chrome_webstore/answer/2664769
- Chrome for Developers, "Declare permissions" (external) — both
host_permissionsandcontent_scripts.matchestrigger warnings. Last updated 2024-02-05. developer.chrome.com/docs/extensions/develop/concepts/declare-permissions - Chrome for Developers, "The activeTab permission" (external) — an alternative to
<all_urls>that displays no install-time warning. Last updated 2012-09-21. developer.chrome.com/docs/extensions/develop/concepts/activeTab
All three checked on 2026-09-12. The screens described are as of 2026-08-04.