New Update The Death of webRequest API & uBO? Not likely, at least for now.

[oldschool]

For those who may have scanned the uBlock Origin forums, or have otherwise heard that Google is proposing API changes that could spell the end for uBO, ... hold your horses! Please read all links and see if you can make sense of what Google's plans are.

API Behaviors

Web Request API
The extension can still intercept, modify, and block any requests from sites it has access to. For sites the extension does not have access to, Chrome badges the extension to indicate that the extension requests access to the page. The user can then grant access to the extension; Chrome then prompts the user to refresh the page to allow your extension to intercept the network requests.
Content Scripts, tabs.executeScript(), tabs.insertCSS()
The extension can still inject scripts and style sheets automatically for any sites it has access to. For sites the extension does not have access to, Chrome badges the extension to indicate that the extension requests access to the page. The user can then grant access to the extension. If the content script was set to inject at document_idle, the script will inject immediately. Otherwise, Chrome prompts the user to refresh the page to allow your extension to inject scripts earlier in page load (at document_start or document_end). The callbacks for the tabs.executeScript() and tabs.insertCSS() methods are only invoked if the user grants access to the site.

Chrome extension manifest v3 proposal · Issue #338 · uBlockOrigin/uBlock-issues

See particularly:

Chromium Blog: Trustworthy Chrome Extensions, by default

 

[Windows_Security]

What will change?
In chrome flags there is already a flag to control/limit execution of EXTENSION SCRIPTS, which (when enabled) requires explicit user confirmation for javascript to execute by Extensions. User has the option do enable this for all sites or on request (allowing on a site requires specific user intervention). Picture from about://flags.

Unlike Chrome applications, extensions are not restricted by content security policy. On installation the user currently grants the extension the necessary site access permissions. The assumption behind this 'grant once - allow always' mechanism was that Google would check all extensions in the Chrome Web Store, so all extension listed in the Web Store would be trustworthy and we all know how that assumption turned out: Extension - Fake Malicious Extensions on Chrome Web Store!). To improve extension security Google had to make changes. Chrome will be implementing new SITE ACCESS permission mechanism for extensions. One of the 10 design principles of Google is that "they use what is already available", so they copied the "javascript" mechanism for extensions and applied this to "website access permissions".

As explained in @oldschool post: "The user can then grant access to the extension; Chrome then prompts the user to refresh the page to allow your extension to intercept the network requests." This is an elegant way to shoot extension developers in the foot. Google simply makes the current model so hard to use, that average PC users will be driven way because it is annoying in day to day usage. When faced with criticism Google can answer "users will have a choice" and when extension developers will complain, Google can simply say "the market has chosen". So in practice extension developers are forced to use this new API.

The good, bad and the ugly
THE GOOD
The new API will have both performance, privacy and security advantages, because in stead of Chrome asking extension what to do with a request the extension can tell Chrome what to do with the request (which implicitly prevents the extension to snoop on the traffic data or misuse/redirect traffic).

• The declarativeNetRequest API allows for evaluating network requests in the browser itself. This makes it more performant than the webRequest API, where each network request is evaluated in JavaScript in the extension process.
• Because the requests are not intercepted by the extension process, declarativeNetRequest removes the need for extensions to have a background page; resulting in less memory consumption.
• Unlike the webRequest API, blocking requests using the declarativeNetRequest API requires no host permissions.
• The declarativeNetRequest API provides better privacy to users because extensions can't actually read the network requests made on the user's behalf.

THE BAD
The new API allows less intervention points (only onBeforerequest stage) and less intervention options (only block or redirect). This limits the control an adblocker has in terms of options and flow of event,

• Evaluation of declarativeNetRequest rulesets is performed during the onBeforeRequest stage of a network request. Extensions using the webRequest API can intercept requests at different stages of the request.
• The declarativeNetRequest API only allows extensions to block or redirect requests. The webRequest api is more flexible as compared to the declarativeNetRequest API because it allows extensions to evaluate a request programmatically.

THE UGLY
Google is working hard to secure its advertising business model by enforcing stricter rules to advertising companies with its "better ads initiative". Chrome has its own internal adblocking mechanism to enforce these guidelines (block intrusive ads). When Google has enforced its grip on acceptable ads (sorry better ads) it would be very easy to add an internal "acceptable ads/better ads" whitelist to bypass the blocks of extension (since the extension has passed over the actual blocking to the browser).

 

[Windows_Security]

Knowing Google and reading the documentation, I am not so sure whether it won't be the end of uBlock0rigin on Chrome ( uBlock0rigin lovers can always move to Firefox ).

Some facts on new API (copied pictures)
- rule syntax looks like 'simple' AdBlock (static uBlock0rigin) rules
- maximum of 100 whitelist and 30.000 block/redirect rules

Static Adblock like rules
Simular to adblock rules, except 'main_frame' and 'sub_frame' are probably equivalent to AdBlock's 'document' and 'subdocument' and domains are specified separately (domains and excluded domains are simular to adblock's $domain=included.com|~excluded.com)

Maximum rules

 

[Windows_Security]

