3 ms·

The most problematic part of MV3 (removing part of the webRequest API functionality) is a part of the platform. This remote JS stuff is a CWS policy.

Wowfunhappy 3y ago
So what can the webRequest API do that couldn't just be accomplished via Javascript injection? From my perspective—admittedly not really understanding how UBlock Origin works—Javascript is basically all-powerful on a web page. Once you have that, I'm surprised that anything else could be a meaningful restriction. (I appreciate you answering my questions!)
- ameshkov 3y ago
  JS is important, but it’s only a part of what’s required. webRequest allows the extension to manipulate web requests: blocking or redirecting them. MV3 tries to replace the old webRequest with a declarative alternative and it’s almost impossible to provide a declarative rule for every possible use case.
- lxgr 3y ago
  Javascript is very powerful, but simple injected Javascript can't e.g. undo requests (from other scripts or just normal resources like third-party images) that have already happened. An injected script is not guaranteed to run before the site's own scripts, I believe. Other than that, you can probably really do everything you could do with the webRequest API, but the complexity of doing it essentially reduces to the halting problem: You'd have to statically analyze all Javascript loaded by the page and figure out if it's going to do any requests you don't want to happen and then rewrite these parts. Maybe there's clever things you could do by shimming all web APIs that can issue HTTP or other requests, but that also doesn't sound fun. On the other hand, with an API that just gets to veto every outgoing request, you can trivially achieve the same goal. Another area where in-page Javascript is limited compared to an extension is the same origin policy. A very fancy ad-blocking extension could e.g. run an image classification AI on third-party image resources and hide the ones that look like visually distracting, flashing etc. ads by default – in-page Javascript can't.
  - Wowfunhappy 3y ago
    Thank you! I guess the main problem is figuring out which elements are ads. Blocking certain requests is a handy way to do that, at least for as long as external ad servers are the norm. > Simple injected Javascript can't e.g. undo requests (from other scripts or just normal resources like third-party images) But could you detect the request, see what element it loaded in, and then hide that element? Or is that much more complicated than I'm imagining?
    - lxgr 3y ago
      If you only care about visual annoyances I believe that should generally be possible (although I also don't know the details!), but many people also use content filters to stop third-party tracking.

Wowfunhappy 3y ago

So what can the webRequest API do that couldn't just be accomplished via Javascript injection? From my perspective—admittedly not really understanding how UBlock Origin works—Javascript is basically all-powerful on a web page. Once you have that, I'm surprised that anything else could be a meaningful restriction. (I appreciate you answering my questions!)

ameshkov 3y ago
JS is important, but it’s only a part of what’s required. webRequest allows the extension to manipulate web requests: blocking or redirecting them. MV3 tries to replace the old webRequest with a declarative alternative and it’s almost impossible to provide a declarative rule for every possible use case.
lxgr 3y ago
Javascript is very powerful, but simple injected Javascript can't e.g. undo requests (from other scripts or just normal resources like third-party images) that have already happened. An injected script is not guaranteed to run before the site's own scripts, I believe. Other than that, you can probably really do everything you could do with the webRequest API, but the complexity of doing it essentially reduces to the halting problem: You'd have to statically analyze all Javascript loaded by the page and figure out if it's going to do any requests you don't want to happen and then rewrite these parts. Maybe there's clever things you could do by shimming all web APIs that can issue HTTP or other requests, but that also doesn't sound fun. On the other hand, with an API that just gets to veto every outgoing request, you can trivially achieve the same goal. Another area where in-page Javascript is limited compared to an extension is the same origin policy. A very fancy ad-blocking extension could e.g. run an image classification AI on third-party image resources and hide the ones that look like visually distracting, flashing etc. ads by default – in-page Javascript can't.
- Wowfunhappy 3y ago
  Thank you! I guess the main problem is figuring out which elements are ads. Blocking certain requests is a handy way to do that, at least for as long as external ad servers are the norm. > Simple injected Javascript can't e.g. undo requests (from other scripts or just normal resources like third-party images) But could you detect the request, see what element it loaded in, and then hide that element? Or is that much more complicated than I'm imagining?
  - lxgr 3y ago
    If you only care about visual annoyances I believe that should generally be possible (although I also don't know the details!), but many people also use content filters to stop third-party tracking.