The Toolbar Census: Who Owns Your Browser Add-Ons?

Most software registers have a sensible shape. There is a finance system, a support desk, a password manager and a stack of subscriptions with renewal dates. Then there is the browser toolbar: a row of little icons that nobody remembers installing and everybody assumes someone else looks after.

As of November 2026, browser extensions are still software. They can read the page you are on, hold a session, change what you see and update without a change request. In a small UK team, that is enough to deserve a line in the register — even if the line is kept in a spreadsheet rather than a proper asset tool.

The toolbar is not a personal desk drawer

It is tempting to treat extensions as personal preference. A developer uses a JSON viewer, someone in marketing uses a screenshot tool, and the finance lead has a PDF pack that saves ten minutes a day. Fair enough. The problem starts when those tools touch shared accounts, customer data or a company browser profile.

An add-on that can 'read and change all your data on all websites' is not just a convenience. It may be able to see the contents of your CRM, your webmail and the admin pages you open. That does not make it malicious. It does make it software with access, and access needs an owner.

What to record — and what to leave out

You do not need a twenty-field form. A useful register needs enough to answer four questions: what is it, who wants it, what can it see, and when will we look again?

A practical set of columns looks like this:

• Add-on name and store link. The exact listing, not just the nickname people use in the office.
• Browser and profile. Chrome, Edge, Firefox or Safari; work profile or personal device.
• Named owner. A person, not a department. 'Marketing' cannot answer a question.
• Job it does. One sentence. If nobody can write it, that is a warning sign.
• Permissions. Broad categories are fine: page content, cookies, downloads, clipboard, history.
• Data it can reach. Webmail, CRM, finance system, nothing sensitive.
• How it updates. Automatic, managed by an admin console, or manual.
• Review date. Put it in the diary. Twelve months is a reasonable default.
• Removal notes. Sign-out steps, OAuth revocation, local data to clear.

Leave out the urge to catalogue every font or theme. The point is risk and ownership, not a museum of browser history.

Read the permission prompt properly

Most people click 'Add to Chrome' the way they click 'Accept cookies'. The permission screen is the only moment the add-on tells you what it wants. In 2026, the wording still matters.

Watch for extensions that ask to read and change data on all sites when the job only needs one domain. Look closely at access to cookies, history, clipboard and downloads. A screenshot tool may legitimately need to see the page; a grammar checker may not need your bank's website. If the permission list is broader than the job description, ask why. Sometimes there is a good answer. Sometimes the answer is 'we could use the web version instead'.

Updates are the quiet part

Browser add-ons update silently by default. That is convenient, but it means the tool you approved in January may not be the same tool in June. A new owner, a new permission or a new data-sharing clause can arrive without an email.

For small teams, full extension management may be overkill. A middle path works: use the browser's admin console or policy settings for managed devices, keep a short allowlist of approved add-ons, and check the store listing at review time. If the extension has changed hands or added permissions, treat it as a new request. The register is there to make that check normal, not to create a change board for every icon.

A quarterly sweep that fits in a lunch break

Once a quarter, export or screenshot the extension list from each managed browser profile. Compare it with the register. For every add-on, ask the named owner one question: 'Still needed?' If yes, check the permissions and move the review date. If no, remove it.

The sweep should take twenty minutes for a small team. If it takes longer, the register is too complicated. A shared spreadsheet with a date column is better than a perfect system nobody opens.

Removing an add-on without leaving crumbs

Uninstalling from the toolbar is step one, not the whole job. Sign out of the service, revoke the add-on's access in the provider's account settings, and clear any local data if the tool stored pages or credentials. If the extension was installed by policy, remove it from the admin console as well, or it will come back on the next sync.

Record the removal date in the register. That sounds bureaucratic, but it answers the question that always comes later: 'Did we ever get rid of that thing?'

Keep it boring, keep it owned

The best add-on register is not a security project. It is a short list with names next to it. Start with the browser profiles that touch customer data or finance, add the obvious tools, and give each one an owner and a date. The toolbar will keep changing. At least the team will know who is supposed to notice.