4 ms·

Are you familiar with declarativeNetRequest? It's already in use by tools like AdGuard and uBlock Origin Lite. I've tested both and they work very well. I th

Are you familiar with declarativeNetRequest? It's already in use by tools like AdGuard and uBlock Origin Lite. I've tested both and they work very well. I think it's very clear that adblockers are still possible in MV3, despite concerns. https://chrome.google.com/webstore/detail/adguard-adblocker-mv3-exp/apjcbfpjihpedihablmalmbbhjpklbdf https://chrome.google.com/webstore/detail/adguard-adblocker-... https://chrome.google.com/webstore/detail/ublock-origin-lite/ddkjiahejlhfcafbddmgiahcphecmpfh https://chrome.google.com/webstore/detail/ublock-origin-lite...

deleted 4y ago
[deleted]
Vinnl 4y ago
DNR doesn't cover all use cases that uBO tries to address, AFAIK, so some tracking will still be possible. Regardless, the point about a Google-only web resulting in restrictions stands even without that: https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...
- toastal 4y ago
  I'm also happy that the project focuses on Fx’s performance first and foremost
- SquareWheel 4y ago
  I read through the page and these features seem... not great? Some of them might be considered anti-features. The Browser Launch feature says that Firefox always waits for extensions to load network requests whereas Chrome gives an option to wait via a setting. So in this case, you're trading performance (parallelizing the work) for privacy (may not catch a tracking request). It's a tradeoff I'm sure many are willing to make, but I like that Chrome offers the setting. I tend to err towards performance, myself. WebAssembly says it isn't used - not because it isn't available - but because it would add an extra permission to the manifest. That is to say, Chrome informs you of this when installing extensions and Firefox doesn't. That's a minor implementation detail at best, and I think a case can be made that providing more granular scopes is a positive thing. Then pre-fetching. Are they really disabling a major performance feature by default? I've used pre-fetching to good effect when the browser's resource scanner ran at the wrong times. The option should exist but this is a terrible default. The other features are more reasonable. HTML filtering could be useful for adversarial sites like Twitch.tv that actively fight adblockers. Storage Compression seems like a useful optimization if you have a lot of extensions installed that populate IndexedDB. I'm assuming it's caching those values rather than doing a "first time setup" every time a new private window is launched. I'll readily admit there may be more intent behind these features than is expressed in these blurbs, but on initial glance I wouldn't say anything here is critical. The pre-fetching one in particular seems like a negative.
  - Vinnl 4y ago
    Hmm, I haven't looked at all of them in detail, but CNAME uncloaking in particular I believe is a very commonly used tracking vector.

deleted 4y ago

[deleted]

Vinnl 4y ago

DNR doesn't cover all use cases that uBO tries to address, AFAIK, so some tracking will still be possible. Regardless, the point about a Google-only web resulting in restrictions stands even without that: https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-best-on-Firefox https://github.com/gorhill/uBlock/wiki/uBlock-Origin-works-b...

toastal 4y ago
I'm also happy that the project focuses on Fx’s performance first and foremost
SquareWheel 4y ago
I read through the page and these features seem... not great? Some of them might be considered anti-features. The Browser Launch feature says that Firefox always waits for extensions to load network requests whereas Chrome gives an option to wait via a setting. So in this case, you're trading performance (parallelizing the work) for privacy (may not catch a tracking request). It's a tradeoff I'm sure many are willing to make, but I like that Chrome offers the setting. I tend to err towards performance, myself. WebAssembly says it isn't used - not because it isn't available - but because it would add an extra permission to the manifest. That is to say, Chrome informs you of this when installing extensions and Firefox doesn't. That's a minor implementation detail at best, and I think a case can be made that providing more granular scopes is a positive thing. Then pre-fetching. Are they really disabling a major performance feature by default? I've used pre-fetching to good effect when the browser's resource scanner ran at the wrong times. The option should exist but this is a terrible default. The other features are more reasonable. HTML filtering could be useful for adversarial sites like Twitch.tv that actively fight adblockers. Storage Compression seems like a useful optimization if you have a lot of extensions installed that populate IndexedDB. I'm assuming it's caching those values rather than doing a "first time setup" every time a new private window is launched. I'll readily admit there may be more intent behind these features than is expressed in these blurbs, but on initial glance I wouldn't say anything here is critical. The pre-fetching one in particular seems like a negative.
- Vinnl 4y ago
  Hmm, I haven't looked at all of them in detail, but CNAME uncloaking in particular I believe is a very commonly used tracking vector.