[DNR/webRequest] Provide a means to discriminate initiators and destinations belonging to a local (private) network

[hackademix]

Noscript with its "Lan Protection", JShelter with its "Net Boundary Shield" and presumably other extensions (according to some sources, but it's unclear to what extent, uBlock Origin and uMatrix) try to defend against cross-zone attacks, for instance to manipulate a weak router web-based administration interface by exploiting CSRF and/or XSS and/or DNS-rebinding.

So far these feature have been considered low-risk from the Manifest V3 transition point of view because browser vendors appeared to agree on the Local/Private Network Access proposal, mitigating this kinds of attacks, to be implemented in a time-frame which would have hopefully surrogate natively the protection provided by the extensions.

Unfortunately compatibility issues have repeatedly postponed the effective enforcing date for this technology, and therefore the aforementioned extension-provided protections are still valuable, while put in danger by DNR's known limitations combined with the removal of blocking webRequest (at least on Chromium-based browsers).

Therefore, for the stated use case of blocking WAN-to-LAN requests and provide UX to exempt certain sites, we propose to augment the DNR API with means to discriminate if the initiator and the destination of a request belongs to a local/private network or not.

This should be at least available to create DNR rules (e.g. through some kind of keyword/wildcard), which would enforce the general blocking policy and can be overridden by exceptions.

As a nice to have (optionally, since on Firefox the DNS API in conjunction with blocking asynchronous listeners can be used to the same effect, even if with much more effort) this information could be also exposed as properties in the details argument of webRequest.onBeforeSendHeaders or in an ad-hoc listener which is invoked on DNS resolution, making a webRequest-based implementation (even a passive one reporting through the non-blocking API) presumably more performant and reliable.

[Rob--W]

Meeting notes are pending publication in #408.

This request is currently stuck on the lack of clear path forward on integrating the capability in the DNR API, due to the feature's desire to operate after DNR resolution, in contrast with DNR's characteristic of evaluating rules at the start of a network request.

[oliverdunk]

@hackademix (and anyone else interested in this) - would being able to apply this across all requests be sufficient, or do the vast majority of use cases require some number of exceptions?

I had a chance to speak to the team working on Private Network Access within Chrome and they mentioned that most of the logic already exists today, and the main thing delaying the rollout is trying to mitigate the impact for users. One path we could take would be adding to the privacy.network API to allow extensions to enable the protections early.

Would love to hear your thoughts on this. If it sounds useful, we can continue that discussion (and also bring this up again in a meeting to see how other browser vendors feel about that idea).

[hackademix]

@oliverdunk

@hackademix (and anyone else interested in this) - would being able to apply this across all requests be sufficient, or do the vast majority of use cases require some number of exceptions?

The point of doing this through an extension, until it's not standardized and actually deployed in stable browsers, is exactly that: you need to provide users with on-demand exceptions for those "legitimate" sites / applications which are currently behind and causing the web compatibility which are slowing down actual rolling out.

@Rob--W :

your observation is correct, this feature would generally require DNR's decision to happen after DNS resolution (even though most of the time the DNR records would be cached).

I propose the late DNR triggering (on DNS resolution if needed) to be optional, conditional (dependent on an explicit flag?) and limited to this (and possibly other, if we decide to allow also for generalized IP-based rules) specific kind of rules.

[oliverdunk]

I spoke again with the Chrome extensions team and the team that owns Private Network Access at the end of last year.

Something that came up is that we generally try to provide UI for anything an extension can control. Since something we want here is site specific settings, there would be a non-trivial amount of work to provide the right UI there. They felt that work would be better spent on building UI that would allow us to ship this to all Chrome users rather than just as part of extensions, and optimistic that we could do that on a similar timescale. With that in mind, I'm not sure the privacy.network idea I had mentioned previously makes sense.

Personally I think the DNR idea is interesting, but I can see the concerns @Rob--W raised and he also knows the implementation in better detail than I do. @Rob--W - do you think the work we've been doing in #460 to define a new request stage could be applied to achieve something here? It would still be a unique stage I imagine but at least we would have a precedence to follow on how new stages behave.

Adding the neutral label for now but I think this is interesting to continue talking about. I certainly appreciate that it would be unfortunate to lose this functionality.