Microsoft is no longer challenging Google in this space,” a user added. “Or you could cease contributing to the Blink monopoly on the web and join us of Firefox. Others expressed that it is better to avoid all the drama by simply switching to some other browser, mainly Firefox. A user commented, “As Chrome is a dominant platform, our work is prevented from reaching users if it does not align with the business goals of Google, and extensions that users want on their devices are effectively censored out of existence.” Many users also mentioned that Chrome is using its dominance in the browser market to dictate what type of extensions are developed and used. Furthermore, if performance concerns due to the blocking nature of the webRequest API was their real motive, they would just adopt Firefox’s approach and give the ability to return a Promise on just the three methods which can be used in a blocking manner.” “Web pages load slow because of bloat, not because of the blocking ability of the webRequest API - at least for well-crafted extensions. Hill had previously shared his thoughts on deprecating the blocking ability of the webRequest API. However, many developers think otherwise. Google’s reasoning for introducing this change is that this API is much more performant and provides better privacy guarantees. Due to its limiting nature, many ad blocker developers and maintainers have expressed that this API will impact the capabilities of modern content blocking extensions. This API allows adding up to 30,000 rules, 5000 dynamic rules, and 100 pages. In place of webRequest API, Google has introduced the declarativeNetRequest API. While the non-blocking form of the API, which permit extensions to observe network requests will be allowed. In Manifest V3, the use of this API will be limited in its blocking form. The basic flow of handling a request using this API is, Chrome receives the request, asks the extension, and then gets the result. The webRequest API permits extensions to intercept requests to modify, redirect, or block them.
#Ublock origin extra update#
Users speculated that probably this outcome is the result of the “crippling” update Google has introduced in Chrome (beta and dev versions currently): deprecating the blocking ability of the WebRequest API. This news sparked a discussion on Hacker News and Reddit. Actually, logic dictates that 1.22.5rc0 should also be rejected and yet it’s still available in the Chrome Web Store.” Users’ reaction on Google rejecting the uBlock Origin dev build He commented, “I will upload stable to the Chrome Web Store, but given 1.22.5rc2 is rejected, logic dictates that 1.23.0 will be rejected. He does plans to upload the stable version. Hill on a GitHub issue mentioned that this is basically “stonewalling” and in the future, users may have to switch to another browser to use uBlock Origin. An email to Hill from Google reads, “Do not create an extension that requires users to accept bundles of unrelated functionality, such as an email notifier and a news headline aggregator.” Google stated that the extension did not comply with its extension standards as it bundles up different purposes into a single extension.
#Ublock origin extra free#
uBlock Origin is a free and open-source browser extension widely used for content-filtering and adblocking. Last week, Raymond Hill, the developer behind uBlock Origin shared that the extension’s dev build 1.22.5rc1 was rejected by Google’s Chrome Web Store ( CWS ).
0 kommentar(er)
