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.

> You can still see every request

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.

Why does uBlock Origin need to be able to block things dynamically?

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.

It's impossible to provide a list of all ads urls. Simple RegEx matching works better, but that requires a dynamic approach

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.

> It seems reasonable to require a static list for privacy reasons.

It's rich to cite privacy reasons for not allowing the blocking of ad sites whose goal is to spy on you.

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.

Ad sites know which urls I’m accessing, too. Google should prohibit those, too.

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.

They aren't removing the capability to monitor browsing.

The block list rules can have regexes, yes:

https://developer.chrome.com/docs/extensions/reference/decla...

I don't personally believe that solves anything. Domain names are cheap. If I don't want my ad to be blocked, I can just rotate through lots of them.

Google has responded to some pressure by upping the max number of rules and allowing some amount of dynamically defined rules.

From what I gather, this "Manifestv3" will change the permission system of browser extensions. Extensions won't be able to inject themselves into any website anymore, hence adblockers, which do this, won't function anymore. This may not be completely accurate, but I think is the gist of it. Maybe someone can correct me.

The Chrome devs claim that this is to enhance user security, but I have my doubts about that.

> The Chrome devs claim that this is to enhance user security, but I have my doubts about that.

Well, then it means they don't need to monitor their extension store for extensions doing bad things, I suppose it's part of the story.

An extension can steal personal data and manipulate pages with Manifest V3 APIs just like before, it does not become any harder for extensions to compromise browsers. There may be an argument that it becomes a bit less performant to execute the JS required to thoroughly compromise a browser, but I don't think such malware cares about microsecond performance losses.

Then what is preventing adblockers from working ? What's that fuss all about ?

Ad blockers will no longer be able to have granular and complete control over requests. Extensions will still be able to observe requests, but not edit them on the fly based on advanced and dynamic criteria.

Extensions will no longer be able to neutralize all current and future evasion techniques the advertising and tracking industry implements. Ad blocking and tracking protection extensions will be forced to degrade technologically by about 5 years, and then stagnate.

Ah, I see. I was still somehow under the impression that adblockers worked by hiding HTML tags :D.

Except the extension can still do loads of evil things... It's a bit like banning one type of gun, and saying "see, gun violence is now solved".

Lots of things are changing. Here is Google's migration guide.[1] I've also personally seen some issues with the `<all_urls>` and `https://*/*` permissions to allow access to all pages, though I have not seen those well-documented elsewhere and it could just be user error. I've gone back to Mv2 for now, planning to fork Chromium to re-enable it for my personal extensions.

https://developer.chrome.com/docs/extensions/mv3/intro/mv3-m...