What will change?

The good, bad and the ugly

Chrome declarativeNetRequest said: 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. Click to expand...

Chrome declarativeNetRequest said: 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. Click to expand...

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: "." 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 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 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,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 ().