Also, this makes it impossible to implement important filter option, which purpose is to override exception filters. When I select only EasyList, uBO reports 42,000 network filters, so even EasyList alone won't be enforceable with the declarativeNetRequest API.īeside the low maximum of 30,000, ABP-compatible filters have no sense of specificity, hence why dynamic filtering can't be implemented with such approach (and if they did it would be a pain to have to recompile the whole filtering profile when merely adding/removing a rule/switch through a click).
![adguard theregister adguard theregister](https://i.imgur.com/lyjnvRx.png)
What is being said now is that the maximum capabilities content blockers will be allowed come down to a maximum of 30,000 ABP-compatible filters.Įven without dynamic filtering and per-site switches, etc., uBO already enforces over 90,000 filters (which themselves go beyond ABP filter syntax) with just the default filter lists, not counting the regional one which may be activated automatically at first install, and other commonly used ones such as Fanboy Social. Which is already better equipped than Chromium's version of uBO - example, example - (and also better equipped than the Firefox legacy version). Actually Firefox's own webRequest API is better designed as it's possible to return a Promise, which makes it possible to defer returning an answer to some point in the future. I am confident uBO will still exist on Firefox. I don't expect Firefox to follow suit and also deprecate its own webRequest API. There are no issue of privacy/performance with uBO, rather the opposite by giving back to users the power of clamping down on what web sites throw at them, so that argument is just plain fallacious as far as uBO is concerned.Ĭhromium got its webRequest API at a time it was trying to gain market share against Firefox (Sep 2011), where Adblock Plus, Ghostery, Disconnect, NoScript, and other such extensions were the most or among the most popular extensions on Firefox. The fact that they are planning to remove a proper blocking webRequest API with no word of an equivalent replacement is a sign of intent, that is, reducing the level of user agency in their user agent (aka Google Chrome). The details of what limitations we may put in the webRequest API are to be determined. As an alternative, we plan to provide a declarativeNetRequest API (see below). The non-blocking implementation of the webRequest API, which allows extensions to observe network requests, but not modify, redirect, or block them (and thus doesn't prevent Chrome from continuing to process the request) will not be discouraged. In Manifest V3, this API will be discouraged (and likely limited) in its blocking form. This can have a significant effect on every single network request, even those that are not modified, redirected, or blocked by the extension (since Chrome needs to dispatch the event to the extension to determine the result).
![adguard theregister adguard theregister](https://image.prntscr.com/image/-cWkw_O0SLm-S--V0t_hcA.png)
This begins in the browser process, involves a process hop to the extension's renderer process, where the extension then performs arbitrary (and potentially very slow) JavaScript, and returns the result back to the browser process. The basic flow is that when a network request begins, Chrome sends information about it to interested extensions, and the extensions respond with which action to take. Currently, with the webRequest permission, an extension can delay a request for an arbitrary amount of time, since Chrome needs to wait for the result from the extension in order to continue processing the request.
![adguard theregister adguard theregister](https://venturebeat.com/wp-content/uploads/2021/06/sale_214984_article_image.jpg)
It is frequently used by content blockers. The current webRequest API allows extensions to intercept network requests in order to modify, redirect, or block them.