Chrome will be similar to Apple’s Safari browser, which now supports “ content blockers” that operate in a speedy, standard way. This change may speed up Chrome by limiting what all browser extensions can do-ad blocking extensions and other 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.īeside 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).Įven Hill notes that ad blockers aren’t going away if this goes through. uBlock Origin puts memory efficiency as its cornerstone while delivering the best experience possible for blocking ads efficiently and effectively. Raymond Hill notes that, if this change goes through, ad blocker uBlock Origin and content filter uMatrix can’t do anything special: However, declarativeNetRequest uses an Adblock Plus-style filtering system. Chrome itself does the blocking without waiting for extensions to respond, and this should be faster. Chrome won’t have to wait for extensions to weigh in while loading a page.Īd blockers must use the “ declarativeNetRequest” API to tell Chrome what they want to block. For further details on Tracking Protection please review Mozillas support. Extensions can only watch these events, and that should speed up page load times.
If the proposed change goes through, extensions won’t be able to block events with this API.
0 kommentar(er)
