How to tell what a Chrome extension can actually do

Chrome's install dialog tells you what an extension can reach, in a sentence written to fit in a dialog. That sentence is doing a lot of compression, and the difference between two extensions with the identical warning can be the difference between one that reads a page you are already looking at and one that could read every page you ever open.

Here is how to close that gap in about two minutes, before you click Add.

1. Read the host list, not the verb

The broad warning is the one that scares people, and it is the one that means the least on its own. Chrome publishes the exact string each permission triggers, and "Read and change all your data on all websites" is what debugger, pageCapture, proxy, tabCapture and webAuthenticationProxy each display — five permissions with almost nothing in common, one sentence.

The dialog is lossy in the other direction too. Chrome's own permission warning guidelines note that some warnings disappear when paired with others: the tabs warning is not shown at all if the extension also asks for <all_urls>. So the dialog is a summary of a summary — reading it is not the same as reading what the extension declared.

What matters is the host list. On the Chrome Web Store listing, open Privacy practices; after installing, open chrome://extensions, click Details, and look at Site access. An extension that names two domains can act on those two domains. An extension that says On all sites can act everywhere, forever, including on your bank and your email.

Neither is automatically wrong. A tool that works with one website should name that website. A grammar checker legitimately needs everywhere. The question is whether the list matches the pitch, and a mismatch is the single most useful signal you can get for free.

2. Learn the four permissions worth a second look

Most permission names are boring. These four decide how much an extension could do if it wanted to:

• tabs — grants four fields on every tab rather than only the one in use: Chrome documents them as url, pendingUrl, title and favIconUrl, and the permission exists only to unlock those four. Many extensions ask for it out of habit when a host permission would have done the same job; it is the one a reviewer asks about first, and the one worth wondering about.
• scripting / content_scripts — runs the extension's own code inside a page. Scoped to the host list above, so this is only as broad as that list is.
• webRequest — observes network requests. Since Manifest V3, webRequestBlocking is no longer available to most extensions (enterprise policy-installed ones keep it), so an ordinary extension can watch but not block or rewrite — a much smaller power than it used to be. It still means the extension sees the addresses of requests on the hosts it covers.
• storage / unlimitedStorage — keeps data in your browser. Worth understanding as the opposite of a red flag: an extension holding a lot of data locally is an extension not holding it on someone's server.

The useful habit is not memorising these. It is asking, for each one: what would this tool have to do to work, and does the list contain anything beyond that?

3. Make the privacy policy be specific

The Chrome Web Store's privacy policy program policy requires any product that handles user data to post a policy disclosing how it collects, uses and shares that data, and all parties it is shared with. A reviewer checks that the policy describes that extension. You should apply the same test.

A policy that says "we may collect information to improve our services" describes nothing and commits to nothing. A useful one answers four questions in a form you can check:

1. What does it collect — named fields, not categories.
2. What leaves the device — and an enumerated nothing is a real answer, worth more than a paragraph about how much they care.
3. Who else sees it — every processor named, not "trusted partners".
4. What each permission is used for — one line per permission in the manifest.

If a policy covers a whole company's product line in one document, notice what that costs: a document written to cover N products has to be written to the union of them, so it describes the most invasive one and lets the rest hide behind it. That is why the policies here are one per extension — Redkeep's covers Redkeep and nothing else — rather than one document for the shelf, which holds only the account and the purchases.

4. Verify a "local-first" claim yourself

This is the part most people skip and it takes 30 seconds.

Open chrome://extensions, turn on Developer mode, and use the extension's own page or service worker link to open DevTools against the extension itself. Go to the Network tab and use the thing. Every request the extension makes appears there — hostname included.

An extension that says nothing leaves your browser should produce no requests to its own servers while you use it. If a "local" tool is talking to an API on every keystroke, the network tab says so immediately, in a way no amount of copy can talk you out of. Do the same at idle: leave it open for a minute and see whether anything phones home on a timer.

Two honest exceptions you will see and should not panic about: a request to the extension's own site to check whether you are signed in, and images loaded from a CDN that belongs to the website you are using anyway.

5. Check what happens at update time

Extensions update silently. A permission addition, though, cannot be silent: Chrome's rule is that a new permission that triggers a warning disables the extension until you accept it. So the check that matters over time is: when a re-authorisation prompt appears, read it rather than clicking through, because it is the one moment the platform makes an extension's growing reach visible.

It is also worth glancing at whether the publisher writes down what changed. A changelog is not proof of anything, but a publisher who cannot be bothered to say what shipped is telling you something about how the next permission will arrive.

Questions

Q: Does a small number of permissions mean an extension is safe? A: No — it means the platform is limiting the damage it could do. A short host list genuinely bounds the blast radius, and that is worth a lot, but "safe" also depends on what the code does inside those bounds. Permissions tell you the ceiling, not the behaviour.

Q: What is the single fastest check? A: Compare the site access list to what the extension claims to be for. A tool for one website that asks for all sites is the most common mismatch, and it is visible in the store listing before you install anything.

Q: Can an extension read my passwords? A: One with access to a site can read what is on that site's pages, including what you type into them. That is exactly why the host list is the thing to read: an extension scoped to two domains cannot see a page on a third, whatever it wanted to do.

Q: Is an extension that stores a lot of data locally a bad sign? A: Usually the reverse. Local storage is data that is not on somebody's server and does not travel — and it disappears with the extension when you remove it. What to look at instead is whether anything is also being sent somewhere, which the network tab answers in a way marketing copy cannot. Our own approach, and what each extension does and does not send, is set out on the shelf and in each extension's own policy.