Declarative Net Request

Entitlement: declarativeNetRequest. Configuration: internal.declarative_net_request.rules and/or <Provision root>/dnr_rules.json. These are kernel-owned fixed rules, not calls to an extension's dynamic-rules API.

Add an EP rule

{
  "internal": {
    "declarative_net_request": {
      "rules": [
        {
          "id": 1,
          "priority": 1,
          "action": { "type": "block" },
          "condition": {
            "urlFilter": "||example.com/sdk-block",
            "resourceTypes": ["main_frame"]
          }
        }
      ]
    }
  }
}

Merge the document and sign it when required. Fully restart, then navigate to https://example.com/sdk-block to verify blocking. Rule conditions use Chromium DNR syntax, not the wildcard syntax used by network.intercept() and navigation_redirect.

Choose matching conditions

Use the RuleCondition reference for field syntax and the Redirect reference for destination options. Apply the Chrovia restrictions below; not every Chrome extension rule option is supported here.

All supplied conditions must match. Do not use tabIds or excludedTabIds: tab-specific filters are not supported for these fixed rules. Explicitly include main_frame when you want top-level navigations covered.

For example, this standalone Provision rules array blocks only POST requests to the API host:

[
  {
    "id": 2,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {
      "requestDomains": ["api.example.com"],
      "requestMethods": ["post"],
      "resourceTypes": ["xmlhttprequest"]
    }
  }
]

Actions and precedence

Use positive rule IDs that are unique across EP and Provision, and explicit positive priorities. For an exception, assign the matching allow rule a higher priority than the block. Specify resourceTypes intentionally; a main_frame rule does not cover every subresource.

Only block, redirect, and allow are supported. allowAllRequests, upgradeScheme, modifyHeaders, and redirect extensionPath are not supported.

For redirects, use redirect.url for a fixed absolute destination, redirect.transform to change URL components, or redirect.regexSubstitution with a regexFilter condition. Choose one destination form per rule. For example, {"type":"redirect","redirect":{"transform":{"scheme":"https","host":"example.org"}}} changes those URL components while retaining the others. Limit the condition to the original host to avoid a redirect loop.

Distribute through Provision

For installation-wide rules, put the rules array itself in dnr_rules.json, not an object containing internal or rules:

[
  {
    "id": 1001,
    "priority": 1,
    "action": { "type": "block" },
    "condition": {
      "urlFilter": "||example.com/sdk-install-block",
      "resourceTypes": ["main_frame"]
    }
  }
]

Both files require declarativeNetRequest. Protect access to dnr_rules.json separately; a signed EP file does not prevent edits to it.

After installing or updating the browser package, confirm that dnr_rules.json is present in the Provision root actually used by that installation. Keep it alongside Extensions, not inside a plugin directory. See Provision packaging.

Limits and troubleshooting

Fully restart after editing fixed rules; there is no Chrovia JS method for updating them live. Malformed entries are skipped and logged. Invalid rules or exceeding rule limits can prevent a ruleset from loading. Unsupported actions do not silently become blocks.

Verify the effective URL, resource type, unique IDs, priorities, License, and EP signature. Fixed rules do not depend on a live Service Worker callback. Use network interception only when you need an application decision per matching request.