The "blocking" and "non-blocking" APIs do completely different things.
With the old API (webRequest), Chrome calls an extension's event handlers before every network request, and uses the result of the handler to decide whether to filter the request. This requires Chrome itself to block
With the new API (declarativeNetRequest), an extension sends a list of rules (i.e. URL patterns) to Chrome, and each rule specifies a static instruction that says how requests matching that pattern should be handled (for instance, being blocked, upgraded from HTTP to HTTPS, or redirected). So Chrome can use its own optimized lookup procedure and doesn't have to block waiting for extension code to complete, which might take arbitrarily long.
The privacy advantage is that the extension can tell Chrome how to handle network requests (in a much more limited way than before) but can't actually gain any information about what requests the user is making. But that's only part of the justification. The Chrome developers have stated in the past that they believe slow extensions using the old webRequest API are causing general browser performance problems (by doing lots of blocking computation on every request) and making it seem like it was Chrome's fault.
But don't they keep the original webRequest api in a way where it does not block and where an extension can observer all the traffice, do all the spying, but just cannot block requests?
The extension would need both the all_urls and webRequest permissions to do this, since you can only spy on requests to origins your extension has a host permission for. The review team discourages all_urls permissions and scrutinizes them more, so theoretically getting a spy onto the store with the right permission combo is hard. If you trust the review team.
Note that these regulations were established for MV2, and MV3 doesn't do anything new to address this. So there's still no benefit to MV3 on this topic. As far as I can tell, and I work with these APIs for a living, the privacy claims of MV3 are bogus.
With the old API (webRequest), Chrome calls an extension's event handlers before every network request, and uses the result of the handler to decide whether to filter the request. This requires Chrome itself to block
With the new API (declarativeNetRequest), an extension sends a list of rules (i.e. URL patterns) to Chrome, and each rule specifies a static instruction that says how requests matching that pattern should be handled (for instance, being blocked, upgraded from HTTP to HTTPS, or redirected). So Chrome can use its own optimized lookup procedure and doesn't have to block waiting for extension code to complete, which might take arbitrarily long.
The privacy advantage is that the extension can tell Chrome how to handle network requests (in a much more limited way than before) but can't actually gain any information about what requests the user is making. But that's only part of the justification. The Chrome developers have stated in the past that they believe slow extensions using the old webRequest API are causing general browser performance problems (by doing lots of blocking computation on every request) and making it seem like it was Chrome's fault.