Thanks for the replay. Disclaimer, I worked on this study. > There's a few issues with the conclusion here. First, they article measures and discusses only the

Thanks for the replay. Disclaimer, I worked on this study. > There's a few issues with the conclusion here. First, they article measures and discusses only the time required to block a single request. Modern web pages are issuing many, many more requests than that, like the 35 that this page issues. At median timings, that would put the DuckDuckGo blocker at almost 300ms, well within what humans can notice. That is true, but on the other hand the DuckDuckGo blocker is the exception here and they could likely improve this performance if it becomes their focus (one way would be to use one of the faster open-source alternatives). If you consider uBlock Origin, Adblock Plus or Ghostery, we see that even blocking 100 requests would not take much time (probably around 1 ms with Ghostery). > The second is that this API is not used solely by the popular content blocking extensions, but by a variety of other extensions. The Chome team's performance concerns likely stem from the fact that a user won't be able to differentiate the browser slowing down and an errant extension slowing down the network requests, and there are examples of extensions that use this API to issue additional network requests or do slow things down. If you cherry-pick the good citizens of this API to show that performance isn't a problem in general, you're not showing that performance can't or shouldn't be the reason, just that it isn't the reason for the fast good citizens. What this data could be used to argue is that imposing strict deadlines on the execution time of these extensions would allow the content blockers that the community cares about to continue to function as they do today while also placing a performance cap on bad extensions. There are indeed examples of extensions doing bad things: collecting private data, etc. But we are talking about diminishing the potential privacy protection of all users to prevent some abuse. On the other hand, the manifest v3 will not prevent extensions from being slow, or doing bad things. Extensions will still be able to use content-scripts, inject arbitrary content in pages or send any private data home. WebRequest listeners will also still be accessible (only not in blocking mode) which can allow any data collection. So yes, I think these changes could in theory prevent some cases of abuse, but I strongly believe that they will overall weaken the privacy protection of users and that this is not an acceptable trade-offs.