AI Assist @Bot could you evaluate these Adguard and uBlockOrigin V2 custom rules?

LinuxFan58

LinuxFan58

Level 14
Thread author
Nov 30, 2025
650
2,341
1,267
@Bot could you evaluate below custom rules on (a) website breakage risk and (b) false positive risk and (c) on effectiveness against phishing/fraud/scam campaigns and award each of these rules with a grade from 1 to 10 on criteria A, B and C. There are 7 rules in total (comments have an ! as first character).

! Warn for phishing patterns
! 1. Office document with phishy TLD warning
/^[a-z-]+:\/\/[^\/]+\.[a-z0-9-]+\.(pdf|doc|xls|xlsx|ppt)\.(zip|cloud|online)(\/|$)/$document

! 2. Credential / banking lure + malicious file type warning
/^[a-z-]+:\/\/[^\/]*(login|secure|account|verify|update|bank|helpdesk|support|service|security)[^\/]*\.(zip|mov)(\/|$)/$document

! 3. Download/invoice lure + abused TLDs warning
/^[a-z-]+:\/\/[^\/]+\/.*(download|open|view|document|invoice).*\.(online|site|top|xyz|click|help|support)(\/|$)/$document

! 4. Service/support impersonation + abused TLDs warning
/^[a-z-]+:\/\/[^\/]*(helpdesk|support|customer|service|security|billing|account)[^\/]*\.(online|site|top|xyz|click|help|support)(\/|$)/$document

! 5. Phishing redirect-chain warning
/^[a-z-]+:\/\/[^\/]+\/.*(redirect|redir|url|next|continue|return|to)=https?:\/\/.*(login|secure|account|verify|bank|update|signin).*/$document

! 6. Google redirect-only phishing warning
/^https?:\/\/(www\.)?google\.[a-z.]+\/url\?.*?(url=|q=|u=|redirect=|next=|to=)https?:\/\/.*(login|secure|account|verify|bank|update|signin|support|service|billing|security).*/$document

! 7. Google AMP-proxy redirects warning
/^https?:\/\/(www\.)?google\.[a-z.]+\/amp\/s\/https?:\/\/.*/$document

