declarativeNetRequestFeedback

• During development and debugging of a content-blocking extension to see why certain requests are being blocked or modified.
• To create a "block log" for users to see what the extension is doing, though this should be an opt-in feature due to the privacy concerns.

This permission is used in conjunction with declarativeNetRequest.

{
  "name": "My Content Blocker (Debug Build)",
  "version": "1.0",
  "manifest_version": 3,
  "permissions": [
    "declarativeNetRequest",
    "declarativeNetRequestFeedback"
  ],
  "host_permissions": [
    "<all_urls>"
  ]
}

Why is it medium risk?

While the standard content-blocking permission (declarativeNetRequest) is private — the extension never sees individual requests — this "feedback" permission partly undoes that privacy. It lets the extension observe which URLs (including main-frame navigations) match its rules, which is essentially a stream of the user's browsing activity for any pages affected by the ruleset.

The onRuleMatchedDebug event also has performance implications, so Chrome surfaces this as a separate, scrutinized permission. It is most appropriate for development/debugging or for opt-in "block log" UIs.

This example logs information to the console every time a declarativeNetRequest rule is matched.

// background.js

chrome.declarativeNetRequest.onRuleMatchedDebug.addListener((info) => {
  console.log("DNR Rule Matched:");
  console.log(`  - Tab ID: ${info.request.tabId}`);
  console.log(`  - URL: ${info.request.url}`);
  console.log(`  - Matched Rule ID: ${info.rule.ruleId}`);
  console.log(`  - Ruleset ID: ${info.rule.rulesetId}`);
});

console.log("Listening for matched DNR rules...");