to the developers , chrome plans manifest draft v3

General discussion about Slimjet, or other issues related to web browser in general.
Post Reply
Posts: 761
Joined: Mon Apr 21, 2014 10:30 pm

to the developers , chrome plans manifest draft v3

Post by dev » Thu Feb 14, 2019 4:34 pm

A chance to gain a further foothold in the browser market if you and when the time comes if you can leave functionality in slimjet when the chrome devs go ahead in what it is planning to do in in webrequest api . A couple of extensions used by a hell of a lot of users examples below ...... A quick take from tampermonkey extensions ...The Chrome development team is currently planning changes that will disable Tampermonkey's ability to execute foreign code. Instead, all userscripts would have to become standalone Chrome extensions.

Currently the public is asked about these changes. If you're a userscript developer or just enjoy using this extension and want to continue using Tampermonkey in the medium term, then it would be nice if you could tell the developers more about your use case.

Please stay respectful, constructive and focused on the subject. Anything else will not help preserving Tampermonkey. :)

and a note the ublock dev gorhill Raymond Hill, known as Gorhill online, the author of the popular content blockers uBlock Origin and uMatrix, voiced his concern over some of the planned changes; these changes, if implemented as proposed currently, remove functionality that the extensions use for content blocking.

ublock chrome

Google plans to remove blocking options from the webRequest API and asks developers to use declarativeNetRequest instead. One of the main issues with the suggested change is that it made to support AdBlock Plus compatible filters only and would limit filters to 30k.

Hill mentioned on Google's bug tracking site that the change would end his extensions uBlock Origin and uMatrix for Google Chrome. While it would be possible to switch to the new functionality, it is too limiting and would cripple existing functionality of the content blocking extensions.

If this (quite limited) declarativeNetRequest API ends up being the only way content blockers can accomplish their duty, this essentially means that two content blockers I have maintained for years, uBlock Origin ("uBO") and uMatrix, can no longer exist.

There are other features (which I understand are appreciated by many users) which can't be implemented with the declarativeNetRequest API, for examples, the blocking of media element which are larger than a set size, the disabling of JavaScript execution through the injection of CSP directives, the removal of outgoing Cookie headers, etc. -- and all of these can be set to override a less specific setting, i.e. one could choose to globally block large media elements, but allow them on a few specific sites, and so on still be able to override these rules with ever more specific rules.

The new API would limit content blockers for Chrome-based browsers and eliminate options to create new and unique content blocking extensions. All that would be left are AdBlock Plus like filtering extensions that would all offer the same blocking functionality.

While there would still be adblockers for Chrome, the limit of 30,000 network filters would make even those less capable than before. EasyList, a very popular blocking list, has 42,000 filters and if users add other lists used for other purposes, e.g. social blocking, that number would increase even more.

Post Reply