> This work was motivated by one of the claims formulated in the Manifest V3 proposal of the Chromium project: "the extension then performs arbitrary (and poten

> This work was motivated by one of the claims formulated in the Manifest V3 proposal of the Chromium project: "the extension then performs arbitrary (and potentially very slow) JavaScript", talking about content-blockers' ability to process all network requests. From the measurements, we do not think this claim holds, as all popular content-blockers are already very efficient and should not incur any noticeable slow-down for users. Moreover, the efficiency of content-blockers is continuously improving, either thanks to more innovative approaches or using technologies like WebAssembly to reach native performance. Not commenting on if the proposed V3 changes are a good idea or not but aren't the changes not supposed to prevent badly written extensions from slowing everything down? It might be the case these adblockers are well written but you can't guarantee that for all extensions. If a user doesn't have an obvious way to know it's the fault of an extension then Chrome gets the blame. By the way, I have a Chrome extension that from its own tab requests many pages from arbitrary domains to examine their content. I need to modify the request headers going out and observe the response headers coming in, but only for requests made from the extension (so it's not impacting other tabs at all). I'm guessing V3 impacts this only if the request header modifications are dynamic and can't be added via the fetch API?