I Had 22 Chrome Extensions Installed. I Had No Idea What Half of Them Could Do.

I did not realize how many Chrome extensions I had installed until I opened the extensions page and counted them one by one.

Twenty-two.

That number bothered me more than I expected.

Not because twenty-two extensions is automatically dangerous. Some of them were tools I used every day. Password manager. Screenshot tool. React DevTools. A grammar helper. A meeting helper. A color picker I forgot I had installed. A few little utilities that probably saved me time once and then quietly stayed in the browser for years.

The uncomfortable part was not the count.

The uncomfortable part was that I could not explain what half of them were allowed to do.

I knew what they were supposed to do from a user point of view. One helped me capture screenshots. One helped me inspect design colors. One changed how pages looked. One added buttons to websites. One helped with forms. But when I started checking permissions, the story became less friendly.

Some could read data on websites I visited. Some had broad host access. Some could inspect tabs. Some could inject scripts. A few had permission names that sounded harmless until I looked them up. A few had permission names that sounded terrifying even when the real behavior was legitimate.

That was the moment Extension Permission Monitor stopped being an abstract idea and became something I wanted for myself.

It is now live on the Chrome Web Store: Install Extension Permission Monitor.

I did not want a security lecture.

I wanted a simple answer:

What can these extensions actually do?

The browser gets messy slowly

The strange thing about browser extensions is that they rarely arrive all at once.

You install one because you need it for a task. Then another one for a project. Then a tool someone recommends. Then a developer extension. Then a design extension. Then a productivity extension. Then something you install just to test it.

Each install feels small.

After a year, your browser has become a little operating system of borrowed code.

That sounds dramatic, but it is basically true. Extensions can add UI, read pages, change network behavior, access browser state, store data, inject scripts, and listen to events depending on the permissions they request.

Again, that does not make them bad.

The best Chrome extensions are useful because they can sit close to your browsing. A password manager needs to interact with forms. A design tool may need to read colors from the current page. A meeting reminder may need to show UI while you are using another tab. Developer tools need access to page internals.

Capability is the point.

But capability without memory becomes risk.

I had installed extensions over time, and my memory of why I trusted them had expired.

The Chrome extensions page is not enough

Chrome already gives you an extensions page. You can go to:

chrome://extensions

From there, you can enable, disable, remove, inspect details, and manage site access for installed extensions.

That page is useful. It is also not designed to answer the question I had in my head.

I did not only want to know what was installed.

I wanted to know which extensions deserved my attention first.

If I have twenty-two extensions, I do not want to open each one, read the store listing, interpret permission warnings, search docs, and make a trust decision from scratch. That is too much friction. Most people will not do it. Honestly, I barely wanted to do it, and I build this stuff.

So I started writing down the kind of view I wished Chrome had given me:

• Show every installed extension in one list.
• Show the permissions in plain English.
• Separate low-risk utility permissions from broad website access.
• Highlight combinations that deserve attention.
• Let me ignore things that are clearly fine.
• Help me decide what to remove, disable, or keep.

That became the product shape.

Not a panic tool. Not a "your browser is infected" tool. A clarity tool.

Permissions are not readable enough for normal people

Permission names are written for developers and platform APIs, not for everyday review.

Take a few examples:

storage
tabs
scripting
cookies
history
webRequest
management
<all_urls>

Some of those sound harmless. Some sound dangerous. Some are dangerous only in combination with other permissions. Some are necessary for perfectly legitimate extensions.

storage is usually boring. It often means the extension stores its own settings.

tabs sounds like it can control everything, but depending on usage it may be about reading tab titles and URLs.

scripting can be necessary for extensions that inject code into pages.

<all_urls> is the one that makes me slow down because it can mean broad access across websites.

management sounds like a tool might manage the browser, but in the context of my extension it is used to read information about installed extensions. Chrome's chrome.management API exposes extension metadata like names, IDs, enabled state, permissions, host permissions, and install type. That is exactly what a permission monitor needs to explain the user's extension list.

The problem is that none of this is obvious from the raw words.

A non-technical user should not need to know Chrome API vocabulary before deciding whether an extension deserves trust.

That is the writing problem at the center of Extension Permission Monitor.

My first manual audit took too long

I tried doing the audit manually first.

I opened my extension list. I picked one extension. I opened details. I checked site access. I searched for what the permission names meant. I looked at the Chrome Web Store listing. I asked myself whether I still used the extension.

Then I repeated that again.

And again.

And again.

By the time I reached the tenth extension, I was annoyed.

By the time I reached the twenty-second, I had removed seven extensions and still felt unsure about a few I kept.

That is a bad workflow.

A good audit should not depend on motivation. It should make the next action obvious.

So I turned the manual process into a product checklist:

1. Read installed extensions.
2. Read their permissions and host permissions.
3. Classify the permissions by practical capability.
4. Convert technical permission names into plain English.
5. Surface the extensions with the broadest access first.
6. Give the user enough context to decide.

The goal was not to tell people what to do.

The goal was to make them informed enough to do it.

The first useful version was just a list

I did not start with a complicated dashboard.

The first useful version was almost boring:

const extensions = await chrome.management.getAll()
 
const visibleExtensions = extensions.filter((item) => {
  return item.type === 'extension'
})
 
