webmusic.live

[ghajini]

URL(s) where the issue occurs

http://webmusic.live/music/mobile/hindi/file.php?id=43167

Describe the issue

popup ads

Screenshot(s)

Versions

• Browser/version: firefox 80.0.1
• uBlock Origin version: 1.29.2

Settings

uBO's default settings

Notes

[stephenhawk8054]

In this site: https://reyohoho.github.io/reyohoho/#61249, this connection

https://aj2635.bid/zzjvcxiIpdeoOECJJu8G8uepAT-OAwdErQ4NLZg85splTGCYAWBtHsbpPDXtNubow6HYGFaVt5MsEthhAX64r8eF1fzQiufXj2aqtFkRU65MKMXnjgz4?vpaid=false&ch=reyohoho.github.io

is not blocked in uBOL. I think maybe because /^https:\/\/(?:cdn77\.)?aj\d{4}\.bid\/[-_0-9A-Za-z]{80,}\?/$xhr,3p,to=bid is discarded by DNR. Anybody has a good filter for uBOL, or should we block it per-site?

[ghajini]

rule works fine in AG mv3

[mapx-]

I see no such (rejected) regex in the log.txt
https://github.com/uBlockOrigin/uBOL-home/blob/main/chromium/log.txt

[stephenhawk8054]

rule works fine in AG mv3

I don't think so. When I added it as custom filter in AG MV3, the XHR connection still loads for me:

https://github.com/user-attachments/assets/48db53aa-08e3-46c9-a93c-9f1b12ee8c51

Note that when you see AG log puts a red (blocked) line, it just means that the connection is supposed to be blocked by the regex (assumed rule), but the real blocking depends on browsers' DNR

https://github.com/user-attachments/assets/6f1e3222-8e8e-4225-8729-a39a95b2c269

https://adguard.com/kb/adguard-browser-extension/solving-problems/debug-rules/

In AdGuard for Chrome MV3, the Filtering log only shows the approximate rules that were applied, which we call “assumed rules”. This is because the browser doesn’t provide details about which specific declarative rules were used unless the extension is in an “unpacked” format. To get precise information, you’ll need to install the unpacked version of the extension in your browser yourself.

[stephenhawk8054]

I see no such (rejected) regex in the log.txt https://github.com/uBlockOrigin/uBOL-home/blob/main/chromium/log.txt

Yeah, the log is just for the filters that are rejected by DNR pre-compiled. There are regex cases where you can only know if DNR rejects the regex when you loads the extension at run-time (in the console as gorhill said): #26671 (comment)

[mapx-]

/^https:\/\/(?:cdn77\.)?aj\d{4}\.bid\/.*\?/$xhr,3p,to=bid

[stephenhawk8054]

Yeah, I think that could work.

[mapx-]

with ?vpaid eventually

[stephenhawk8054]

Yeah, I'll check if I can find other sites with same connections or not. This is an old issue so it might be hard to other examples.

[Yuki2718]

I don't see the request, a connectioon to 4f463c79.obrut.show is rejected. But why
/^https:\/\/(?:cdn77\.)?aj\d{4}\.bid\/.*\?/$xhr,3p,to=bid works if /^https:\/\/(?:cdn77\.)?aj\d{4}\.bid\/[-_0-9A-Za-z]{80,}\?/$xhr,3p,to=bid doesn't?

[mapx-]

aj* crap only if you click play

[mapx-]

[\w\W]{80,} does not work too

[stephenhawk8054]

But why
/^https:\/\/(?:cdn77\.)?aj\d{4}\.bid\/.*\?/$xhr,3p,to=bid works if /^https:\/\/(?:cdn77\.)?aj\d{4}\.bid\/[-_0-9A-Za-z]{80,}\?/$xhr,3p,to=bid doesn't

I think it's because of {80,}. The isRegexSupported() is purely based on browsers deciding about "performance" themselves, so maybe they think that regex is too expensive?

[ghajini]

rule works fine in AG mv3

I don't think so. When I added it as custom filter in AG MV3, the XHR connection still loads for me:

https://github.com/user-attachments/assets/48db53aa-08e3-46c9-a93c-9f1b12ee8c51

Note that when you see AG log puts a red (blocked) line, it just means that the connection is supposed to be blocked by the regex (assumed rule), but the real blocking depends on browsers' DNR

https://github.com/user-attachments/assets/6f1e3222-8e8e-4225-8729-a39a95b2c269

https://adguard.com/kb/adguard-browser-extension/solving-problems/debug-rules/

In AdGuard for Chrome MV3, the Filtering log only shows the approximate rules that were applied, which we call “assumed rules”. This is because the browser doesn’t provide details about which specific declarative rules were used unless the extension is in an “unpacked” format. To get precise information, you’ll need to install the unpacked version of the extension in your browser yourself.

you are correct

[stephenhawk8054]

Just for testing. This works for me:

/^https:\/\/(?:cdn77\.)?aj\d{4}\.bid\/[-_0-9A-Za-z]{13}/$xhr,3p,to=bid

but this doesn't work for me:

/^https:\/\/(?:cdn77\.)?aj\d{4}\.bid\/[-_0-9A-Za-z]{14}/$xhr,3p,to=bid

so yeah, it's just the browser's decision.

[mapx-]

this is working

/^https:\/\/(?:cdn77\.)?aj\d{4}\.bid\/[^?]{30,}\?/$xhr,3p,to=bid

when >30 does not work

[stephenhawk8054]

Confirm it works 👍

DNR's regex is such a mess : ))

[mapx-]

{n,m} quantifier
Chrome: supports, but many rules fail with memoryLimitExceeded

w3c/webextensions#344

[Yuki2718]

The player doesn't work on my end (connection refused), but looking at #7900 (comment), maybe no need for regex? ://aj*?vpaid=false&ch=$xhr,3p,to=bid|online might be enough, though I don't know if this works for other sites (can be added to EL if it's universal).

[Yuki2718]

Looks now the site was parked.

[stephenhawk8054]

Which site?

[Yuki2718]

Which site?

webmusic.live

[ghajini]

Looks now the site was parked.

removed
f646f48