Manifest V3: Redefining Chrome Extensions
- Manifest V3 is a browser extension specification that replaces persistent background pages with ephemeral service workers for improved efficiency.
- It enhances privacy and security by restricting permissions, deprecating risky APIs, and enforcing a stricter Content Security Policy.
- Adoption has surged due to performance benefits, though developers face migration challenges and capability regressions in network control.
Searching arXiv for papers on Manifest V3 and browser extensions.
Manifest V3, commonly abbreviated MV3, is the current Chrome extension platform specification proposed to replace Manifest V2 (MV2). It was announced by Google in 2020, after earlier proposal work in late 2018 for Chromium-based browsers, with stated goals centered on privacy, security, and performance. MV3 is not merely a manifest-version increment: it reorganizes extension execution around service workers, narrows Content Security Policy (CSP), and replaces key imperative capabilities—most notably blocking webRequest—with a more declarative model. Empirical and qualitative studies portray MV3 as a consequential platform redesign whose effects are heterogeneous across extension categories: adoption accelerated sharply by 2024, many abuse-prone capabilities were reduced, yet substantial migration friction, capability loss, and new attack adaptations remain evident (Pantelaios et al., 2024, Polčák et al., 18 Jul 2025).
1. Historical positioning and policy objectives
MV3 emerged as Google’s designated successor to MV2 for Chrome extensions, with an announced shift in 2020 and an initial plan to phase out MV2 by January 2023. That deprecation timeline was later postponed to January 2025 following developer pushback and additional platform work (Pantelaios et al., 2024). A second study characterizes MV3 as the newest generation of the browser extension platform that Google began proposing in late 2018 for Chromium-based browsers, emphasizing secure, performant, privacy-respecting extensions while making it harder to build extensions that leak data or harm performance (Polčák et al., 18 Jul 2025).
The policy rationale is framed around three pillars. First, privacy: MV3 reduces open-ended access to request metadata and tightens host and execution permissions. Second, security: it removes or constrains APIs that historically enabled arbitrary code execution, traffic manipulation, and cross-origin exfiltration. Third, performance: it replaces persistent execution models with event-driven ones and shifts network mediation toward browser-enforced rule evaluation rather than per-request JavaScript interception (Pantelaios et al., 2024).
A central point of dispute is that Google’s communications promised preservation of MV2 capabilities “in spirit,” whereas the practical consequence was redesign or removal of important APIs, notably background pages and blocking webRequest, in favor of declarative and ephemeral models (Polčák et al., 18 Jul 2025). This suggests that MV3 should be understood less as a compatibility-preserving upgrade and more as a redefinition of the extension threat model and execution contract.
2. Architectural redesign and API re-scoping
MV3’s most visible architectural change is the replacement of persistent background pages with service workers. Under MV2, background pages provided long-lived execution and broad API access. Under MV3, service workers are ephemeral and event-driven: they wake on events and then terminate, aligning the extension platform with modern browser architectures and improving performance and memory usage (Pantelaios et al., 2024). The developer study adds that this shift forces state migration into browser-managed storage with asynchronous I/O, and requires reworking initialization, messaging, alarms, and logic that assumed continuity (Polčák et al., 18 Jul 2025).
A second major change concerns network control. MV2’s webRequest and webRequestBlocking allowed extensions to intercept and block arbitrary requests dynamically. MV3 instead introduces declarativeNetRequest (DNR), in which extensions pre-register rules enforced natively by the browser. The intended effect is to minimize runtime interception overhead, reduce access to raw request data, and limit abuse, but at the cost of real-time contextual decision-making, rule-cap expressiveness, and extension collaboration (Pantelaios et al., 2024). The qualitative developer evidence is consistent with this: DNR decisions must be precomputed, cannot depend on dynamic extension state in real time, and offer poor introspection for user-facing feedback (Polčák et al., 18 Jul 2025).
A third redesign concerns code loading and CSP. MV3 prohibits third-party JavaScript inclusion in extension contexts and tightens CSP by deprecating unsafe-eval. Executable code must be shipped with the extension. The allowed values highlighted for extension pages include 'self', 'none', localhost, and 127.0.0.1 (Pantelaios et al., 2024). This directly targets arbitrary code execution and remote code import, although later sections show that this does not close every route to page-context abuse.
The paper on the ecosystem summarizes several concrete API and manifest migrations:
| MV2 element | MV3 element | Reported purpose |
|---|---|---|
background_scripts |
service_workers |
Event-driven execution |
chrome.browserAction |
chrome.action |
API modernization |
chrome.extension.* |
chrome.runtime.* |
Deprecated messaging/background calls |
tabs.executeScript |
scripting |
Updated injection model |
webRequest / webRequestBlocking |
declarativeNetRequest |
Native pre-registered rules |
MV3 also constrains XMLHttpRequest and fetch through stricter CORS and context rules, makes host_permissions explicit, and narrows the scope in which content scripts run (Pantelaios et al., 2024). In combination, these measures reduce persistent background execution, runtime network interception, and unrestricted privileged cross-origin access.
3. Adoption trajectory and migration dynamics
The ecosystem study quantifies adoption from the announcement period through 2024 and reports a markedly non-linear trajectory. Before the 2023 pause, less than 5% of all extensions had transitioned to MV3 despite the announced deadline. By late 2023 and early 2024, however, nine out of ten new extensions—about 90%—were uploaded as MV3. Monthly adoption rates rose from roughly 2% in January 2021 to around 40% of new daily updates by the time the migration plan was paused (Pantelaios et al., 2024).
Migration was not monotone. The same study reports 3,128 extensions that had moved to MV3 and then reverted to MV2; of these, 84.7% remained online in the Web Store, while 15.3% were removed. The reported interpretation is that functional and review challenges accompanied the transition (Pantelaios et al., 2024). This is corroborated by developer testimony that service worker lifetime issues, API gaps, and execution-model differences made some MV3 ports fragile or incomplete (Polčák et al., 18 Jul 2025).
The 2025 developer study provides a more focused view on privacy- and security-related extensions. Among 1,110 selected privacy/security-related Chrome extensions, were MV3 and remained MV2 as of 2024-08-26. Large projects migrated more quickly near the deadline: 44 of 50 projects with more than 1 million users had migrated by August 2024 (Polčák et al., 18 Jul 2025). The study also notes deadline-linked pressure points, including removal of featured badges for MV2 after 2024-06-04 and disabling of MV2 in Chrome 127 by July 2024 (Polčák et al., 18 Jul 2025).
Migration effort varied substantially. In the malicious-extension conversion study, 89.6% of converted extensions required 20–200 changed lines of code, while 1.1% exceeded 10,000 lines because of large bundled libraries and code beautification artifacts; changes below 20 lines were rare (Pantelaios et al., 2024). Separately, developers reported that completed migrations often took days to a month, but some took multiple months, including one reimplementation done well in advance at “huge costs” (Polčák et al., 18 Jul 2025). A plausible implication is that MV3 adoption statistics alone understate the engineering cost distribution across extension classes.
4. Security and privacy effects
MV3’s security logic is grounded in reducing the extension attack surface. The ecosystem study evaluates APIs historically associated with vulnerable or malicious code and reports that 87.8% of APIs linked to malicious activity are removed or constrained under MV3 (Pantelaios et al., 2024). The strongest examples are dynamic code execution and privileged network access. eval appears in 87.8% of the malicious extensions studied, XMLHttpRequest in 65.8%, fetch in 60.3%, webRequest in 16.4%, and webRequestBlocking in 6.8%; MV3 deprecates unsafe-eval, restricts remote code inclusion, narrows cross-origin request contexts, and shifts request handling to DNR (Pantelaios et al., 2024).
These changes are security-relevant because they target several canonical abuse patterns. Limiting persistent background execution reduces long-lived covert activity and persistent state available to attackers. Strict CSP and shipped-code requirements obstruct supply-chain attacks and runtime injection in privileged extension contexts. Tightened host_permissions and more consistent CORS enforcement reduce arbitrary origin access and stealthy data exfiltration from privileged contexts (Pantelaios et al., 2024).
Privacy effects are similarly dual. On one side, stricter CSP, prohibition of third-party code in extension contexts, and reduced runtime inspection of raw network data curtail data hoarding and privilege misuse (Pantelaios et al., 2024). On the other side, the developer study reports that many privacy and security developers perceived little or no user-facing benefit, particularly where removed capabilities had previously enabled protective behavior. One respondent summarized the outcome as “running to stay in place,” with almost no user benefits unless something breaks or becomes unavailable (Polčák et al., 18 Jul 2025).
The relation between MV3 and malicious extensions is therefore not binary. The data support the narrower claim that MV3 reduces avenues for abuse; they do not support the stronger claim that MV3 eliminates abusive extensions or that all privacy/security tools benefit uniformly from the redesign (Pantelaios et al., 2024, Polčák et al., 18 Jul 2025).
5. Empirical analysis of malicious extensions and adaptation under MV3
A major empirical contribution in the 2024 study is the dynamic analysis of 517 confirmed malicious MV2 extensions compiled from historic Web Store data and prior reports. Malicious categories included click scam, ad replacement, user data analytics, credential theft, browser modification, and “other” such as crypto, mining, gambling, and phishing; many extensions carried multiple labels, and user data analytics dominated (Pantelaios et al., 2024).
The conversion pipeline built on the Extension Manifest Converter and augmented it to transform MV2 to MV3 by changing manifest_version to 3, replacing background scripts with service workers, migrating browser_action to action, updating CSP and host_permissions, adapting sandbox and related fields, replacing deprecated chrome.extension.* calls with chrome.runtime.*, and moving tabs.executeScript logic to scripting (Pantelaios et al., 2024). Converted extensions were then executed in automated Chromium sessions using Playwright, with recording and replay via Catapult to reduce redundant requests. Behavior was compared against baseline sessions without the extension, and manual validation included about 130 hours of code review, approximately 15 minutes per extension (Pantelaios et al., 2024).
The principal quantitative findings are stark. After direct conversion, only 154 of 517 malicious extensions remained functionally malicious under MV3, yielding
After applying the authors’ MV3-compliant proof-of-concept adaptation techniques, 290 of 517 retained harmful capabilities, yielding
Among successful MV3 runs in the reported subset, category-level outcomes were: user data analytics 123, browser modification 88, ad replacement 77, click scam 15, credentials stealing 2, and other 29 (Pantelaios et al., 2024).
The proof of concept is important because it identifies a residual attack channel consistent with MV3 policy. Although remote third-party JavaScript and unsafe-eval are disallowed in extension contexts, attackers can still use web_accessible_resources to expose a local script to matching pages, and that local script can inject a remote payload into the page DOM. The paper states that this chain of JavaScript inclusions can enable session cookie theft, credential compromise, and data exfiltration from page context (Pantelaios et al., 2024). This establishes a precise limitation of MV3: privileged extension-context remote code execution is constrained, but page-context script induction via extension-mediated resource exposure remains feasible.
A common misconception is that MV3’s tighter CSP alone prevents extension-enabled remote code attacks. The empirical result does not support that view. It supports the narrower conclusion that MV3 raises the bar and removes many abuse-prone mechanisms, while leaving exploitable pathways for adversaries willing to adapt (Pantelaios et al., 2024).
6. Developer experience, capability regressions, and contested functionality
The 2025 qualitative study analyzes developers’ experience through 33 meaningful replies collected from extension projects and WebExtensions Community Group participants between November 2023 and early February 2024 (Polčák et al., 18 Jul 2025). The responses depict a differentiated impact across extension classes rather than a uniform migration story.
Blocking webRequest is the pivotal point. Of 14 projects using webRequest, 3 were non-blocking and the remaining approximately 11 depended on blocking behavior. Some categories—such as proxy managers, page sanitizers, and some blockers—could migrate, sometimes with bugs or reduced introspection. Others could not retain essential functionality: an ad blocker, an authentication tool, and two cookie managers stated that migration was impossible because they needed to programmatically modify requests, and one blocker removed a feature that depended on blocking webRequest (Polčák et al., 18 Jul 2025). These accounts reinforce the formal limitation of DNR: rule-based, predeclared actions are not equivalent to context-sensitive request rewriting.
Service worker ephemerality generated a second class of regressions. Seven respondents described state handling as a general challenge, six said new solutions did not work well, and only one reported smooth migration (Polčák et al., 18 Jul 2025). Developers reported fragile lifecycles, unreliable startup on some messages, and burdensome re-architecture toward asynchronous storage. One workaround kept the MV3 worker alive using periodic local storage requests, explicitly characterized as an anti-pattern with energy and privacy trade-offs (Polčák et al., 18 Jul 2025).
A third issue concerns early content script execution. Many privacy/security tools need scripts to run before page scripts in order to modify web APIs or sanitize DOM. Browsers introduced scripting.RegisteredContentScript, but none of the six respondents with early-injection requirements were confident that their scripts ran in time under MV3, and two explicitly answered “No” (Polčák et al., 18 Jul 2025). The study also notes Firefox bug 1267027, which prevents injection via inserted script elements under site CSP and blocks some mitigation strategies; only one respondent weakened CSP to work around it, which the study characterizes as a risky trade-off (Polčák et al., 18 Jul 2025).
Storage and confidentiality form a fourth friction point. Because ephemeral workers push more state into browser storage APIs, two projects reported storing secrets such as cryptographic material and private-tab data in storage due to the absence of a secure-in-RAM or confidential storage API, raising privacy and security concerns (Polčák et al., 18 Jul 2025). Respondents therefore identified several “critical missing APIs,” including reliable early content script injection, secure/confidential storage, better DNR and webRequest introspection, a dedicated header-modification API, IP- and TLS-aware request controls, shadow-DOM search, DOM overlay capability not accessible to page scripts, and more stable cross-browser parity (Polčák et al., 18 Jul 2025).
The studies therefore converge on a tension: MV3 can improve footprint and reduce several abuse-prone privileges, but these same restrictions can degrade or eliminate protective functionality in extensions whose logic depends on dynamic network control, reliable early instrumentation, or confidential state handling.
7. Cross-browser divergence, remaining risks, and future directions
MV3 is often discussed as if it were a single stable platform, but both studies point to a more fragmented reality. The developer study reports concerns about migrating twice—first to Chrome MV3 and then to Firefox’s MV3 variant—and highlights cross-browser differences in permissions, event models, and API availability, including Firefox-only DNS API support and differences between event pages and service workers (Polčák et al., 18 Jul 2025). Some developers explicitly regarded Chrome’s MV3 as removing capabilities still available elsewhere, thereby worsening portability (Polčák et al., 18 Jul 2025).
The security outlook is similarly mixed. The 2024 study concludes that MV3 reduces avenues for abuse, yet is “not immune” to malicious behavior, and demonstrates a proof of concept under which 56% of examined malicious extensions retain harmful capability after adaptation (Pantelaios et al., 2024). The 2025 study extends this caution from a store-ecosystem perspective: malware removals counted 19 for MV3 versus 2 for MV2, and “policy violations” counted 7 for MV3 versus 3 for MV2 in the sampled Chrome Web Store data, challenging the expectation that MV3 alone curbs abusive extensions (Polčák et al., 18 Jul 2025). This suggests that platform redesign and platform governance should be treated as complementary rather than substitutable controls.
Future directions identified in the studies are concrete. The ecosystem paper proposes cross-browser analysis across Firefox, Opera, Safari, and Edge, continued platform refinements to balance security/privacy with developer flexibility and ad-blocker functionality, strengthened review processes, open-source scrutiny using tools such as CRXcavator and LayerX, and watcher services to monitor web_accessible_resources for malicious changes (Pantelaios et al., 2024). The developer study emphasizes secure storage APIs, stronger and clearer early-injection guarantees, richer and more transparent DNR semantics, cross-browser alignment through the W3C WebExtensions Community Group, and clearer communication of stable timelines (Polčák et al., 18 Jul 2025).
Taken together, the evidence positions MV3 as a substantial but incomplete reconfiguration of extension security. It measurably constrains historically abused capabilities and improves some resource-usage properties, yet it also introduces migration complexity, capability regressions for several privacy/security extension classes, and new adaptation surfaces centered on page-context execution and cross-browser inconsistency.