Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove complicated heuristics for $domain modifier #1875

Open
Yuki2718 opened this issue Apr 14, 2024 · 13 comments
Open

Remove complicated heuristics for $domain modifier #1875

Yuki2718 opened this issue Apr 14, 2024 · 13 comments

Comments

@Yuki2718
Copy link

Yuki2718 commented Apr 14, 2024

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:

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

login

blocked

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

@ameshkov
Copy link
Member

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

@Yuki2718
Copy link
Author

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
Copy link
Member

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

@Yuki2718
Copy link
Author

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

@ameshkov
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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

@Yuki2718
Copy link
Author

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
Copy link
Member

ameshkov commented Jul 30, 2024

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

@Yuki2718
Copy link
Author

Yuki2718 commented Aug 1, 2024

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
Copy link

krystian3w commented Aug 1, 2024

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
Copy link
Member

ameshkov commented Aug 1, 2024

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

@Alex-302
Copy link
Member

Alex-302 commented Aug 9, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants