-
Notifications
You must be signed in to change notification settings - Fork 56
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
META: use cases for blocking webRequest not covered by declarativeNetRequest #110
Comments
Google’s definition of third-party domains doesn’t agree with Privacy Badger’s definition. According to Google,
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. |
Just added: |
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:
The text was updated successfully, but these errors were encountered: