Runtime tracking explained: what browser extensions do that their permissions never show

Here's a thing that took me embarrassingly long to internalize: the permission list an extension shows you at install time is a declaration of intent, not a record of behavior. It tells you what doors the extension asked for. It tells you nothing about which rooms it actually walks into, how often, or who it phones once it's inside.

I tend to obsess over permissions because they're the one thing the browser shows you up front. But a fresh academic study put a hard number on the gap between "what an extension asked for" and "what it does the moment it loads" — and that number is bigger than I expected.

The concept: declared permissions vs runtime behavior

When you install an extension, Chrome or Firefox shows you a list: "Read and change your data on all websites," "Read your browsing history," that kind of thing. Those strings come straight from the permissions and host_permissions fields in the extension's manifest.json. They're a contract the developer signs at packaging time.

Runtime behavior is different. It's everything the extension's code actually does once it's running in your browser — every network request its content script fires, every analytics endpoint it pings, every bit of page data it reads and ships somewhere. None of that shows up in the install prompt.

The trap is assuming the two line up neatly. They often don't. An extension can sit on a minimal permission set and still stream data about you to a third party, because the tracking happens in code the manifest never has to describe.

What runtime tracking actually looks like

Say an extension declares only storage and activeTab. Looks tame. On paper it can't read every site you visit. But the moment its content script runs on a page you've granted it, that script can issue a fetch() to any URL it wants — an analytics server, an ad network, the developer's own logging endpoint.

// Inside a content script — no special permission flags this
fetch("https://metrics.example-vendor.com/collect", {
  method: "POST",
  body: JSON.stringify({
    url: location.href,
    referrer: document.referrer,
    ts: Date.now()
  })
});

That request leaks the page URL, the referrer, and a timestamp. There's no host_permissions entry for metrics.example-vendor.com, because outbound fetch from a content script to a third party doesn't require one the way reading a host does. The permission prompt you saw at install never mentioned this endpoint, because it couldn't.

This is the core reason permission-only analysis misses things. I built a whole map of declared permissions across 308,000 extensions earlier, and it's genuinely useful for spotting over-asking — but it's a snapshot of intent, not a recording of behavior. Two extensions with identical manifests can behave completely differently at runtime.

The 1-in-6 number

This is where the new research comes in. A study called AXECC, published in ACM Transactions on Privacy and Security in 2026, built the first fully automated framework for benchmarking what extensions actually do — combining static analysis, dynamic (runtime) analysis, and accessibility checks across real web pages.

The researchers ran it against 21,000 real extensions from the Chrome Web Store. The headline finding: 15.97% of them engaged in some form of third-party tracking within the first 60 seconds of loading. The study notes those extensions collectively reach more than 600 million users. (AXECC, ACM Transactions on Privacy and Security, 2026).

Roughly one in six. Tracking, in the first minute, before you've really done anything. And the study found these behaviors correlate strongly with extension category and stay consistent across different pages — so it's not random noise from a handful of bad actors. It's a structural pattern.

The AXECC authors also flagged a smaller group — extensions reaching about 65 million users — that alter a page's accessibility while you browse, and those alterations tended to come bundled with more complex tracking. The point I'd pull out: the static manifest told you almost none of this. You only see it by watching the extension run.

Risk assessment: when it's fine and when it isn't

Tracking inside an extension isn't automatically malware. Plenty of legitimate extensions phone home for boring reasons — crash reporting, feature-usage stats, license checks. The presence of a network request doesn't mean someone's building a profile to sell.

So how do I think about it? A few rough lines:

Probably fine: an extension hits its own domain, the data is plausibly tied to a feature you use, and the privacy policy actually describes it. A password manager syncing your vault. A grammar tool sending text you typed into its box.

Worth a closer look: the extension contacts third-party analytics or ad domains that have nothing to do with its stated job. A PDF converter pinging an ad network on every page load doesn't need to do that to convert PDFs.

Concerning: tracking that fires regardless of whether you're using the extension, on pages unrelated to its function, especially when it's shipping full URLs or page content. That's the pattern the AXECC study describes as kicking in within 60 seconds — running whether or not you asked it to do anything.

The hard part is that you can't tell which bucket you're in by reading the permission list. The behavior and the declaration live in different places.

How to check your own extensions

You don't need an academic framework to get a useful read on this. A few things I actually do:

1. Watch the network tab. Open Chrome DevTools, go to the Network panel, load a page, and filter for requests you don't recognize. If an extension is phoning a third-party domain on every page, it shows up here — the closest thing to the dynamic analysis AXECC automated.

2. Read the privacy policy for runtime claims, not just permissions. Does it name the analytics or ad partners it shares data with? Vague policies that disclose data-sharing in the abstract are a known pattern — I dug into how that "disclosed but hidden" trick works and it's worth understanding before you trust a tidy permission list.

3. Cross-check the permission footprint against the function. If a screenshot tool wants host_permissions for all URLs, the mismatch itself is a signal — even before you get to runtime. My breakdown of the all-URLs host permission covers when that ask is justified.

4. Lean on behavioral scanning when you can't watch every request yourself. This is exactly the gap Extenshi's catalog tries to close — looking at what extensions do, not only what they declare.

The takeaway

The permission prompt is the start of the conversation, not the end of it. The AXECC research is a good reminder that a clean-looking manifest and a tracker-on-load extension can be the same extension. If you've been judging your add-ons purely by the scary-string list at install time, you've been reading the menu and skipping the meal.

I'm not saying panic over every network request. I'm saying the install prompt was never designed to show you this layer, so you have to go look for it — or use a tool that looks for you.

Check what your extensions actually do at runtime, not just what they asked for. Check your permissions →

You can also browse security and privacy reports for specific extensions in the Extenshi catalog.

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].