Note the alternatives mentioned (method-executeScript and method-insertCSS have Cross Site Scripting warnings (see picture). Mwaahhh :emoji_disappointed:

 

[Moonhorse]

Im already in panic about moving to other browsers
I still keep chrome on my pc for banking and keep the simple extensions ublock+ netcraft + MBA on it
Firefox has nice year ahead, but only problem i have is chrome still has built in flash and other browsers require to download the flash wich is working worse compared to chrome

Maybe im gonna install adguard hehe

 

[Windows_Security]

Hold your horses. The manifest is still in draft and when changes are implemented extensions developers will have a year+ to adopt their software. It took them over 1.5 year to move from Manifest V1 to V2 and since january 2014 we are on V2 (so five years now). When they manage to speed up implementation like they did for V1 to V2 transition, it will be in Q4 of 2020 at the earliest that only the new API is allowed.

Once announced and implemented, it will eventually be required for all extensions over a year + rollout

Will be interesting to see whether Raymond Hill will adopt or shift development effort to Firefox (or to Edge with the help of Hugo Xu - developer of NanoAdBlocker). Raymond Hill does not accept donations, so he develops for fun. Most programmers don't find rewriting software very inspiring when it is just for technical compliance.

Maybe this is a nice opportunity for Microsoft. They are moving to Blink engine and expect to ship early version end 2019, so maybe Microsoft uses this as an opportunity to differentiate Edge form Chrome and Chrome clones (the only browser with Blink engine and advanced Ad Blocking )

 

[Moonhorse]

So year for gorhill to make ublock origin work with that chrome version, no worries then ..im staying with google

 

[Sunshine-boy]

When Google has enforced its grip on acceptable ads (sorry better ads) it would be very easy to add an internal "acceptable ads/better ads" whitelist to bypass the blocks of extension (since the extension has passed over the actual blocking to the browser).

there are ungoogled chromiums like Brave and Yandex browser.

 

[oldschool]

So year for gorhill to make ublock origin work with that chrome version, no worries then ..im staying with google

No, this is not the case, according to Gorhill it will mean the end of dynamic filtering:

"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."

My question is whether, as @Sunshine-boy points out, ungoogled browsers like Brave will make this switch. Hopefully, they stick to their business model and refuse to go along with Google's implementation. If so, I will remain a Brave user, or if not, I would stick with Firefox. Brave also claims one of their goals is to have their own Brave Store.

 

[Windows_Security]

Ungoogled chromium won't involve such drastic changes as a different API and less interception options also the logic is completely reversed, maybe Opera because they have a build-in adblocker. Best chance would be Edge, because they 'only' using Blink.

 

[oldschool]

Ungoogled chromium won't involve such drastic changes as a different API and less interception options also the logic is completely reversed, maybe Opera because they have a build-in adblocker. Best chance would be Edge, because they 'only' using Blink.

I'm not quite understanding your intent. Do you mean to say that Brave, etc. will follow Google's lead, or not??

BTW: Brave has a built-in adblocker with option to enable/disable. Also script blocking, fingerprinting and HTTPS Everywhere are built-in. I still use Nano Adblocker though.

 

[Burrito]

The subject matter of this thread potentially has a more real and tangible effect on many of us than the vast majority of discussions here at MT.

Ad blocker uBlock Origin “can no longer exist” if a proposed change to Chrome goes through. That’s according to Raymond Hill, the developer of uBlock Origin and uMatrix, in a comment on Chromium’s bug tracker. ​

....​

Beside causing uBO and uMatrix to no longer be able to exist, it’s really concerning that the proposed declarativeNetRequest API will make it impossible to come up with new and novel filtering engine designs, as the declarativeNetRequest API is no more than the implementation of one specific filtering engine, and a rather limited one (the 30,000 limit is not sufficient to enforce the famous EasyList alone).​

....​

It’s a tradeoff. Browser extensions like uBlock Origin can no longer implement their own filtering engine, but the filtering engine will be a speedy one built into Chrome itself. The whole industry has been moving toward more limited browser extensions. Despite what some people have feared, Google isn’t using this as an opportunity to kill off ad blockers. ​

Chrome May Get Faster Ad Blocking While Breaking uBlock Origin​

​

Some of us may lose uBO and/or uMatrix, some of us may change browsers based on changes.

I've tried most of the major browsers and prefer straight-up Chrome, and I use and like uBO on most of my computers. But... maybe the change will end up being good.

Thanks to the participants on this thread who have helped me understand the potential changes.

I'll be watching..

 

[Local Host]

I use Adguard so this doesn't affect me, plus by the time this changes are implemented, Microsoft Edge will be my main browser everywhere.

 

[oldschool]

The subject matter of this thread potentially has a more real and tangible effect on many of us than the vast majority of discussions here at MT.

Ad blocker uBlock Origin “can no longer exist” if a proposed change to Chrome goes through. That’s according to Raymond Hill, the developer of uBlock Origin and uMatrix, in a comment on Chromium’s bug tracker. ​

....​

Beside causing uBO and uMatrix to no longer be able to exist, it’s really concerning that the proposed declarativeNetRequest API will make it impossible to come up with new and novel filtering engine designs, as the declarativeNetRequest API is no more than the implementation of one specific filtering engine, and a rather limited one (the 30,000 limit is not sufficient to enforce the famous EasyList alone).​

....​

It’s a tradeoff. Browser extensions like uBlock Origin can no longer implement their own filtering engine, but the filtering engine will be a speedy one built into Chrome itself. The whole industry has been moving toward more limited browser extensions. Despite what some people have feared, Google isn’t using this as an opportunity to kill off ad blockers. ​

Chrome May Get Faster Ad Blocking While Breaking uBlock Origin​

​

Some of us may lose uBO and/or uMatrix, some of us may change browsers based on changes.

I've tried most of the major browsers and prefer straight-up Chrome, and I use and like uBO on most of my computers. But... maybe the change will end up being good.

Thanks to the participants on this thread who have helped me understand the potential changes.

I'll be watching..

Yes, these developments will pose a challenge for many users.

BTW: I posted the thread that @Windows_Security referred to above. You have to dig in to the referenced source material to get the big picture. It's kind of like a slow-moving tidal wave. :emoji_cold_sweat: