As in, a content filter extension (or anything that interacts with a content filter) is run in a WASM sandbox without any access to the network or underlying system? It’s hermetically sealed from the rest of the extension, that might well need to make external requests to function.
The v3 fixes this by instead only letting bad blocker submit things they want blocking, and never letting them see that page. It’s not perfect by any means, but it is much more secure.
For example, iOS runs content filters in a special isolated process with no persistence or access to the outside world.
With this model, the content filter requests elements to be removed and the browser does the actual removal. As such, the scope of modifications can be reduced whilst keeping arbitrary and perhaps complex filtering logic.
“Send it somewhere else” being the important part.
The interface Chrome went with was a declarative list of filters that Chrome will use to perform the actual filtering, but the declarative interface isn’t great and wasn’t well received.
My point is: there is an interface that is non-declarative and sandboxed, whilst allowing Chrome to perform the actual filtering.
nope - the way ublock etc work is arbitrary code exec and arbitrary access to the urls and pages.
the new extension model that everyone hates is extreme sandboxing, but not letting adblockers do that.
In other words, the problem is poor sandboxing of extensions.