Remove complicated heuristics for $domain modifier

[Yuki2718]

I mean

$domain modifier matching target domain:

In some cases the $domain modifier can match not only the referrer domain, but also the target domain. This happens when all the following conditions are met:

1. The request has the document content type
2. The rule pattern does not match any particular domains
3. The rule pattern does not contain regular expressions
4. The $domain modifier contains only excluded domains, e.g. $domain=~example.org|~example.com

This seems to be the culprit of false positive I fixed.

STR:

0. Add ://www2.etc-$document,domain=com|net|icu
1. Set languages for Google search to Japanese (and maybe use Japanese VPN).
2. Search for ETC利用照会サービス
3. Click ログイン

IMO the heuristics is no more needed, as we now have $to and it should be decided by filter author in actual context.

[ameshkov]

As I recall there were lots of $cookie rules that were using $domain to point to a target domain?

[Yuki2718]

As I recall there were lots of $cookie rules that were using $domain to point to a target domain?

They can be converted to $to.

[ameshkov]

But are they converted in other filter lists? Like uBO lists for instance?

[Yuki2718]

uBO doesn't support $cookie in the first place.

[ameshkov]

Sorry, I may be confusing things now, but I recall that in uBO filters something similar was used for other rule types, maybe it was $removeparam?

[Yuki2718]

I don't remember, but I can say we uBO team always assume $domain works as $from, meaning it is used only for base domain than target.

[ameshkov]

Got it, thank you! I generally like the idea and this whole heuristic was made for compatibility reasons back in the day.

[Yuki2718]

uBlockOrigin/uBOL-home#156 Somewhat related and AGMV3 is also affected. Do all the AG products now support $to and can I safely change these $domain rules in Japanese filter for malicious sites to $to? E.g. /\/t_([0-9A-Za-z]{32})\?token=\1/$document,domain=cn|com|net|top.

[ameshkov]

All save for Safari-based: AdguardTeam/SafariConverterLib#60 (but I think it can't be properly implemented there anyway)

[Yuki2718]

It's a bit problematic if we have to use $domain for Safari and $to for MV3. Fortunately there are not too many $document rules with $domain so maybe we can use hint or !#if.

[krystian3w]

Maybe you're talking about a problem with the referer:

#1579
#1421

In AdGuard 4.2+ add-on, opening links from Google causes a strict block prompt again for good sites. I haven't tested yet replace domain/from with to= to unlock opening good pages and prompt warning for scam/malware.

[ameshkov]

Safari most likely won't be able to apply $to properly anyway

[Alex-302]

Related problem with 3p filter
AdguardTeam/AdguardFilters#185543 (comment)