3 ms·

Humm, no: https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-asked-questions-(FAQ)#filtering-capabilities-which-cant-be-ported-to-mv3 https://github.com/

Humm, no: https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-asked-questions-(FAQ)#filtering-capabilities-which-cant-be-ported-to-mv3 https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as...

moi2388 2y ago
Uhm, yes. You can still apply rules with regard to all requests and then dynamically adept them. You just can’t do it before the request hits the browser, so you can’t pretend to be a vpn inside the browser. Blocking or redirecting all requests, based on dynamic values, adapting all headers through webrequest and not showing any ads and removing them from the page is still possible with service workers and content scripts. The only issue is with regards to “static” rules and modifying them before they hit the browser. After that you can still do everything you could before. The only issue is bandwidth, but this should always have been an app to intercept all network requests instead of something inside the browser (like a vpn adblocker)
- zarzavat 2y ago
  If you use a VPN^ to block ads then the VPN needs to be able to see inside your TLS session. Moreover, you still need an adblocker inside the browser process to do DOM manipulation, etc. For example, the element picker. It’s technically possible to bifurcate an adblocker like that but it’s an ugly setup and you would only do it if a gun was held to your head by an ad monopoly. That said, it may be a good idea in the current situation. ^ This is really stretching the meaning of ‘VPN’!
  - moi2388 2y ago
    But you can totally still block ads based on element picker and do DOM manipulation. That’s not an issue. The only two things you cannot do is declare them as static rules (well you can but not unlimited), and look and modify every header before it hits the browser. And yes, you could have an app with a browser extension like Adblock already did for years without issues. You could also have only a browser extension and have all the user functionality you have now, the only difference being it just slightly slower, and you still having the network load the ads (but not the page you’re on). A bit annoying? Sure. But it’s hardly the severe problem it’s being made out to be.
- Sophira 2y ago
  > The only issue is bandwidth It's not just bandwidth, though. It's also about not allowing ad companies to collect data about you such as which sites you view. Not showing ads is important, but it's only half the battle.
  - moi2388 2y ago
    Which you can also still do, with around 30k static and 5k dynamic rules with regex possibilities. Which is a lot. And even if you somehow hit this number, afterwards you can still intercept every request before the user sees it to modify headers or remove ad content. Is it annoying? Sure. But again, you can technically still do everything you could before.

moi2388 2y ago

Uhm, yes. You can still apply rules with regard to all requests and then dynamically adept them. You just can’t do it before the request hits the browser, so you can’t pretend to be a vpn inside the browser. Blocking or redirecting all requests, based on dynamic values, adapting all headers through webrequest and not showing any ads and removing them from the page is still possible with service workers and content scripts. The only issue is with regards to “static” rules and modifying them before they hit the browser. After that you can still do everything you could before. The only issue is bandwidth, but this should always have been an app to intercept all network requests instead of something inside the browser (like a vpn adblocker)

zarzavat 2y ago
If you use a VPN^ to block ads then the VPN needs to be able to see inside your TLS session. Moreover, you still need an adblocker inside the browser process to do DOM manipulation, etc. For example, the element picker. It’s technically possible to bifurcate an adblocker like that but it’s an ugly setup and you would only do it if a gun was held to your head by an ad monopoly. That said, it may be a good idea in the current situation. ^ This is really stretching the meaning of ‘VPN’!
- moi2388 2y ago
  But you can totally still block ads based on element picker and do DOM manipulation. That’s not an issue. The only two things you cannot do is declare them as static rules (well you can but not unlimited), and look and modify every header before it hits the browser. And yes, you could have an app with a browser extension like Adblock already did for years without issues. You could also have only a browser extension and have all the user functionality you have now, the only difference being it just slightly slower, and you still having the network load the ads (but not the page you’re on). A bit annoying? Sure. But it’s hardly the severe problem it’s being made out to be.
Sophira 2y ago
> The only issue is bandwidth It's not just bandwidth, though. It's also about not allowing ad companies to collect data about you such as which sites you view. Not showing ads is important, but it's only half the battle.
- moi2388 2y ago
  Which you can also still do, with around 30k static and 5k dynamic rules with regex possibilities. Which is a lot. And even if you somehow hit this number, afterwards you can still intercept every request before the user sees it to modify headers or remove ad content. Is it annoying? Sure. But again, you can technically still do everything you could before.