Reading the Permissions Screen: A Practical Guide to Evaluating Any Browser Extension

Every browser extension install ends with the same screen: a list of things the extension is asking to do, an “Add extension” button, and a “Cancel” button. Almost everyone clicks past the list. It’s written in a way that makes it easy to — vague verbs, unfamiliar domain patterns, a wall of text between you and the feature you actually wanted.

That screen is also the most honest thing an extension will ever show you. It’s generated by the browser from the extension’s manifest, not written by the extension’s marketing team, and it discloses exactly what the code is allowed to do — before you’ve granted it a shred of trust. Learning to read it takes about five minutes and applies to every extension you’ll ever install, not just AI tools.

Two different kinds of permission

Chrome extension permissions split into two categories that get lumped together on the install screen but mean different things.

Host permissions control which websites an extension’s code can read and modify. This is what lets an extension see the text in a Gmail compose box, insert a button onto a page, or read data displayed on a site you’re visiting. Host permissions are usually shown as either a specific list of domains or the broad grant “Read and change all your data on all websites” — Chrome’s plain-language rendering of the <all_urls> pattern in a manifest.

API permissions control which browser features an extension can call, independent of any website — things like storage (save data in the browser), contextMenus (add right-click menu items), clipboardWrite, or tabs (see open tab titles and URLs). These say nothing about which sites the extension touches; they say what it’s allowed to do once it’s running.

A privacy-relevant install decision usually comes down to matching these two categories against what the extension claims to be for. A note-taking extension asking for host permissions on every website is worth a second look. A note-taking extension asking for clipboardWrite and storage is asking for exactly what a note-taking extension needs.

The permission that deserves the most attention: broad host access

“Read and change all your data on all websites” is the permission people react to most, and for good reason — it’s the broadest grant available. But broad isn’t the same as unjustified. The right response isn’t automatic rejection; it’s asking whether the extension’s actual job requires seeing every page.

Some categories of extension have a legitimate reason to request it:

• Ad blockers need to inspect and modify every page’s requests, because ads can appear anywhere.
• Password managers need to detect login forms, which can appear on any domain.
• Accessibility tools need to modify page content universally to add their features.
• AI writing or browsing assistants that work on arbitrary text fields — not just a fixed list of sites — need the same breadth, for the same reason: the product’s whole premise is “this works wherever you’re typing,” and a hardcoded site list would defeat that.

What separates a reasonable <all_urls> request from a concerning one isn’t the permission itself — it’s whether the extension is specific about what it does with the access once granted, and whether that’s checkable. A calculator extension requesting the same permission has no comparable justification, and that mismatch — not the permission in isolation — is the actual signal worth acting on.

This is the same reasoning covered in more depth in Privacy by Architecture, which walks through why Browsy specifically requests <all_urls> and — more importantly — what that permission does not let it do: it doesn’t grant the ability to transmit page content anywhere, and it doesn’t bypass the requirement that a background service worker, not a content script, is the only thing allowed to make an outbound API call.

Permissions worth a quick pause, and why

A handful of other permissions show up often enough to be worth recognizing on sight:

storage — lets the extension save data locally in the browser. Low risk on its own; almost every extension with settings needs it. Worth noting whether the extension uses storage.sync (backed up to your account, roams across devices) versus storage.local (stays on the one device) if that distinction matters for what’s being stored — an API key, for instance, is the kind of thing worth checking isn’t quietly synced somewhere you didn’t expect.

tabs — lets the extension see the titles and URLs of your open tabs, not just the active one. Reasonable for a tab manager or session-saving tool; harder to justify for something with no stated reason to know what else you have open.

webRequest / webRequestBlocking — lets an extension observe or intercept network requests made by pages you visit. Central to how ad and content blockers work; a much bigger ask for an extension whose stated purpose doesn’t involve blocking or rewriting network traffic.

clipboardRead — lets an extension read whatever is currently on your clipboard, not just paste what you put there. Rare to see a legitimate need for read access specifically, versus the far more common (and much less concerning) clipboardWrite.

None of these are disqualifying by default. Each one is a small piece of evidence you weigh against what the extension is for.

Checking what’s already installed

The permissions screen only appears at install time, which means most people never look at it again. Chrome keeps the same information available afterward:

1. Go to chrome://extensions.
2. Click Details on any installed extension.
3. The Site access section shows exactly which sites it can currently read and modify, and — for extensions using Manifest V3’s optional permissions — you can often narrow this yourself, restricting an extension to specific sites even if it originally requested broader access.

This is worth doing periodically, not just at install time, because an extension can request additional optional permissions later through an update, and Chrome will prompt you again when that happens rather than silently expanding access.

Verifying a permission claim, not just reading it

The permissions list tells you what an extension is allowed to do. It doesn’t tell you what it actually does with that allowance — for that, you need to check, not just read. Two tools do most of the work:

DevTools’ Network tab. Open it, use the extension, and watch where requests go. An extension that claims to process your data locally, or to send it only to a specific AI provider, should show requests going only to domains consistent with that claim. A request to an unfamiliar domain is the clearest possible signal that a claim and a behavior don’t match. This is the exact verification method described in What Is BYOK for checking whether a “bring your own key” tool is actually skipping its own servers, and it generalizes to any extension making any claim about where your data goes.

Public source, when available. Not every extension is open source, but when one is, the permissions in its manifest and the code that uses them are both inspectable. You don’t have to read all of it — searching the source for where a broad permission is actually exercised is usually enough to confirm it’s used for what’s claimed and nothing more.

Neither of these requires special technical skill beyond opening a panel that’s already built into the browser. The bar isn’t “audit the codebase” — it’s “spend two minutes confirming the extension’s own explanation holds up.”

A five-question checklist

Before installing anything, or as a periodic check on what’s already in your browser:

1. What does the extension claim to do? Read the actual description, not just the name.
2. Do the requested permissions plausibly serve that claim? A mismatch — broad access with a narrow stated purpose — is the strongest single signal.
3. If host permissions are broad, is there a specific explanation for why? “We need this because X” is different from no explanation at all.
4. Can you verify where data actually goes? DevTools’ Network tab, used once, tells you more than any privacy policy.
5. Is there a free-but-unaccountable angle? As covered in Why Most “Free” AI Extensions Aren’t Actually Free, a tool with no subscription and no obvious revenue model is sometimes monetizing through the same broad access you just granted — permissions and business model are worth reading together, not separately.

None of this requires distrusting every extension by default. It requires treating the permissions screen as information rather than an obstacle between you and the “Add extension” button — because, unusually for anything involved in a software install, it’s one of the few things in the whole process that isn’t trying to sell you on anything.

---

Curious what this looks like applied to a specific extension? Privacy by Architecture walks through Browsy’s own permissions line by line — what’s requested, why, and what each one is structurally prevented from being used for.