Comment by ghostwords | Hacker News Reader

Comment by ghostwords | Hacker News Reader

Parent Full thread

DNR is better than at launch, but still full of feature gaps. How do you match a redirect response? How do you robustly rewrite URLs based on query parameters?[1]

The fundamental problem is that DNR is not an adequate replacement for webRequest. From something I wrote[2] a couple of years ago:

> [R]emoving blocking webRequest won’t stop abusive extensions, but will harm privacy and security extensions. If Manifest V3 is merely a step on the way towards a more "safe" (i.e., limited) extensions experience, what will Manifest V4 look like? If the answer is fewer, less-powerful APIs in service of “safety”, users will ultimately suffer. The universe of possible extensions will be limited to what Google explicitly chooses to allow, and creative developers will find they lack the tools to innovate. Meanwhile, extensions that defend user privacy and safety against various threats on the Web will be stuck in the past, unable to adapt as the threats evolve.

[1] https://github.com/w3c/webextensions/issues/302

[2] https://www.eff.org/deeplinks/2021/12/googles-manifest-v3-st...

For the most part I agree with your quote save for the “stuck in the past, unable to adapt” part, I’d replace with “lag behind”.

If the things continue to develop the way they are now, the new features will be eventually incorporated into DNR (in somewhat different form, but anyways). Basically, the “innovation” should be requested via the W3C group from the browsers and only then (after quite some time) it can be used as a part of DNR.

Is it worse than what we had before? Absolutely, adding anything to DNR is now a many-months process.

Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant.

I’d say that the situation changed from “MV3 is bad, DNR is unusable” to “MV3 is good, DNR is useable-but-limited”.

> If the things continue to develop the way they are now

I am not comfortable making that assumption! We already went through one "lost decade" for Chrome extensions.

Good comment. I guess it’s a matter of hope :) I really want to believe that the extensions platform will continue to develop with at least the same pace, and eventually comes to Android. Maybe I am over optimistic though, we’ll see, but otherwise I just don’t understand what was all that about and what justifies such a significant investment in the extensions team.

> Do we get anything in return? We actually do, the changes and improvements that are being made to the extensions platform are significant.

Honest question, what kind of significant improvements do you actually see in MV3? I see a lot of more restriced, more complex APIs but few new features.

I would argue that new APIs are better thought through and cover the use cases that the extensions actually need.

Let me name a few examples.

1. chrome.scripting API and the concept of "isolated worlds" is easier to use and understand than what we had before.

2. Dynamic content scripts registration that everyone has waited for so long.

3. userScripts API is also a welcome addition. It does not provide everything and it needs to be improved, but it is already a good step forward. Finally the existence of userscript managers was recognized by Chrome and they're trying to make life easier for them.

Also, the bug fixes. Before the expansion of the extensions platform team there were major bugs that could be open for many years, and now I see them closing one by one. To an outside observer it may look ridiculous that there was such a problem from the start, but that's how underinvestment looks like and I am happy that the situation improves.

Even DNR is not a bad API by itself, the problem that was never addressed is that in MV3 there is no blocking webRequest anymore and DNR cannot fully replace it.

edit: formatting

Sorry, but I have to disagree here.

> the concept of "isolated worlds" is easier to use and understand than what we had before.

Isn't this basically the same concept they already used with ordinary content scripts for years? It's indeed useful, but also something that could have been relatively easily emulated with dynamic execution inside a content script before, I believe.

> 2. Dynamic content scripts registration that everyone has waited for so long.

3. userScripts API is also a welcome addition.

Yes, but those too are just an improvement compared to the previous state of MV3. In MV2 none of those APIs would even be necessary because an extension could easily implement this stuff itself. So it's an "improvement" in the sense that it now only removes 30% of the functionality instead of the 50% it did before.

> Also, the bug fixes.

That's orthogonal to MV3 though. And it again sounds like "we're now slightly less shitty to extension devs than we were before".

> Even DNR is not a bad API by itself, the problem that was never addressed is that in MV3 there is no blocking webRequest anymore and DNR cannot fully replace it.

It's indeed not a bad API and there are many use cases in which it's clearly the better choice than the blocking version. However, the removal of the blocking variant and the removal of various usecases is Google's entire point here - otherwise, they wouldn't be so cagey with setting the limits of the number of rules. Firefox shows that it's no technical problem at all to implement both APIs at the same time.

> Isn't this basically the same concept they already used with ordinary content scripts for years?

It was implicit, now it's explicit and it gives more control and better understanding. It also allows introducing more levels of isolation, like a separate "USER_SCRIPTS" world or "MAIN", before that you had to mess with evals and adding script tags.

> Yes, but those too are just an improvement compared to the previous state of MV3

Yes, that's why I listed these as improvements.

> And it again sounds like "we're now slightly less shitty to extension devs than we were before".

They went from "1 person that tries to make things not crumble" to a large team of developers, it's a big step forward. What signal do we send them if we always say "everything you're doing is bad" even when it's factually not true?

> Firefox shows that it's no technical problem at all to implement both APIs at the same time.

At first we all thought that DNR is there for them to limit content blockers. With time they proved us wrong when they worked hard on improving it and covering more and more use cases.

Now I tend to think that this is an engineering decision that's driven by the other change - the shift from persistent background pages to service workers.

Is there a better solution that could save the blocking webRequest and achieving their goals at the same time? Most likely there is, but how hard would it be to implement it instead or what if it requires an architectural change? Anyways, these are speculations, I am with you here and I don't support blocking webRequest removal.

Reply on news.ycombinator.com