logoalt Hacker News

zamadatix • yesterday at 11:49 PM • 1 reply • view on HN

https://github.com/uBlockOrigin/uBOL-home/wiki/Frequently-as... has a few of the more practical concrete examples. Namely content can load without the blocker being ready to filter, CNAME cloaking can't be handled properly (in Chrom* at least), and the filter rules aren't as flexible.

Interestingly, the rule count limits themselves do not (currently) seem to be much an issue despite it being one of the more common concerns on the original MV3 announcement.

Replies

taviso • today at 12:42 AM

> content can load without the blocker being ready to filter

This isn't an MV3 issue, it's a Chromium design decision that extensions cannot block browser initialization. It was also true with MV2. In fact, MV3 has improved the situation because DNR rules are enforced immediately.

You could certainly argue that Chrome should allow extensions to block browser initialization, or that it should be user configurable - but it seems like an entirely defensible Chrome decision. Regardless, it's nothing to do with MV3.

> the filter rules aren't as flexible.

That's true, but they are still very flexible, and DNR makes some very nice features possible in uBO lite that were not possible in uBO.

For example, did you know that you can change your User-Agent with uBO lite? Go to the Custom DNR rules tab, and enter something like this to pretend to be Lynx on whatever.com:

     id: 5
     priority: 100
     action:
       type: modifyHeaders
       requestHeaders:
         - header: User-Agent
           operation: set
           value: Lynx/2.9.2 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/3.5.7
     condition:
       requestDomains:
         - whatever.com
       resourceTypes:
         - main_frame
I don't think that's possible in uBO, so clearly there are some benefits to switching. I have a ton of custom dnr rules, and love this feature.