Chrome 151 blocks DevTools extensions on other extension pages: supported migration path?

[c luo]

Hi,

I am the developer of Storage Area Viewer:

https://chromewebstore.google.com/detail/storage-area-viewer/fcbndbpibgeafoogbmbcljcmgakaniae

It is a Manifest V3 DevTools extension. When a developer inspects a chrome-extension:// page, it adds a DevTools panel for inspecting chrome.storage areas (local, sync, session, and managed) and editing data where permitted.

Problem

On macOS with Chrome 151.0.7922.109, the Storage Area Viewer panel no longer appears when DevTools is opened for another extension's chrome-extension:// page.

The current Chrome Web Store release is 1.0.3. I also reproduced the problem with an enabled unpacked 1.0.5 development build.

What I found:

1. For a normal web page target, the extension's devtools_page can load.
2. For Storage Area Viewer's own extension page, it can also load.
3. For a chrome-extension:// page belonging to a different extension, devtools_page is never loaded. The extension therefore has no opportunity to display an error, fallback UI, or migration notice.
4. Launching Chrome with --extensions-on-extension-urls restores the previous behavior.

This appears to be related to the following DevTools Frontend change. RegisteredExtension.isAllowedOnTarget() now prevents a DevTools extension from loading on a different extension origin:

https://chromium.googlesource.com/devtools/devtools-frontend/+/951c1e9f60ad86eb0a6b247b6cdf8b2f6e3f301d

I understand that cross-extension code execution or data access may present a security risk. However, the current implementation does not only restrict inspectedWindow.eval(); it prevents the entire devtools_page from being registered. This effectively ends a category of developer tools that previously worked.

Why the native Extension Storage panel is not a complete replacement

Chrome 132 introduced Application > Storage > Extension Storage:

https://developer.chrome.com/docs/devtools/storage/extensionstorage

The native panel provides basic viewing, filtering, creation, editing, and deletion. Storage Area Viewer also provides debugging-focused capabilities:

- A live timeline of storage add, update, and delete events with timestamps
- Structured old/new JSON diffs that highlight the exact changes
- Search across both keys and serialized values, including an exclusion filter
- Pinning keys that need to be monitored continuously
- A collapsible JSON detail view
- A full JSON editor with formatting and one-click copying
- Virtualized lists for working with large storage datasets during continuous debugging

These features make it a storage debugger rather than only a data table.

I would appreciate guidance from the Chrome Extensions / DevTools team:

1. Is this an intentional and permanent security policy change?
2. Is there a public design document, migration notice, or Chromium issue describing it?
3. Could there be an explicit user-consent mechanism allowing a DevTools extension to access selected extension targets, such as a permission, extension ID allowlist, or confirmation prompt in DevTools?
4. Could Chrome expose a restricted DevTools API that only reads and modifies the target extension's chrome.storage data, without allowing arbitrary JavaScript execution?
5. Is --extensions-on-extension-urls a supported and stable development path? Can it be enabled through an enterprise policy or dedicated development configuration?
6. If this DevTools extension architecture is no longer supported, what migration path does the team recommend?

I would like to understand the security reasoning behind this change and find an officially supported implementation that follows the new security model while preserving these debugging capabilities.

Thank you.

[Anton Bershanskyi]

Hi,

Disclaimer: I'm not a Google employee, the following is just my opinion based on prior experience of developing personal and commercial extensions not owned by Google and preparing a few patches in Chromium codebase.

I believe the real bug in the linked patch is the lack of a clear warning prompting user to add --extensions-on-chrome-urls flag to enable this functionality. If you are interested in adding this warning back, I might be able to help you.

I used your extension a few times  a while ago before Chrome added native implementation in Application > Storage > Extension Storage, it was very useful back then. It is unfortunate that your extension got broken, but even as a former user I'm not sure I would want to reduce friction of one extension peeking into unrelated extension's storage (or breaking any other form of isolation). You are asking for a simpler path to security-critical permission elevation or waiver beyond already existing mechanism.

A while back I came up with a different integration approach (which worked better for my use case and hence stopped using your extension). I integrated extension storage viewer and other debug utils directly in debug builds of my extensions. Essentially, I had a build config option which is used only for local debugging. When this option is activated, extension gets DevTools integrations for itself, which exists as a separate DevTools tab for this extension. That included storage viewer and editor, Alarms API viewer and editor, extension context viewer (which was much more relevant before runtime.getContexts() existed), extension message passing viewer, and a few other minor things. This way extension DevTools ran within extension's own origin and thus had unrestricted access to entirety of their own data, without elevated permissions. Build integration enabled me to run code before extension's code and instrument it much better than dynamic code injection did.

Obviously, by design this tooling was integrated during my extension compilation and was not available for any other extensions. I also played with the idea of integrating this tooling into other extensions, even ones downloaded from Chrome Web Store. I did not really need that use case, so that remained as just a toy, but it might work for you as a main mechanism. It worked by unpacking prebuilt extensions and injecting my DevTools Page declaration in their manifests and copying my DevTools UI files into unpacked folder and then just loading the while instrumented build as an unpacked extension. This process obviously had a lot of friction, but that friction was intentional to uphold security boundaries. In theory, one could relatively easily build an extension which calls Extensions Management API to get a list of installed extensions, then presents user with a choice to install "instrumented" debug builds of them, and once user chooses something, downloads original extension files, patches them, and prompts the user for installation. Obviously, the "real" and "instrumented" installs have different copies of source code and different storage areas, so this can not be considered a true replacement of your tool.

Thanks,

Anton.

[woxxom]

To state the obvious: the impact of the change wasn't communicated publicly, which means that it was either not intentional or Chromium team keeps treating the extensions platform as just a built-in proprietary thing of their browser being unaware of WECG and other public venues like these very groups.

Assuming for the sake of an argument this was an intentional restriction and the amount of extensions that will be broken as developers won't re-run the browser with --extensions-on-extension-urls flag because it's not limited to a particular id and thus exposes the entire browser, I think a better opt-in mechanism should be devised. For example, it can be similar to "Allow User Script" toggle in the extension's details or it can be a button/checkbox inside devtools.

[Anton Bershanskyi]

Hi,

The fundamental problem with Google Chrome extensions for DevTools is the coarse nature of DevTools permission. Google Chrome grants it based on presence of devtools_page attribute in manifest[1] for all pages at once and it can not be made optional. Once extension has a DevTools access, document specified in devtools_page must be able to see fairly detailed information about the tab, for example, to decide whether it wants to display a DevTools pane or not. In the past, I looked into solving this problem by either (1) making DevTools appear only on pages which have active Host Permission (that is host_permissions or optional_host_permissions) or (2) introducing a way to request permission for a tab. Either way, it was a very non-ergonomic change and rather complicated to integrate and handle edge cases like tab navigations with open DevTools.

> similar to "Allow User Script" toggle in the extension's details or it can be a button/checkbox inside devtools.

I suppose having a DevTools permission switch for each extension would be an improvement over current system and would be a half-step into the right direction. Perhaps, we should file a bug requesting this and see whether the Chrome team would be receptive of patches.

[1] https://source.chromium.org/chromium/chromium/src/+/main:extensions/common/manifest_handlers/devtools_page_handler.cc;l=59