I run a Chrome extension. Its manifest requests the identity permission, a host permission scoped to my own Supabase backend, and, more importantly than either of those, a content script that runs on every http:// and https:// page you visit, which is what actually produces Chrome’s broadest “read and change all your data on the websites you visit” warning, not the backend host permission. I’ve written the full breakdown of what all of that is for elsewhere on this site. I’m naming it again here, up front, because a post whose whole argument is “judge extensions by their manifest, not their pitch” only earns the right to make that argument if it survives being pointed at its own author first.
With that said: here’s how to actually read a manifest, and what it shows when you apply the method to eight extensions people install every day, plus a self-critical look at where mine lands.
How to read any extension’s manifest yourself
The Chrome Web Store install prompt is a summary. The manifest is the source. A few things worth knowing before you compare the two:
- Permissions, host permissions, and content scripts are three separate declarations that can each independently trigger the same broad warning. An extension can look narrow in its
permissionsarray and still run on every page you visit because of acontent_scriptsblock with widematches, or ahost_permissionsentry of<all_urls>. Read all three, not just whichever one the install prompt happens to summarize first. - A declared permission is a ceiling, not a guarantee of use. Some extensions declare broad access in the manifest but ship a narrower default behavior, only exercising the full scope when you explicitly opt into a feature that needs it. That’s a real distinction worth checking for, not just assuming away, and it cuts the other direction too: a manifest that looks narrow on paper can still be doing something with the access it does have that you’d want to know about.
optional_permissionsandoptional_host_permissionsare a meaningfully different claim than the same access requested at install. A permission Chrome only asks for the moment you click a specific feature is a smaller, more accountable request than the same permission bundled into every install, even if the two end up granting identical API access once triggered.- Manifest V3 structurally forecloses one whole category of risk: extensions can no longer fetch and execute arbitrary JavaScript from a remote server at runtime. This isn’t a soft recommendation anymore, either: Chrome stopped running Manifest V2 extensions in 2025, and Google is delisting the remaining ones from the Web Store entirely on August 31, 2026. An extension that never migrated off V2 isn’t a “worth a second look” case by now, it’s one that either already doesn’t run or is about to disappear.
- If it’s open source, read the actual manifest.json in the repo, not a summary of it, including this post’s. If it’s closed source, the Chrome Web Store listing’s own permissions disclosure is the most reliable public signal available to you, thinner than source code, but still more precise than the feature description above it.
- A privacy policy that names exactly what leaves the device, and under what condition, is worth more than one that says “we may collect information to improve our services.” Vague policies are boilerplate regardless of how good the extension actually is.
- None of this is a one-time check. An extension’s ownership can change hands after you’ve already installed it, and a new owner can ship an update carrying new capability under the same name and the same install base. I get into what that looks like further down.
What that looks like applied to eight real extensions
I pulled the actual manifest for each of these, from the project’s own GitHub repository where the extension is open source, or from the Chrome Web Store’s own permissions disclosure where it isn’t.
| Extension | Permissions / host access | Broad access? | Justified? |
|---|---|---|---|
| uBlock Origin Lite | activeTab, alarms, declarativeNetRequest, offscreen, scripting, storage, unlimitedStorage, userScripts; host_permissions: <all_urls> | Declared broad, default narrow | Yes, and mostly unused by default. <all_urls> is the ceiling for its optional “Optimal” and “Complete” filtering modes; the default “Basic” mode blocks purely through declarativeNetRequest’s static rulesets and never reads page content unless you raise the mode yourself, per-site |
| Bitwarden | activeTab, alarms, clipboardRead, clipboardWrite, contextMenus, idle, offscreen, scripting, sidePanel, storage, tabs, unlimitedStorage, webNavigation, webRequest, webRequestAuthProvider, notifications; host_permissions: https://*/*, http://*/* | Yes | Yes. Autofill can’t work without reading the form fields on the page you’re on, and that could be any page |
| ClearURLs | <all_urls>, webRequest, webRequestBlocking, tabs, downloads, contextMenus, webNavigation, storage, unlimitedStorage (still Manifest V2) | Yes, on paper | This one is a cautionary example, not a “people install this every day” one. URL rewriting would justify the access if it still ran: this is a Manifest V2 extension, its maintainer explicitly closed the request to migrate to V3 as “not planned,” Chrome already stopped running it, and Google delists remaining MV2 extensions from the Web Store on August 31, 2026, ten days after this post went up |
| Privacy Badger (EFF) | alarms, declarativeNetRequest, privacy, scripting, storage, tabs, webNavigation, webRequest; host_permissions: <all_urls> | Yes | Yes. Detecting third-party trackers by watching which domains show up across unrelated sites is the mechanism, not a side effect of it. (Worth knowing as a reader: EFF’s own GitHub source file is an unbuilt MV2 template, not what’s actually published. The row above is the real shipped Manifest V3 permissions, pulled from the live Chrome Web Store binary, not the repo.) |
| Dark Reader | alarms, fontSettings, scripting, storage; host_permissions: *://*/* | Yes | Yes. Rewriting a page’s CSS to invert or dim it has no version that works on only some pages |
| GoFullPage | activeTab, scripting, storage, unlimitedStorage; optional_host_permissions: <all_urls>, file://*/* | Declared broad, opt-in | Matches the job. The install-time grant is narrow, activeTab only touches the tab you actively trigger a capture on. Broader access exists in the manifest but sits behind optional_host_permissions, meaning Chrome only grants it if a specific capture scenario (like a page containing iframes) actually asks for it, not on install |
| Vimium | tabs, bookmarks, history, storage, sessions, notifications, scripting, favicon, webNavigation, search; host_permissions: <all_urls> | Yes | Yes. Keyboard-driven navigation of every page needs to run everywhere, and the bookmarks/history access backs its own keyboard commands for jumping to a bookmark or a past page, not a separate feature bolted on |
| OneTab | tabs, activeTab, scripting, storage, unlimitedStorage, contextMenus, favicon (closed source; based on the live Chrome Web Store manifest, not a primary GitHub source) | No broad host access, but not nothing | Matches the job, with one permission worth actually reading: tabs grants the URL and title of every tab you have open, not just the one you act on, which is exactly the kind of thing this method exists to surface instead of assuming away from a feature description alone |
| Second Bookmark Bar (mine) | activeTab, bookmarks, storage, favicon, identity, alarms; optional tabGroups (requested at runtime only, not on install); host permission scoped to one Supabase domain; content script on http://*/* and https://*/* at document_start | Yes | Mostly, but the content-script scope is real. It’s what draws the bar and reads a dragged element’s details, and it’s genuinely broader than the bookmarks/storage/activeTab permissions above it, which is the honest reason this extension doesn’t rank at the top of this table |
A hypothetical free extension with <all_urls>, a bundled ad or analytics SDK, and a copy-pasted privacy policy | <all_urls> plus outbound calls to a third-party SDK domain | Yes | No, by design. This is the shape to watch for, not a specific product: broad access with no feature that obviously needs it, monetized through a network call the description never mentions, backed by a policy that reads like boilerplate rather than a disclosure |
A few things worth pulling out of that table rather than leaving buried in it. OneTab and GoFullPage have the least host access of anything here, neither asks for a single site it can reach freely, and that’s not an accident: a tab-list tool and a screenshot tool genuinely don’t need to see page content beyond what you act on, so they don’t ask for it. But “least access” isn’t the same as “no permission worth reading.” OneTab still declares tabs, which hands it the URL and title of every tab you have open at once, not just the one you click, and that’s a real, specific thing to know about a tool that otherwise looks about as narrow as this list gets. (If tab hoarding is the actual problem you’re solving, I’ve also written up how OneTab compares to Second Bookmark Bar if you’re deciding between the two approaches.) Bitwarden, Privacy Badger, Dark Reader, and Vimium are all broad at install and all justified, because the thing each one does structurally requires seeing every page: autofill, cross-site tracker detection, CSS rewriting, and universal keyboard capture don’t have a version that works on a subset of the web. ClearURLs would belong in that same group on manifest grounds alone, URL rewriting needs to see every URL, but it’s worth knowing that grounds is mostly theoretical now: it never migrated off Manifest V2, and Chrome stopped running MV2 extensions in 2025.
uBlock Origin Lite is the most interesting case, and the one I got wrong on first read. Its manifest genuinely declares <all_urls>, full stop, no asterisk. But that declaration is a ceiling for optional modes most users never turn on; the mode it ships active by default, “Basic,” blocks purely through declarativeNetRequest’s pre-compiled rulesets and never actually reads a page’s content unless you explicitly raise the filtering level on a given site. The lesson isn’t “uBlock Origin Lite has zero permissions,” which would have been wrong. It’s that a manifest tells you the maximum an extension could do, and you still have to check what it actually does by default before you know whether that maximum matters day to day.
And then there’s mine. Second Bookmark Bar doesn’t top this table, and it shouldn’t. The content script running on every page you visit is real broad access, full stop, and no amount of “it only reads elements when you drag them” changes what the manifest declares. That’s the same standard I’m applying to everyone else in this table, so it has to apply to my own row too, or the rest of this post is just marketing wearing a permissions audit as a costume. If you want the complete case-by-case walkthrough of what that content script does and doesn’t do with the access it has, that’s the full safety post, and if you’re specifically evaluating this on behalf of a company rather than yourself, there’s a security-reviewer version of the same disclosure written for that use case.
Permissions aren’t a one-time check
In February 2026, a Chrome extension called QuickLens, a “Google Lens” style search-screen tool with roughly 7,000 installs, changed ownership. It had been listed for sale on a third-party extension marketplace shortly after it was first published, and by February 1 it had a new owner operating under a different name, with a privacy policy swapped out for one hosted on what researchers described as a barely functional domain. On February 17, a new version shipped that added code to detect installed cryptocurrency wallets, including MetaMask, Phantom, Coinbase Wallet, and several others, and attempt to harvest the credentials needed to drain them. Multiple security researchers and outlets covered it as a documented supply-chain incident once it was discovered, not a rumor.
Nothing about that story required a manifest change most users would have noticed at the time. The extension’s install base, its name, and its listing were the same. What changed was who was behind it and what that new owner chose to ship. That’s the honest limit of everything above: reading a manifest tells you what an extension can do right now, from the people who currently control it. It doesn’t tell you who will control it a year from now, or what they’ll decide to add. Checking permissions once at install time is a reasonable habit. Treating that check as permanent isn’t.
What to do if your work Chrome blocks an extension
None of this audit matters if your employer’s Chrome policy blocks the extension outright before you ever see an install prompt, which is a separate, much more common situation than a genuinely risky manifest. If you’ve hit that gray “blocked by your organization” dialog, I wrote up what that block actually is and how the request-to-install flow works, including what your IT admin actually sees when you ask them to approve something. And if you’re the one on the other side of that request, deciding whether to approve an extension for a team rather than just for yourself, the permission-by-permission review written for that reviewer is the page built specifically for that decision.