webNavigation permission explained: what browser extensions see when you move around the web

Most of the permissions I write about are ones you can reason about by picturing the extension doing something to a page — reading it, rewriting it, blocking a request. webNavigation is different, and that's exactly why it's easy to miss. An extension can hold the webNavigation permission, touch no page, inject no code, and still watch every URL you open the instant you open it.

It's the quietest form of browser surveillance I know of. No content script running in the page, no network interception you could catch in DevTools. Just a passive feed of where you go, delivered live to the extension's background service worker. Let me walk through what it actually does.

The concept: a live feed of your navigation

Think of webNavigation as a subscription to your browser's own play-by-play. Every time a tab starts loading a page, commits to it, finishes it, or fails — the browser fires an event, and any extension holding this permission gets a copy.

You add it in one line of the manifest:

{ "permissions": ["webNavigation"] }

That's the whole ask. Chrome shows the user a single warning for it: "Read your browsing history." Same string you see for the history permission and for tabs — three very different powers hiding behind one sentence. I've dug into how the history permission reads your past, and how the tabs permission logs URLs going forward. webNavigation is the forward-looking one taken to its most granular extreme.

What the webNavigation permission actually allows

The API is a set of lifecycle events. For a normal page load they fire in order: onBeforeNavigate → onCommitted → onDOMContentLoaded → onCompleted, per the Chrome webNavigation reference. There's also onErrorOccurred, onCreatedNavigationTarget (a link opened a new tab), onReferenceFragmentUpdated (a #section change), and onTabReplaced.

Each event hands the extension a details object: the full url, the tabId, the frameId, a timeStamp, and — on onCommitted — a transitionType and transitionQualifiers. That last pair is the part people underestimate. It tells the extension how you got to the page: did you type the address, click a link, use a bookmark, hit reload, or go back? "typed" versus "link" is behavioral signal, not just a URL.

Here's a complete, functioning tracker. This is the entire extension:

// manifest.json permissions: ["webNavigation"]
// No host_permissions. No content scripts. Nothing injected into any page.
chrome.webNavigation.onCommitted.addListener((d) => {
  // Fires for every tab, the instant each page commits.
  log(d.url, d.transitionType, d.timeStamp);
});

Three things make this heavier than it looks.

It's real time, and it's every tab. You're not querying a database of the past like history does — you get a callback the moment a navigation commits, including in background tabs you're not even looking at.

It's the full URL, not the domain. Path and query string included. Query strings routinely carry search terms, document IDs, and sometimes session tokens.

It doesn't need host permissions. This is the big one. The webNavigation permission alone delivers URLs across every site — the API doesn't require <all_urls> or any host grant to see where you went. That's confirmed by both the Chrome permissions reference and MDN's webNavigation docs. So the mental shortcut a lot of people use — "if it doesn't ask to read and change data on all sites, it can't watch my browsing" — is wrong here. webNavigation slips underneath it.

The single-page-app blind spot

There's one more event worth its own paragraph: onHistoryStateUpdated. It fires when a page changes its URL through the History API — pushState and replaceState — without a full page load. That's how modern single-page apps work. Gmail, YouTube, your bank's dashboard, most SaaS tools: they swap "pages" client-side, and the browser never does a fresh navigation.

onHistoryStateUpdated means an extension sees those in-app moves too. On Gmail it can watch the URL change as you open a specific message thread. On a banking SPA it sees you switch to the transfers view.

No content script needed — the browser volunteers the new URL. So "it's an SPA, the URL doesn't really change" is not the protection it feels like.

Real examples: legit uses vs the concerning pattern

Plenty of good extensions need this. Tab and session managers use navigation events to track what's open and restore it later. Page-load performance tools time onCommitted to onCompleted.

Some privacy and security extensions watch navigations to warn you before a known-bad domain finishes loading. These are honest, documented uses — the API exists for a reason.

The concerning pattern is the mismatch: an extension whose stated job has nothing to do with knowing your full browsing stream, quietly subscribing to it anyway. And browsing streams are valuable.

A security researcher documented 287 Chrome extensions quietly sending browsing data from 37.4 million users to third-party analytics firms, as reported by The Register. Separately, Georgia Tech researchers ran over 100,000 extensions through an automated system called Arcanum and found more than 3,000 silently extracting user-specific data, none of it disclosed in privacy policies — detailed in their USENIX Security paper and study announcement. A live navigation feed is a clean, low-effort way to build exactly that kind of profile.

Risk assessment: when it's fine, when to pause

webNavigation on its own is capability, not proof of harm — the same point I keep coming back to in runtime behavior versus declared permissions. An extension that can watch your navigation may never send a byte anywhere. So judge it by fit.

Probably fine: a tab manager, a session saver, a page-timing or accessibility tool, a security extension — things whose core job obviously involves knowing what's loading.

Worth a pause: a wallpaper theme, a single-site helper, a simple converter, a cosmetic tweak — anything that has no reason to know your whole browsing pattern but declares webNavigation anyway. Pair that with an extension that also phones home a lot, and the passive feed has somewhere to go.

How to check your extensions

Open chrome://extensions/, click Details on anything you're unsure about, and read the permissions. Firefox exposes the same list on the add-on's detail page. Because webNavigation shows up as the generic "Read your browsing history" line, you can't tell it apart from history or tabs in the UI — but seeing that warning on an extension that clearly shouldn't need it is your cue to look closer.

To audit more than one or two at a time, look them up in the Extenshi catalog, which tracks permission profiles across Chrome, Firefox, and Edge listings and flags when an extension asks for more than its category peers. Or run your installed set through the permission scan and see which ones can watch where you go.

The permission isn't the problem — the use is

Browsers need webNavigation. Real tools depend on it, and the API is public and well documented. The problem is that it grants a live view of your movement across the whole web while wearing the same vague label as two milder permissions — and without the host-permission warning most people rely on as their tripwire.

Your extensions sit between you and everything you do online. webNavigation is one of the calmest-looking ways an extension can watch that happen. Worth knowing it exists, and worth a glance next time you hit "Add to Chrome."

Scan your extensions for webNavigation →

Sources

• Chrome for Developers — chrome.webNavigation API
• Chrome for Developers — Permissions list
• MDN Web Docs — webNavigation
• Georgia Tech — Study finds thousands of browser extensions compromise user data
• USENIX Security 2024 — Georgia Tech Arcanum study on extension data collection (Xie et al.)
• The Register — Security researcher finds 287 Chrome extensions leaking data from 37.4M users

This article is based on publicly available security research and news reporting. Extenshi does not independently verify all claims made by third-party researchers. References to specific companies or products reflect the findings of cited sources and do not constitute accusations of intentional wrongdoing. If you believe any information is inaccurate, please contact us at [email protected].