Hacker News Reader

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.

> 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.

I can choose to not install extensions that do these things, while using ones that only have a manifest list…

I agree with you, and that's why I would like to see this declarative API being an addition to the current WebRequest API. This way there could be extensions using it exclusively and users could decide to pick these if they offer sufficient privacy protection for their taste. On the other hand, you would still have the option of installing more powerful extensions using the dynamic APIs (allowing things which will never be possible with the declarative API).

Yup, I’m not saying that the old API should be killed; it’s just that it’s convenient to have the new one and be able to “trust” the extension to not be able to slow down my browsing, steal information from the page, etc. but also be able to fall back to something I do trust for what gets through if necessary.

As you suggest, there are many ways to punish the bad citizens (slow or malicious extensions) without harming the good ones, which is what manifest v3 will do. You can solve with UX (e.g. showing that an extension is slowing down a page), or imposing strict guidelines on extensions for webrequest API times. Google is already quite strict on many aspects for extensions (e.g. obfuscated code was forbidden recently), so I don't see why they cannot be strict also with performance.

Right, but again, if that's what you want to argue, this article is not the way to do it. Concluding that the performance claim doesn't hold because the top performers are performant is different than saying something along the lines of "While performance may be an issue in some cases, it clearly does not have to be to achieve this use case we care about, and so we should think about alternative solutions".

Arguing this correctly is extremely important if the community wants to change Google's mind, and the miscellaneous fear-mongering and accusations of bullshit motivations that are flying around this and other threads can be easily dismissed if we aren't more careful about how we conclude analyses like these.

Slowing down requests can be intentional, so even putting a cap on it would limit legitimate usecases. Instead the information should simply be surfaced to the user so they can decide to remove the extension if they don't want the slowdowns.