Feature request: Extending Whitelist/Blacklist/Custom with CIDR Netblock

[arizvisa]

First of all, thanks so much for committing your time to developing/maintaining this extension. I've been using it for years, and it's (by far) the best out of the user-agent management extensions. As per the title, this is a feature request...

Presently, there is support for whitelisting/blacklisting URLs using globs, regexes, etc. This is fine in general for most cases.

On the internet, though, servers are not actually contacted by their domain name, rather their IP is used. There is support in the extension for explicitly specifying IPv4 or IPv6, but specifying more than one address or an entire network is not available. Namely, if there was support for specifying ranges, or a CIDR block/network that the domain resolves to, when modifying the user-agent header, this would allow greater control over the user-agent used by your extension for different hosts.

I believe this would allow issues #135, #183, #199, and #211 to be resolved..as one could specify something like 104.16.0.0/12 to whitelist the entire CLOUDFLARENET network. This would also allow setting a specific user-agent for an entire local network for when the network's services are (stupidly) restricted depending on the browser that you use. I use "custom mode", specifically, for a similar "use-case".

However, I believe my request might not be possible due to inherent limitations of the declarativeNetRequest extension APIs (https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/declarativeNetRequest)... in that the header-editing rules only allow you to match against the url, and not against the address the hostname resolves to.

More importantly, the declarativeNetRequest extension APIs do not allow an extension to receive any feedback from the domain currently being resolved in order to specify an arbitrary condition. (ref of gecko's implementation: https://github.com/mozilla/gecko-dev/blob/master/toolkit/components/extensions/ExtensionDNR.sys.mjs#L1536)

Despite the limitations of declarativeNetRequest, I wonder if there is another way to accomplish this by combining it with another extension API or perhaps by making a secondary web-request for the url to determine the IP for a domain? Once the IP has been resolved with the secondary request, you could then match it against one of the chosen netblocks, and then use that result to determine whether to add a declarativeNetRequest rule for the visited url. Afterwards, the webpage could then be reloaded by the extension in order for the declarativeNetRequest rules to still be applied.

[ray-lothian]

With the "v3" release, we've fully transitioned to using the declarativeNetRequest implementation. This is now the sole network-synced method for header manipulation. However, this API is quite limited in its current state. As a result, incorporating IP-based filtering is not feasible at this time.

Excluding Cloudflare (CF) based on its IP range is not recommended, as it would result in skipping approximately half of all websites. In these scenarios, our goal is to allow CF to pass while ensuring the destination website still receives the spoofed user agent. The extension should only bypass the intermediate checking page.

I'll keep this open for suggestions.

[arizvisa]

Ah, the solution wasn't intended as only being a fix for cloudflare. But rather for whitelisting addresses in a network that the user may consider trusted. For example, a work VPN which will have their own network for internal services provided to employees. Presently using "custom/blacklist/whitelist", requires the user to specify each specific subdomain and address manually for each of these.

This scenario is a lot more ubiquitous nowadays since work-from-home is a common model for employment.