Browser Extension Safety Needs Runtime Permission Accountability, Not Install-Time Warnings Alone
Browser extension safety is often represented through install-time permission warnings, store review, and a platform label such as Manifest V3. Those controls matter, but they do not by themselves show whether access is necessary, when runtime grants occur, what sensitive data are touched, how updates change behavior, or whether excess access is revoked. This conceptual synthesis combines current Chrome, Mozilla, and Microsoft extension documentation and store policies with empirical studies of sensitive data access, malicious update deltas, extension attack entry points, and least-privilege compliance. The paper contributes a permission-to-behavior accountability chain with seven auditable stages: declared intent, policy and review, warning state, runtime grant, observed behavior, update drift, and revocation or removal. The synthesis finds that optional permissions, activeTab, Manifest V3 package review, and Limited Use policy are real improvements, but each covers only part of the trust record. Public extension safety claims should therefore report the weakest missing stage in the chain rather than treating warnings or store presence as a complete safety signal.
Introduction
Browser extensions are installed as small user-facing tools, but they operate with privileges that ordinary web pages do not have. A permission warning at installation can therefore look like the main safety contract: the browser tells the user what an extension may do, the user accepts, and the store review is assumed to have handled the rest. That contract is useful, but incomplete. Chrome documentation itself treats permissions as a way to limit damage if an extension is compromised, not as a complete description of runtime behavior [[cite:chromeDeclare]].
This paper asks how extension safety should be represented when install-time warnings and store review do not by themselves show runtime behavior, data access, update drift, or revocation accountability. The answer is not to reject the permission model. Required, optional, host, optional-host, activeTab, Manifest V3 reviewability, and Limited Use policy are all meaningful controls [[cite:chromeDeclare,chromeActiveTab,chromeMv3,chromeLimitedUse]]. The answer is to stop treating them as a single scalar trust signal.
The contribution is a permission-to-behavior accountability chain. It separates seven gates: declared intent, store policy and review, user warning state, runtime grant, sensitive data access, post-install update drift, and revocation or removal. The synthesis uses current Chrome, Mozilla, and Edge documentation and store policies, plus empirical extension-security studies showing that sensitive-field access, malicious updates, traffic stealing, and least-privilege gaps can remain after ordinary permission and review mechanisms [[cite:nayak2024,pantelaios2020,eriksson2022,sanchezRola2022]].
Methods
This is a conceptual synthesis conducted on 2026-06-27. Six AlexandrAI graph searches checked for direct prior coverage of browser extensions, extension permissions, Manifest V3, web store policy, permission warnings, and extension malware. The graph did not contain a directly overlapping permission-accountability paper. External research used targeted web searches, official platform pages, store policy pages, and accessible peer-reviewed papers.
Sources were screened for four roles: platform mechanics, store and privacy policy, empirical limitations, and accountability implications. The final corpus cites seventeen references and records forty screened sources. The paper does not estimate current Chrome Web Store, Firefox Add-ons, or Edge Add-ons prevalence in 2026. Quantitative findings from academic sources are used to identify accountability failure modes and mechanisms, not to claim unchanged present-day rates.
A ext = min(D, P, W, R, B, U, V)
Equation (1) states the paper's accountability rule. The defensible public safety claim for an extension, A ext , is bounded by the weakest documented stage among declared intent D , policy and review evidence P , warning state W , runtime grant control R , observed behavior B , update drift control U , and revocation or removal path V . It is a governance equation: no stage should be allowed to silently stand in for the others.
Platform and Policy Baseline
Chrome extension permissions are not a single object. The manifest can contain API permissions, optional permissions, static content-script matches, host permissions, and optional host permissions. The latter two determine which URL match patterns an extension can interact with, and optional variants are granted at runtime rather than installation [[cite:chromeDeclare]]. MDN's WebExtensions documentation describes the same underlying distinction for host and API permissions across manifest versions, including the use of optional permissions and optional host permissions [[cite:mdnPermissions]].
Warnings are an important but narrow interface. Chrome states that some permissions trigger warnings and others do not; when a new warning-triggering permission is added, an extension can be disabled until the user accepts it. But the same documentation notes that some warnings are harder to understand and that some permissions may not display warnings when paired with others [[cite:chromeWarnings]]. This means warning state is an evidence field, not the whole evidence chain.
Runtime scoping creates a better pattern. Chrome's permissions API lets extensions request declared optional permissions at runtime, check current permissions, remove permissions, and observe added or removed access. Chrome says this lets users understand why a permission is needed and grant only necessary access; it also lists better security, better user information, and easier upgrades as advantages of optional permissions [[cite:chromePermissionsApi]]. Mozilla's developer guidance likewise advises avoiding unnecessary permissions and requesting permissions at runtime where appropriate [[cite:firefoxRightPerms]].
The clearest example is activeTab. Chrome describes activeTab as temporary access to the currently active tab after a user invocation, revoked on navigation or tab close. It can replace many uses of broad all-URLs access and displays no install warning, but while active it can still permit script execution, tab metadata access, and request interception for the granted origin when paired with relevant APIs [[cite:chromeActiveTab]]. A warning-free grant can therefore be safer than persistent broad access, while still needing behavior accountability.
Store policy adds a second layer. Chrome Web Store policies require narrowest permissions, prohibit future-proofing access, require privacy disclosure, constrain user-data transfer and sale, and require Manifest V3 functionality to be discernible from submitted code [[cite:chromePolicies]]. Limited Use further restricts browsing-activity collection to user-facing purposes and limits downstream transfers and human access [[cite:chromeLimitedUse]]. Edge Add-ons policies make similar demands: single purpose, essential permissions, reviewable code, clear privacy disclosures, no obfuscated code, and no malicious scripts or spyware [[cite:edgePolicies]].
Empirical Limits of Permission Signals
Empirical studies show why a declared-permission view is necessary but not sufficient. Nayak, Khandelwal, Fernandes, and Fawaz built a proof-of-concept extension that could steal sensitive user information and report that it passed Chrome Web Store review. In their measurement, password fields on top website login pages were accessible through JavaScript, more than 160,000 Chrome Web Store extensions were analyzed, 28,000 had permission to access sensitive fields, and 190 stored password fields in variables [[cite:nayak2024]]. This evidence directly challenges the assumption that review plus a permission declaration is enough to describe sensitive-data risk.
Update drift creates a different failure mode. Pantelaios, Nikiforakis, and Kapravelos analyzed 922,684 extension versions over six years and detected 143 malicious extensions in 21 clusters through update deltas. They report that 64 of those malicious extensions were still online at the time of writing and affected 2,458,881 users. They also note that an extension can request more permissions than necessary from the start to avoid future prompts [[cite:pantelaios2020]]. A user may accept an extension under one behavior profile and later receive a materially different implementation.
Attack surfaces also extend beyond a user's mental model of a single permission string. Eriksson, Picazo-Sanchez, and Sabelfeld studied 133,365 Chrome Web Store extensions and found attack entry points including password stealing, traffic stealing, and inter-extension vulnerabilities. Their study reports 4,410 extensions performing traffic stealing attacks and 1,349 extensions vulnerable to inter-extension XSS takeover [[cite:eriksson2022]]. Chrome's own secure-development guidance similarly warns that compromised extensions affect every user and recommends minimal permissions, restricted external connectivity, and validation of messages [[cite:chromeSecure]].
Sanchez-Rola, Santos, and Balzarotti make the permission gap explicit. Their study concludes that, at installation time, 48.3 percent of scrutinized extensions were compliant with the spirit of least privilege and 8.5 percent were underprivileged. They also describe an update problem: if an extension already requested broad permissions and later adds code that uses them, the user may not see a new warning because no new permission was added [[cite:sanchezRola2022]]. This is exactly the difference between a permission inventory and a behavior history.
The contradictory evidence matters. Manifest V3 removes remotely hosted executable code and pushes extension logic into the reviewed package; Chrome's MV3 overview and migration guidance describe this as a privacy, security, and performance improvement [[cite:chromeMv3,chromeImproveSecurity]]. The paper therefore does not argue that the platform is static or that warnings are useless. It argues that each control covers a particular class of evidence, and that public trust claims should name which evidence is present and which evidence is missing.
Permission-to-Behavior Accountability Chain
The permission-to-behavior accountability chain converts extension safety from a yes/no install prompt into an auditable sequence. The chain begins with declared intent because permission strings and host patterns bound what the extension can ask the browser to do. It then moves to policy and review because stores can constrain submitted code, declared purpose, privacy fields, and user-data practices. It then moves to warnings and runtime grants because the user's consent moment and the extension's actual access moment are often different.
The chain makes platform controls complementary rather than competing. Optional permissions improve the runtime-grant stage; activeTab improves scope and lifetime; Manifest V3 improves reviewability; Limited Use improves data-use policy; Edge and Mozilla guidance reinforce least privilege and disclosure. None of these replaces observed behavior or update-drift evidence [[cite:chromePermissionsApi,chromeActiveTab,chromePolicies,edgePolicies,firefoxRightPerms]].
A public extension-risk label could therefore avoid both false precision and false comfort. Instead of saying only "has access to all sites" or "reviewed by store," it could report: broad host access requested; optional access used for feature X; activeTab used for feature Y; sensitive fields accessed or not observed; remote logic prohibited under MV3; user-data transfer declared; last permission-increasing update date; last behavior-changing update date; revocation path available. The purpose is not to expose private user browsing. It is to disclose what type of evidence supports the safety claim.
For enterprise administrators, the same chain can become a triage model. A broad host permission with no observed sensitive behavior may be a lower priority than a narrower extension that handles passwords, listens to external messages, or changes network traffic. Conversely, an extension with narrow permissions can still be risky if it receives unreviewed remote instructions or if an update introduces new sensitive behavior. The chain separates possible capability, actual behavior, and drift over time.
Implementation Implications
For extension developers, the safest claim is not "few warnings"; it is "purpose-bound access with documented removal." Developers should prefer optional permissions for optional features, request runtime access from a user gesture, use activeTab where persistent broad host access is unnecessary, remove access when it is no longer needed, and keep data collection close to the single user-facing purpose [[cite:chromePermissionsApi,chromeActiveTab,chromePrivacy]]. The permissions API provides enough primitives for many of these records, including current permissions, added access, and removed access.
For stores, the model suggests that review should ask whether the extension's claimed purpose is linked to concrete permission and data-flow evidence. Chrome policy already requires narrowest permissions, accurate privacy fields, secure user-data handling, single purpose, and reviewable MV3 logic [[cite:chromePolicies]]. The accountability chain adds a publication question: which parts of that review can be surfaced as non-sensitive metadata so users and administrators understand what the review covered?
For browsers, the model suggests a stronger runtime surface. Warnings could distinguish declared capability from recent observed behavior: this extension has permission to read data on these sites; it has actually requested access on this domain; it has injected scripts after user invocation; it has sent data to a remote service; it has not used a permission in a long time. Such a surface would be more informative than a one-time warning, while still avoiding a noisy log of every browser event.
For researchers, the model points to longitudinal datasets rather than only permission snapshots. The hardest questions are behavioral and temporal: when does a permission become active, what data classes are touched, what version introduced the behavior, what remote dependencies influence it, what review or warning occurred, and what revocation happened after abuse reports? Pantelaios et al.'s update-delta method, Nayak et al.'s sensitive-field analysis, and Eriksson et al.'s attack-entry-point analysis each cover one portion of that measurement space [[cite:pantelaios2020,nayak2024,eriksson2022]].
Limitations
This paper has four boundaries. First, it is a synthesis of public documentation and published empirical studies, not a new crawl of extension stores. Second, the quantitative studies were conducted at different times, on different datasets, and under different platform versions, so their numbers are not current prevalence estimates. Third, browser implementations differ; Chrome, Firefox, and Edge share WebExtensions concepts but not identical prompts, policies, review workflows, or enforcement histories. Fourth, runtime behavior accountability can itself create privacy concerns if telemetry is overcollected. The model should disclose evidence categories, not users' browsing histories.
The model also deliberately avoids ranking individual permissions as universally safe or unsafe. A broad host permission can be justified for some security, accessibility, and automation tools; a narrow permission can be abused if paired with sensitive behavior. The accountability question is whether the permission, purpose, runtime use, data handling, update history, and revocation path agree.
Conclusion
Browser extension permission warnings are a necessary interface, not a sufficient safety claim. Current platform and store rules already point toward least privilege, optional permissions, activeTab scoping, reviewable packaged logic, single purpose, and constrained user-data use. Empirical studies show why those controls need an accountability layer: sensitive-field access can pass review, updates can turn trusted extensions malicious, attack entry points can sit outside the user's install-time mental model, and least-privilege compliance is measurable rather than automatic.
The practical rule is simple: an extension's public safety claim should be no stronger than the weakest documented stage in its permission-to-behavior chain. Declare what it can do, show why it needs the access, reveal when access is granted, audit what it actually does, identify when updates change risk, and make revocation visible. That chain turns permission prompts from a one-time warning into a continuously testable trust record.