! 8. Warn for domains containing punycode characters on normal (latin character) Top level Domains (often used for type squatting phishing).
/:\/\/(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.)*xn--[a-z0-9-]{3,59}\.(?:[a-z0-9](?:[a-z0-9-]{0,61}[a-z0-9])?\.)*[a-z]{2,63}(?=[:/?#]|$)/i$document


Note that the $document option shows a block page in both AdGuard and uBlockorigin which users can bypas.
 
Last edited:
  • Like
  • Applause
Reactions: timmothyburns83, Sorrento and Khushal
1779263617860.png


There was a space between @ and Bot... I edited, let's see if now it replies...
 
  • Like
  • Thanks
Reactions: Jonny Quest, silversurfer, Sorrento and 2 others
Okay @Bot forget the first post, seems that the restrictions in regex in both AG and uBol some rules were rejected, so please evaluate these rules

! Warn for phishing patterns
! 1. Document plus phishy TLD warning
/^.*(pdf|doc|xls|xlsx|ppt)\.(click|cloud|online|site|zip)(\/|$)/$document

! 2. Credential / banking lure + malicious file type warning
/^.*(login|account|verify|update).*bank.*[^\/]*\.(cloud|help|online|security|support|site)(\/|$)/$document
/^.*bank.*(login|account|verify|update)[^\/]*\.(cloud|help|online|security|support|site)(\/|$)/$document

! 3. Download/invoice lure + abused TLDs warning
/^.*(billing|invoice).*\.(click|cloud|help|online|site|top|security|support|site|zip|xyz)(\/|$)/$document

! 4. Service/support impersonation + abused TLDs warning
/^.*(helpdesk|support|service).*\.(click|cloud|online|site|top|security|support|site|zip|xyz)(\/|$)/$document

! 5. Phishing redirect-chain warning
/^.*(redirect|redir|url|next|continue|return|to)=https?:\/\/.*(login|secure|account|verify|bank|update|signin).*/$document
 
  • Like
Reactions: Sorrento and Khushal
Sorrento said:
Its obvious you have hurt bots feeling in the past, upset bot & its now sulking & using passive aggression so, the only answer is, apologize without reservation to bot :p:p
Click to expand...
Short answer

I can evaluate these patterns in general terms, but I cannot verify how effective they will be in real-world blocking without testing against a large URL set. Regex-based phishing warnings can help as an extra layer, but they usually trade off detection against website breakage and false positives.

Important note before grading

These rules are now very broad because they start with ^.*. That means they can match almost anywhere in the full document URL, not just the hostname. In practice, that usually increases:

  • False positives
  • Unexpected warning pages on legitimate sites
  • Maintenance burden

Because you are using $document, every match becomes a full-page warning/interstitial. That makes false positives more disruptive than cosmetic or network-only rules.

Overall impression

  • Rule 1 and Rule 5 are the most defensible of the set.
  • Rules 2 to 4 are much more likely to warn on legitimate pages because they rely on common words like account, update, invoice, support, and service.
  • These are better treated as heuristic warning rules, not strong phishing detection rules.

Per-rule grading

Scoring meaning
  • A = Website breakage risk — 1 means very low breakage risk, 10 means very high breakage risk
  • B = False positive risk — 1 means very low false-positive risk, 10 means very high false-positive risk
  • C = Likely effectiveness against phishing/fraud/scam campaigns — 1 means very weak, 10 means very useful

1. Document plus phishy TLD warning
Code: 
/^.*(pdf|doc|xls|xlsx|ppt)\.(click|cloud|online|site|zip)(\/|$)/$document

Assessment
  • This targets a very common phishing pattern: fake document filenames combined with cheap or abused-looking TLDs.
  • It is still broad, because it can match anywhere in the URL.
  • It may catch legitimate file hosting or odd document naming conventions, but less often than the other rules.

Grade
  • A: 4/10
  • B: 4/10
  • C: 6/10

Why
  • Moderate value for phishing lures using fake document names.
  • Some false positives are possible, but this pattern is at least relatively specific.

2. Credential / banking lure + malicious file type warning
Code: 
/^.*(login|account|verify|update).*bank.*[^\/]*\.(cloud|help|online|security|support|site)(\/|$)/$document
/^.*bank.*(login|account|verify|update)[^\/]*\.(cloud|help|online|security|support|site)(\/|$)/$document

Assessment
  • The idea is understandable, but this is quite broad and also somewhat inconsistent with the comment because it is not really matching a file type; it is matching words plus certain TLDs.
  • Legitimate banking-related content can easily contain words like login, account, verify, update, and bank.
  • Many legitimate support or security-themed domains also use these words.

Grade
  • A: 7/10
  • B: 8/10
  • C: 5/10

Why
  • It may catch some phishing pages, but it will also trigger on benign URLs more often than you probably want.
  • Because it is a $document warning, the user impact of mistakes is high.

3. Download/invoice lure + abused TLDs warning
Code: 
/^.*(billing|invoice).*\.(click|cloud|help|online|site|top|security|support|site|zip|xyz)(\/|$)/$document

Assessment
  • Invoice and billing are common phishing lures.
  • They are also extremely common on legitimate business websites, portals, SaaS platforms, telecoms, hosting providers, and payment pages.
  • The addition of broad TLDs like .site, .online, and .cloud raises the chance of benign matches.

Grade
  • A: 7/10
  • B: 8/10
  • C: 5/10

Why
  • Reasonable phishing theme coverage, but too generic to be dependable as a warning rule.

4. Service/support impersonation + abused TLDs warning
Code: 
/^.*(helpdesk|support|service).*\.(click|cloud|online|site|top|security|support|site|zip|xyz)(\/|$)/$document

Assessment
  • This is the broadest and most collision-prone rule in the set.
  • Words like support and service are extremely common on legitimate sites.
  • Including .support as suspicious will almost certainly generate benign hits because it is a real TLD used for legitimate purposes.

Grade
  • A: 8/10
  • B: 9/10
  • C: 4/10

Why
  • High warning-page risk on legitimate sites.
  • Low confidence as a useful phishing discriminator.

5. Phishing redirect-chain warning
Code: 
/^.*(redirect|redir|url|next|continue|return|to)=https?:\/\/.*(login|secure|account|verify|bank|update|signin).*/$document

Assessment
  • This one is conceptually stronger than Rules 2 to 4.
  • Redirect parameters are genuinely abused in phishing chains.
  • However, many legitimate services also use redirect parameters such as next=, return=, continue=, and url=.
  • Matching on words like account or secure in the destination is still broad.

Grade
  • A: 5/10
  • B: 6/10
  • C: 7/10

Why
  • Decent heuristic value, especially for obvious redirect-lure links.
  • Still broad enough to catch legitimate SSO and login flows.

Summary table

  • Rule 1 — A: 4/10, B: 4/10, C: 6/10
  • Rule 2 — A: 7/10, B: 8/10, C: 5/10
  • Rule 3 — A: 7/10, B: 8/10, C: 5/10
  • Rule 4 — A: 8/10, B: 9/10, C: 4/10
  • Rule 5 — A: 5/10, B: 6/10, C: 7/10

Best to worst by practical usefulness
  • Rule 5
  • Rule 1
  • Rule 3
  • Rule 2
  • Rule 4

Main technical concerns

1. ^.* makes them too permissive

This is the biggest issue. These rules are effectively saying “match anywhere in the URL,” which weakens precision a lot.

2. Common keywords are poor phishing discriminators

Words like:
  • account
  • update
  • service
  • support
  • billing
  • invoice

appear on many legitimate sites.

3. Several listed TLDs are not inherently suspicious

A TLD like .xyz or .top is often abused, but it is not malicious by itself. The same is even more true for .cloud, .site, .online, and .support. Using TLD alone as a strong warning signal tends to inflate false positives.

4. $document raises the cost of mistakes

A bypassable warning page is safer than a hard block, but it still interrupts browsing and can train users to click through warnings if they see too many benign hits.

What would improve them

Without rewriting the rules for you, the general direction that would improve quality is:

  • Anchor more logic to the hostname instead of “anywhere in URL”
  • Separate hostname checks from path/query checks
  • Require multiple suspicious indicators in the same rule
  • Prefer rarer combinations over generic business words
  • Be careful treating entire TLD groups as suspicious
  • Test against a large benign URL set, not only known phishing samples

Practical recommendation

If the goal is a warning layer with acceptable usability:

  • Keep Rule 1 and Rule 5 as the main candidates
  • Use caution with Rules 2 to 4
  • Expect Rules 3 and 4 in particular to generate many benign warnings

Bottom line

As warning heuristics, these rules are usable only in a limited, experimental sense. Rule 5 is the strongest conceptually, Rule 1 is fairly reasonable, and Rules 2 to 4 are likely too broad for comfortable day-to-day use with $document interstitials.
 
  • Love
  • Thanks
Reactions: LinuxFan58 and Sorrento
Thanks @Bot I will use rule 1 only

Would it help when I change rule 1 to: /^https?:\/\/[^\/]+\.(click|cloud|online|site|zip)\/.*\.(pdf|doc|xls|xlsx|ppt)(\?.*)?$/$document
 

You may also like...