There's an extension api called onBeforeRequest() that lets Chrome extensions see urls that are about to be requested by the browser. It allows you to examine the url and do whatever code heuristics you want to decide whether you want to block it.
Google is removing that dynamic blocking ability and providing you with a way to supply a static list of blocked urls instead. No ability to use code to implement a dynamic list.
It's somewhat similar to taking a virus scanner and only allowing it to identify a virus by the filename being in a static, pre-generated list.
Also, Google says they are doing this for privacy reasons. Which is funny, because OnBeforeRequest() isn't going away, just the ability to block a request inside of it. You can still see every request, inject javascript with content scripts, exfiltrate data, and so on. You just can't preemptively stop a url/resource from being loaded using code...only a static list of urls. You can guess the type of extensions that depend on that functionality.
I pointed this out in a thread yesterday too, but the whole point is that you will no longer need to grant "see all my requests" permissions to ad blockers. In fact, due to the removal of the old blocking API, if an ad blocker asks for such permissions it's highly suspicious.
I imagine ad blockers also use content scripts for things like blocking ads based on images that are known IAB sizes. In that case, they have another avenue to watch requests.
I'd give the privacy angle more credence if they were really locking down everything. They aren't, because extensions would then be of very limited use.
It blocks requests based not merely on the full url, but just parts of it such as the the filename or path, or based on which tab or frame the load is for.
Heuristics can use information like parts of the url, context of the request (origin domain for example, or "request is coming from an iframe"), existence of third-party cookies, already detected page behavior, and so on. It also allows for updating the rules on the fly. Like if I allowed something, but it turned out to be a bad idea.
And Chrome won't allow the extension block lists to include regexps/wildcards, they all have to be FQDNs?
It seems reasonable to require a static list for privacy reasons. But not supporting pattern matching rules would seem to be an explicit attempt to stop ad blockers.
The privacy advantage is not giving extensions access to what domains you are browsing. The extension declares a static list but doesn't know what did/did not match.
Because if the extension knows what URLs you're accessing, and can send that data somewhere, that's a major privacy concern.
So this makes sense and seems good for privacy. But if it breaks uBlock Origin significantly, that seems like a very bad thing.
It’s a good theory, but it will still be possible to get an event for every single item that gets loaded. All they removed was the ability to block individual loads in that event. It is still entirely possible to collect that list of urls and snitch on the user.
Google is removing that dynamic blocking ability and providing you with a way to supply a static list of blocked urls instead. No ability to use code to implement a dynamic list.
It's somewhat similar to taking a virus scanner and only allowing it to identify a virus by the filename being in a static, pre-generated list.
Also, Google says they are doing this for privacy reasons. Which is funny, because OnBeforeRequest() isn't going away, just the ability to block a request inside of it. You can still see every request, inject javascript with content scripts, exfiltrate data, and so on. You just can't preemptively stop a url/resource from being loaded using code...only a static list of urls. You can guess the type of extensions that depend on that functionality.