![]() 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. ![]() As a user, I personally wouldn't accept browsing the world wild web without the advanced features in uBO, I find this unthinkable. ![]() That new declarativeNetRequest API seriously reduces what blockers can do, to the point they will become distinguishable only by their UI, not their capabilities. How to do this? Use privacy/performance as Trojan arguments to rationalize reducing user agency over what all bloated web sites throw at people's user agents. 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). Issues of performance and privacy lie with web sites, not uBO - so I don't feel concerned with the issues of privacy and efficiency being put forth as advantages of using declarativeNetRequest over webRequest. There is no concept of specificity in static filtering - and even more, there is no concept of dynamic filtering rules relinquishing filtering to static filters (dynamic filtering's noop rules).īasic ABP-like syntax, 30000 filters MAX.Īnd there I was recently testing how uBO handled over half a million network filters with the 3rd-gen HNTrie. Dynamic filtering logic requires an arbitrary amount of block/allow rules overriding other block/allow rules based on specificity. There is no way to transpose either either dynamic filtering, dynamic URL filtering, per-site/per-scope switch logic (let's refer to all these as "dynamic filtering"), into static filters. If there is really such phase out planned, and if the declarativeNetRequest is strictly an implementation of static filtering à la ABP, this would be the death of uBO and uMatrix. It is explicitly stated this is meant to phase out webRequest API? If so, where? Quickly perusing the page, I don't see such phase out being stated. It appears that Google is phasing out the webRequest API (Plus there's the change from background page to ServiceWorker.) I would expect big changes needed to uBO and other blockers. ![]() Looking at the new API page, it's a rather different way of doing things. This API is currently being implemented, and will be available to both the current manifest version and Manifest V3, but will be the primary way to modify network requests in Manifest V3. This is also better for user privacy, as the details of the network request are never exposed to the extension. This allows us to ensure efficiency since a) we have control over the algorithm determining the result and b) we can prevent or disable inefficient rules. Thus, instead of the above flow where Chrome receives the request, asks the extension, and then eventually gets the result, the flow is that the extension tells Chrome how to handle a request and Chrome can handle it synchronously. At its core, this API allows extensions to tell Chrome what to do with a given request, rather than have Chrome forward the request to the extension. The declarativeNetRequest API is an alternative to the webRequest API. It appears that Google is phasing out the webRequest API in favor of their new declarativeNetRequest.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |