Manifest V3 enhance updateDynamicRules with dynamic headers

[Julien Jean]

Hello there,

I'm currently working on a browser extension which sets a custom header with a unique value on every request when it is targeting a given server. With the new DeclarativeNetRequest API, this is not possible anymore, as it seems that we can only define static values.

As we really need a unique value for every request matching the rule, we cannot simply define a custom rule, and removing it everytime that the rule matched. We would miss some requests.

How can I manage such a thing ? Would it be possible to define a custom header value by calling a function referenced when we define a new rule ?

Something like

```javascript
chrome.DeclarativeNetRequest.updateDynamicRules({
  addRules: [
  {
    action: {
      type: 'MODIFY_HEADERS',
      requestHeaders: [
        {
          header: 'X-Foo-Bar',
          value: () => `${new Date().getTime()}`,
          operation: 'SET',
        }
      ]
    }
  }
}, () => {...})
```

As you can see, the value could receive a function that would be called everytime the rule matches. Here, every request matching the rule would have a X-Foo-Bar header with the current timestamp as value.

Is that is not feasible nor planned in the roadmap, is there any workaround ?

Thanks !

[wOxxOm]

Not any time soon, because this API was designed to run natively inside the browser process (where you can't run JS code), which was advertised as much more performant solution for privacy and ad-blocking extensions. Many extension authors already noted the obvious fact that this will actually reduce privacy and quality of ad-blocking (and many more usage scenarios) due to the lack of flexibility, but ManifestV3 team so far has ignored opinions on fundamental issues that differ from their own in every case, AFAIK.

A minor improvement like regular expression substitution might be possible to expect. See issues 1254637, 1021672, 1241397 for this and other arguably feasible suggestions.

[Julien Jean]

Hey,

Thanks for your quick feedback ! I start thinking that we'll have to lock some features on our chromium-based extension builds at this point.

Best regards,