META: use cases for blocking webRequest not covered by declarativeNetRequest

[hackademix]

This is meant as a meta-issue to collect use cases not (yet?) covered by declarativeNetRequest which currently prevent MV2 extensions relying on blocking webRequest from migrating.

It aims to either justify keeping blocking webRequest around, better if asynchronous like in Firefox, for specific use cases requiring an ad-hoc permission, or to alternatively obtain clear and actionable instructions to serve the same use cases with available MV3 technology.

Already filed:

• 109

• 88

• 82

• 169

• 255

• 176

[ghostwords]

Google’s definition of third-party domains doesn’t agree with Privacy Badger’s definition.

According to Google,

A request is said to be first party if it has the same domain (eTLD+1) as the frame in which the request originated.

Privacy Badger and probably all content blockers care whether a resource is third party to the site (top-level document frame) the user chose to visit, not to some frame within the site.

Moreover, how will Privacy Badger continue to account for domains that appear different but in fact belong to the same entity? Privacy Badger maintains a long list of lists of such domains. Whenever Privacy Badger performs a "party-ness" check, this list is taken into account.

[hackademix]

Just added:

• 169

• 176

• 255

[erosman]

Also:

• Supply credentials for proxy authorization in MV3 #264

[hackademix]

Adding

• 506