Chrome Permission Audit

Chrome webRequest & declarativeNetRequest permissions: why AI reading tools shouldn't need them.

What do webRequest and declarativeNetRequest do in Chrome extensions? Learn why ad blockers need network interception—and why an AI reading assistant usually shouldn't.

Best fit

Best for security reviewers checking whether an AI Chrome extension is intercepting browser network traffic or modifying HTTP headers.

Technical Manifest Audit

Permission specification & risk profile.

Review how Chrome enforces webRequest / declarativeNetRequest in Manifest V3 and how to tell legitimate user-triggered extensions apart from intrusive tools.

Risk level: HigherwebRequest / declarativeNetRequest
Chrome install-time warning
"Block content on any page" or "Read and change all your data on all websites"
Manifest V3 declaration
{
  "manifest_version": 3,
  "permissions": ["declarativeNetRequest", "webRequest"]
}
Legitimate uses vs. red flags
What to verify before granting this permission to an AI browser tool.

Legitimate AI reading uses

  • Ad blockers and privacy shields (like uBlock Origin Lite) filtering tracker requests
  • Developer debugging tools inspecting API headers or CORS rules

Red flags to watch for

  • A simple AI summarizer or reading extension asking for `webRequest` across all domains
  • Modifying outbound links or injecting affiliate tracking parameters into e-commerce requests
Step-by-step workflow

How to run this workflow in place.

1

Match network permissions to product category

Network interception belongs in ad blockers, VPNs, and HTTP debuggers—not in text summarizers or reading assistants.

2

Check host permission scope

An AI extension only needs host permission for its own backend API (to fetch AI responses) plus DOM access for the text you select.

3

Reject unnecessary traffic observers

If an AI extension requests `webRequest` without a clear developer-tooling reason, look for a cleaner alternative.

Key details

Why this approach works better than switching tabs.

How webRequest differs from normal API calls
An extension does not need `webRequest` to make normal `fetch()` calls to its own AI server. `webRequest` is specifically for observing or intercepting the browser's other network requests.
  • Normal AI extensions use `fetch()` inside their background service worker to talk to their own API endpoint
  • `webRequest` lets an extension observe URLs, query parameters, and headers of subresources loading across pages
  • Manifest V3 replaced most blocking `webRequest` uses with `declarativeNetRequest` to improve privacy
Why Vezz me keeps network permissions minimal
Vezz me's background service worker communicates strictly with the Vezz me API (`vezz-me-api.ithinkisee8.workers.dev`) when you ask a question or check subscription status.
  • No `webRequest` or `declarativeNetRequest` permissions requested
  • No third-party analytics SDKs or ad networks embedded in the extension
  • Outbound requests occur only when you trigger an answer or manage your account
Frequently asked questions

Common questions about chrome permission audit.

Does an AI Chrome extension need webRequest to talk to OpenAI or its backend?

No. Standard `fetch()` requests from an extension's service worker only require host permission for the destination API domain. They do not require `webRequest`.

Does Vezz me use webRequest?

No. Vezz me does not request `webRequest` or `declarativeNetRequest` and never observes your browser's network traffic.

Related workflows & guides

Explore connected pages.

Available for Chrome and Firefox

Ready to try this workflow on your own reading?

Install Vezz me free, highlight text on any webpage, and press your customizable shortcut (default: Ctrl+Shift+X or Cmd+Shift+X on Mac) to get an answer right beside the source.