Extensions' declarativeNetRequest rules are able to block requests initiated by other extensions. This is a change from MV2, where chrome.webRequest had no visibility of these requests.

Example

An extension defines the following rule, with the intent of blocking requests to example.com on pages loaded in the browser:

{
    "id": 1,
    "priority": 1,
    "action": {
      "type": "block"
    },
    "condition": {
      "requestDomains": ["example.com"],
      "resourceTypes": [
        "csp_report",
        "font",
        "image",
        "main_frame",
        "media",
        "object",
        "other",
        "ping",
        "script",
        "stylesheet",
        "sub_frame",
        "webbundle",
        "websocket",
        "webtransport",
        "xmlhttprequest"
      ]
    }
  }

Should another extension how wish to make a request to example.com from their background script/service worker, it will be blocked:

fetch('https://example.com/') // blocked

Current browser status

I tested this in Chrome, Firefox and Safari using these test extensions. Steps to reproduce:

1. Download the attached zip and extract somewhere.
2. Install the extracted "extension-requests" subdirectory as an unpacked extension.
3. Open the background console for the extension requests demo extension.
4. Switch to the network panel, and see the requests to https://testpages.kzar.co.uk/ being made every second successfully.
5. Install the "extension-request-blocking-mv3" subdirectory as an unpacked extension.

(For Firefox and Safari minor changes are needed for the extensions to load).
Results:

• Chrome 111: Requests are blocked (Chromium bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1421697)
  
• Firefox Developer Edition 112: Requests are blocked
  
• Safari Technology Preview 165: Requests are not blocked

Discussion

We came across this issue due to a user reported issue on our extension repo (duckduckgo/duckduckgo-privacy-extension#1732). A youtube.com block rule was preventing the FeedBro extension from fetching RSS feeds from their background page. This was unexpected for us, as these requests are not visible in chrome.webRequest.

The issue can be mitigated by using a excludedTabIds: [-1] condition, however this also prevents the rule from matching requests initiated by website service workers (which is important for tracker blockers).

I believe this issue will introduce significant unexpected extension breakage, plus introduce new ways for extensions to sabotage each other. For example, an extension could prevent a privacy extension from fetching updates to their blocklist rules.