adfilt
adfilt copied to clipboard
DandelionSprout
github blocking rule blocks too much
Describe the problem below this line as meticulously and detailed as possible (incl. pagelinks if any)
This blocking rule is somehow included in the annoyances list, but also it blocks a lot more than expected. E.g. it blocks all *.github.io subdomains, and api.github.com is also blocked.
Add screenshots below if needed
No response
Add a screenshot of the extension's logger
Which adblocker(s) did you use when testing this?
AdGuard (Paid desktop/Android versions - Standard filtering + DNS Blocking™™©)
Adblocker version(s)
AdGuard Android v4.3.1
Which filterlists did you use? Failing to tell this will temporarily close the report until it has been told.
Annoyances List, updated Jan 8
Which browser(s) did you use when testing this?
Google Chrome (Manifest V2), Firefox (incl. LibreFox)
Browser version(s)
N/A as this is the DNS blocking capabilities
Which OS(s) did you use when testing this?
Android
OS version(s)
14
Considering the ~io part, it is a mystery to me at the moment why it gets blocked, but I will of course look into it today.
Hmm, after reading your comment, I just tested it against uBlock Origin, and it works fine. Maybe this is an adguard problem. @ameshkov thoughts?
@DandelionSprout if you come to the same conclusion, we can close this and I'll try and move this issue to somewhere more relevant.
Seems to me like an "HTTPS tunnel" bug, at which point it'd be virtually impossible for me to reproduce it, since I don't even know how to turn on that function. 😅 But yes, seem in my eyes like a bug.
@DandelionSprout well, it's rather easy to reproduce it, just disable HTTPS filtering in AG.
The explanation is that when HTTPS filtering is disabled AG considers every connection as a document request and evaluates rules against https://domain.com/
It's hard to expect people to whitelist every subdomain of github, e.g. the .io is of course dynamic since every user and org can potentially have one. In addition, for github.com there's more than just api.github.com, I've also seen e.g. alive.github.com.
I'm not sure what the solution is here, but I think the filter itself is valid. I've raised a bug request in AdGuardForAndroid.
I honestly don't see what's a bug here, the rule is supposed to block domains with word github there, it blocks them, works as expected.
The bug would be that it's not taking into account the domain directive no?
Ah, got it, the rule should use $denyallow instead, $domain specifies the source domain, not the target domain
Surely there wouldn't be differences between $domain=~(…) and $denyallow= for the purposes of first-party page loading? I'm still convinced that something related to "HTTPS Tunnel" would surely be affecting this?
@DandelionSprout well, that's a question of how these modifiers are interpreted by different ad blockers.
In AdGuard the conditions for $domain to be interpreted as a target domain are stricter than just first-party page loading:
$denyallow is safer tbh.
Okay, so checking out the app menus a bit better (and in English this time), OP's screenshot showing the Firefox logo and the "HTTP Tunnel" text indicates it cannot possibly be DNS-type filtering. The latter would've used a generic "Android head on green grid" logo and something like "A Request" or "AAAA Request". So "(…) this is the DNS blocking capabilities" seems to have been an honest mistake.
If I understand Meshkov's screenshot correctly, the entry seems to not match factor 3, as the entry visibly has regular expressions.
As such, I struggle to imagine a scenario where my entry would give this false positive, albeit with $~third-party (Equal to $1p in uBO) added to the entry just to be sure.
• "(…) the rule does not need to match the second and third conditions to match (…)" Huh.
I'll think of something else now. Of some sort.
Does it work any better after I added a non-~ $domain value a couple days ago?
I've just updated the filters, and checked a few domains, *.github.io seems to load correctly, same with api.github.com. I tried a few tlds, github.sale was blocked by a different filter, and github.cc was not blocked as expected (though, it seems that github.cc is owned by github, as it redirects to github.com)
It seems to work in uBlock Origin. Though they convert lists' values (and orders of values) to their own syntaxes, the entry I added above does seem to work in uBO, at least.