What Browser Extensions Can Actually See on a Team Laptop

The shared laptop the social team posts from picks up extensions the way a coat picks up lint. A screenshot tool from a client review. A grammar checker from a hiring push. A scheduler left from a trial. Nobody remembers approving most of them, and the browser will tell you what each one can do, if you know which screen to open.

A different exposure than sharing a password

This is not about who holds a login. If two people know a brand account password, the exposure is a credential: it grants access when somebody chooses to use it, and it can be rotated. We covered that surface in sharing brand account access without sharing a password.

An extension permission is a different mechanism. It is code inside the browser, and its access does not depend on who is logged in or on anyone invoking it. If an extension holds broad site access and ships a script that runs automatically, that script runs when the page loads. Rotating a password does nothing to it. Removing a teammate does nothing to it. The permission is the only lever.

What a browser extension can actually ask permission for

Chrome’s developer documentation defines host_permissions as match patterns that “give access to one or more hosts”. The user-side view is blunter. Google’s Chrome Web Store Help article describes a control on each extension’s Details page labelled “Allow this extension to read and change all your data on websites you visit”, with site access settable to “On select”, “On specific sites”, or “On all sites”. The first grants access “when you select the extension”. The third allows an extension “to automatically read and change data on all sites”.

Automatically is the operative word. Chrome documents content scripts as files “that run in the context of web pages” which “are able to read details of the web pages the browser visits, make changes to them”, and static declarations as being “for scripts that should be automatically run”. All-sites access plus a static content script puts the extension’s code on the page before anyone touches the toolbar icon.

Firefox exposes the same model through different furniture. Mozilla’s Extension Workshop states that Firefox “displays a message showing what permissions an extension is requesting when it’s installed”, and lists “Access your data for all websites” as the message a broad host permission triggers.

How to check what is already installed

Do this on the actual machine. An inventory of what people think they installed is a different artifact.

  • Chrome, list view. Open chrome://extensions. You get every installed extension, enabled or not.
  • Chrome, per extension. Select Details and find the site access control. Google’s help article documents the three settings as “On select”, “On specific sites”, and “On all sites”, and elsewhere describes that first one as “When you select the extension”. Same position in the menu, same setting.
  • Chrome, narrowing without removing. Under “Permissions”, Google’s article says you add a site to the right of “Allowed sites”, switching to “On specific sites” first if the Add option is missing. The extension stays installed.
  • Firefox. Open about:addons, which Mozilla’s Extension Workshop calls the “Add-on manager”. Its controls sit behind the gear menu at the top, the one Mozilla points developers at when it says “open about:addons, click the gear icon, and click Check for Updates”. Open an add-on there to see what it has been granted. MDN states that “Starting with Firefox 84, users can manage optional permissions of installed extensions from the Add-ons Manager”. One honest limit: the literal “Manage Extension” and “Permissions” tab labels could not be confirmed from a machine-readable Mozilla source on 6 September 2026.
  • Repeat per browser and per profile. Extensions install into a profile, not a machine. A laptop running Firefox plus two Chrome profiles is three separate lists.

The categories that pile up on a social team’s laptop

These are categories, not a ranking, and nothing below recommends or compares one tool against another. Each example comes from that extension’s own Chrome Web Store listing, fetched 6 September 2026. Note what the store’s privacy panel is: a developer’s declaration about data handling, not a printout of host permissions.

  • Grammar and writing checkers. Grammarly’s listing, last updated 2 September 2026, says the extension “handles the following” and names five categories: Personally identifiable information, Personal communications, Location, User activity, Website content.
  • Scheduling and posting helpers. No example is named here, deliberately. This is the category the publisher of this site competes in, and naming one vendor’s disclosure while skipping the publisher’s own would be the wrong shape. Run this check against whichever scheduling extension your team installed, RecurPost’s included.
  • Screenshot and annotation tools. The listing for Awesome Screen Recorder & Screenshot, last updated 3 August 2026, names one: Website content.
  • Ad account and analytics companions. Meta Ads Data Advisor’s listing, last updated 3 September 2026, names three: Web history, User activity, Website content.
  • Link shorteners. Category members do not all declare the same thing. Bitly’s listing, last updated 22 July 2026, carries the opposite disclosure: “The developer has disclosed that it will not collect or use your data.”

The Bitly line is the useful one, because it shows the field is capable of saying nothing is collected. When a listing instead names website content, that is the developer’s own published statement.

What broad host permissions expose in practice

An extension granted all-sites access runs in whatever tab is open. The browser does not distinguish a news article from a logged-in ad account, an analytics dashboard, or a scheduling tool with a client’s queue on screen. If the match pattern covers the tab, the script is in the page, reading what is rendered there, including what is on screen only because someone is authenticated.

Two caveats matter, and skipping either turns an audit into an accusation. Holding a permission is not evidence of using it badly, and nothing quoted here alleges anything improper about any of them. The permission screen reports capability, not conduct. It tells you what an extension can read, not what it transmits, where, or how long that is kept. Those answers live in the vendor’s own privacy documentation, and in a contract.

An audit workflow for a shared laptop

Picture a three-person team sharing one laptop for client posting. A routine pass would run like this.

List what is actually installed, from chrome://extensions and about:addons, in every profile on the device. Not from memory, and not from a Slack thread. The extensions nobody claims are the ones the audit exists to find.

Sort by breadth of site access and work down, so all-sites extensions are reviewed before anything limited to running when clicked. For each, decide whether it needs that scope, works narrowed to specific sites, or is not in active use. The last bucket gets removed rather than disabled, since a disabled extension is still installed and re-enables with one toggle.

Attach the recheck to something the team already does rather than a schedule that will be skipped. Onboarding and offboarding are the natural hooks: someone joining or leaving the shared device is already a moment when access gets reviewed.

Read next

If credentials are the open question, read sharing brand account access without sharing a password. For the same habit applied to measurement, see what your analytics tools can and cannot see.

FAQ

Can a browser extension read a page even if I never click its icon?

Yes, if its site access is set to all sites and it ships a statically declared content script. Chrome documents those declarations as being “for scripts that should be automatically run”, and Google’s help article describes the all-sites setting as allowing an extension “to automatically read and change data on all sites”.

Does removing an extension delete data it already collected?

No. Uninstalling stops future access from that profile but does nothing about what was already sent to the developer’s servers. Retention is not something the browser controls or reports, so the permission screen cannot answer it. That sits in the vendor’s own privacy disclosure.

Is this the same risk as sharing a login for a brand account?

No. Password sharing is about who holds an active credential, addressed by rotation and seat-level access, and covered in sharing brand account access without sharing a password. Extension scope is about what code in the browser can read regardless of who is logged in. Fixing one leaves the other untouched.

Do Chrome and Firefox show the same permission information?

Both expose it per extension, in different places and wording. Chrome puts site access on each extension’s Details page under chrome://extensions, in Google’s help article wording. Firefox shows the request at install time, in phrasing Mozilla’s Extension Workshop lists such as “Access your data for all websites”, with the Add-ons Manager at about:addons where MDN says optional permissions are managed afterward.

Sources

Store listings and platform documentation verified 6 September 2026. This is not Watchdog data and is not on the re-verification schedule. followedapp is published by the team behind RecurPost, and RecurPost is covered vendor #34 under the same rules as every other vendor.

Scroll to Top