const rows = visibleExtensions.map((extension) => ({
  id: extension.id,
  name: extension.name,
  enabled: extension.enabled,
  permissions: extension.permissions ?? [],
  hostPermissions: extension.hostPermissions ?? [],
}))

That list alone was revealing.

Seeing every extension with its declared capabilities in one place changed how I felt about my browser. It made the invisible visible.

Then I started adding interpretation.

For example:

function explainPermission(permission: string) {
  const explanations: Record<string, string> = {
    storage: 'Can save its own settings and local extension data.',
    tabs: 'Can access information about browser tabs, such as titles and URLs.',
    scripting: 'Can inject code into pages where it has access.',
    history: 'Can read your browsing history.',
    cookies: 'Can access browser cookies for sites it has permission to use.',
    management: 'Can read information about installed extensions and apps.',
  }
 
  return explanations[permission] ?? 'Uses a Chrome extension permission that needs review.'
}

This is not enough for a final product, but it was enough to prove the direction.

The value was not in inventing a perfect risk algorithm.

The value was in translating the browser's language into human language.

Risk is about combinations, not just individual permissions

The more I looked at permissions, the more I realized a simple red/yellow/green model would be misleading.

Some permissions are low-risk alone but more important in context.

An extension with scripting and narrow access to one domain is different from an extension with scripting and access to every website. An extension with tabs may be acceptable if it has a clear reason. An extension with broad site access, script injection, and network-related permissions deserves more attention.

So I stopped thinking in terms of scary permission names and started thinking in terms of capability bundles.

The question became:

What could this extension do if it used every permission it has been granted?

That phrasing matters.

Permissions do not prove bad behavior. They describe possible behavior.

A trustworthy extension can request powerful permissions for a good reason. A suspicious extension can request the same permissions for a bad reason. The user still has to decide whether the developer, product, and need justify the access.

A monitor cannot replace judgment.

It can improve judgment.

I wanted the copy to be calm

Security tools often make everything feel urgent.

I understand why. Fear gets attention. But fear also wears people out. If every extension is labeled dangerous, people stop listening.

I wanted Extension Permission Monitor to feel calm.

Instead of:

DANGER: This extension can read all your data!

I prefer something like:

This extension has broad website access. That can be normal for tools that work across many sites, but you should keep it only if you trust the extension and still use it.

That tone is less exciting, but it is more useful.

Most users do not need to be scared. They need to be oriented.

That is also why this first blog post matters. I do not want to market the product as a magic scanner that tells you what is safe. I want to explain the real habit behind it:

Every few months, look at what you have installed.

Remove what you do not use.

Pay attention to broad access.

Understand what permissions mean.

That habit alone makes your browser healthier.

What I removed from my own browser

During my manual audit, I removed seven extensions.

Not because I proved they were malicious.

I removed them for simpler reasons:

• I had not used them in months.
• I did not remember installing them.
• Their permissions were broader than their value to me.
• They duplicated features I already had elsewhere.
• The store listing did not give me enough confidence.

That last one is underrated.

If an extension asks for meaningful access, its listing should explain why. If the extension has broad permissions and the listing is vague, I get cautious.

This is not paranoia. It is maintenance.

You do not keep old apps on your phone forever. You do not keep unused SaaS subscriptions forever. Browser extensions deserve the same cleanup habit.

The product became live because the problem was real

Extension Permission Monitor is now live on the Chrome Web Store:

Install Extension Permission Monitor

That sentence still feels a little surreal because the product started from me being annoyed at my own browser.

The live version is not trying to be an enterprise security platform. It is a personal browser clarity tool. It helps you see installed extensions, understand their permissions, and think more clearly about what deserves to stay.

The first audience is people like me:

Developers, builders, designers, students, freelancers, and internet-heavy workers who install tools over time and forget how much access they have handed out.

If you only have five extensions, you may not need a tool for this.

If you have twenty-two, you probably do.

A five-minute habit I recommend

Even without my extension, you can do a quick audit today.

Open your Chrome extensions page and ask five questions:

1. Do I still use this extension?
2. Do I recognize the developer or product?
3. Does the extension need to work on every website?
4. Does the permission list match the feature it provides?
5. Would I install it again today?

That last question is the cleanest one.

Would I install it again today?

If the answer is no, disable it or remove it.

You do not need a dramatic reason.

Not using it anymore is enough.

What building this taught me

I thought the hard part would be technical.

The technical side was real. The Chrome management API has its own constraints. Permission data needs interpretation. Host permissions need special handling. The UI has to avoid making false claims.

But the harder part was language.

How do you explain a permission without exaggerating it?

How do you warn someone without scaring them away from useful tools?

How do you make a developer API understandable to someone who just wants to know whether a browser extension is worth keeping?

That is the product work.

The code reads extension data.

The product earns trust by explaining it honestly.

The bigger lesson

I used to think of browser extensions as small things.

A button here. A helper there. A shortcut. A convenience.

Now I think of them as software that lives very close to my daily work.

That does not mean I will stop using extensions. I love them. I build them. My own workflow depends on them.

But I want to be more intentional about them.

I want to know what is installed. I want to know what it can do. I want to remove tools I no longer use. I want permission language to be readable without opening five docs tabs.

That is why I built Extension Permission Monitor.

Not because every extension is suspicious.

Because trust is easier to maintain when you can actually see what you are trusting.

References

• Extension Permission Monitor on the Chrome Web Store
• Chrome extension permission documentation
• Chrome management API