Serious Discussion uBol Declarative NetRequest rules for protection

[LinuxFan58]

Hi, I thought to share some uBol rules to increase protection. They are grouped by subject.

IMPORTANT: DON'T COPY THEM ALL IN, READ THE RULE EXPLANATION (starts with hashtag #) and decide to add them to your list.

# --------------------------------------------------------------------------------------------------
# GROUP: fraud/scam/phishing related
# these rules have a very low change of website breakage.
# --------------------------------------------------------------------------------------------------
# GROUP: much abused COUNTRY Top Level Domains
# copy the regex rule and ask CHATGPT what countries are listed and decide to include it or not
# --------------------------------------------------------------------------------------------------
# GROUP: much abused GENERIC Top Level Domains (spilt in 3 groups to overcome regex limitation in uBol)
# these rules have a change of website breakage, check whether you use
# --------------------------------------------------------------------------------------------------
# GROUP: non latin character (puny-code) restrictions
# don't apply these when your language contains a lot of non-latin characters

# GROUP fraud/scam/phishing related 
# 1. Double extension + high-risk TLD (zip/mov)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(pdf|doc|xls|xlsx|ppt)\\.(zip|mov)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 2. Account/login/support phishing combined with zip/mov payload
priority: 5
action:
  type: block
condition:
  regexFilter: "(login|secure|account|verify|update|bank|helpdesk|support|service|security).*(\\.zip|\\.mov)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 3. Scam TLDs combined with file-like deception patterns
priority: 5
action:
  type: block
condition:
  regexFilter: "(download|open|view|document|invoice).*(\\.(online|site|top|xyz|click|help|support))(\\b|/)"
  resourceTypes:
    - main_frame
---
# 4. Helpdesk/support impersonation + scam TLDs
priority: 5
action:
  type: block
condition:
  regexFilter: "(helpdesk|support|customer|service|security|billing|account).*(\\.(online|site|top|xyz|click|help|support))(\\b|/)"
  resourceTypes:
    - main_frame
---
# GROUP: much abused COUNTRY Top Level Domains 
# 1. Small islands / offshore / disposable hosting-heavy ccTLDs
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(cc|cx|nf|ms|vg|tc|gd|gg|sh|fm|tv|ws|to|vu|ki|nr|pw)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 2. Post-Soviet / Eastern Europe abuse clusters
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(ru|su|by|kz|kg|uz|tj|tm)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 3. Far east: SAR related countries abuse clusters
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(cn|hk|mo|kp)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 4. Middle East high-abuse observed TLDs
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(ir|iq|sy|ye)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 5. South & Central America high-abuse observed TLDs
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(ag|bo|bz|cu|do|gt|hn|jm|ni|pa|pr|py|sv|tt|uy|ve)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 6. South East Asia high-abuse observed TLDs
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(af|bd|bt|la|lk|mm|mn|np|pk|ph)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 7. African ccTLDs (abuse-clustered)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(bj|bw|cf|cm|cv|ga|gh|ke|lr|mg|ml|mw|mz|na|ne|rw|sn|sl|so|ss|st|sz|td|tg|tz|ug|zm|zw)(\\b|/)"
  resourceTypes:
    - main_frame
---
# GROUP: much abused GENERIC Top Level Domains
# 1 Scam / high-abuse TLDs (group A split because regex filter maximum)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(zip|mov|top|xyz|click|loan|work|support|help)(\\b|/)"
---
# 2 Scam / high-abuse TLDs (group B split because regex filter maximum)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(online|site|live|store|fun|today|icu|info)(\\b|/)"
---
# 3 Scam / high-abuse TLDs ((group C split because regex filter maximum)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(biz|pw|pro|monster|rest|host|cfd|cam|lol|uno)(\\b|/)"
---
# don't apply these when your language contains a lot of non-latin characters
# 1 Block everything from TLD containing a punycode (xn--)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.[^/]*xn--[^/]*(\\b|/)"
---
# 2 Block Punycode domains (non-ASCII domains encoded in Punycode)
priority: 5
action:
  type: block
condition:
  regexFilter: "xn--"
  resourceTypes:
    - main_frame
---

 

[Bot]

Hi, I thought to share some uBol rules to increase protection. They are grouped by subject.

IMPORTANT: DON'T COPY THEM ALL IN, READ THE RULE EXPLANATION (starts with hashtag #) and decide to add them to your list.

# --------------------------------------------------------------------------------------------------
# GROUP: fraud/scam/phishing related
# these rules have a very low change of website breakage.
---
# --------------------------------------------------------------------------------------------------
# GROUP: much abused GENERIC Top Level Domains (spilt in 3 groups to overcome regex limitation in uBol)
# these rules have a low change of website breakage.

# --------------------------------------------------------------------------------------------------
# GROUP: much abused COUNTRY Top Level Domains
# these rules have low chance of chance when YOU ARE NOT LIVING IN THAT REGION!
# copy the regex rule and ask CHATGPT what countries are listed and decide to include it or not
# --------------------------------------------------------------------------------------------------
# GROUP: non latin character (puny-code) restrictions
# have a medium chance of breaking websites
# don't apply these when your language contains a lot of non-latin characters

# 1. Double extension + high-risk TLD (zip/mov)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(pdf|doc|xls|xlsx|ppt)\\.(zip|mov)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 2. Account/login/support phishing combined with zip/mov payload
priority: 5
action:
  type: block
condition:
  regexFilter: "(login|secure|account|verify|update|bank|helpdesk|support|service|security).*(\\.zip|\\.mov)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 3. Scam TLDs combined with file-like deception patterns
priority: 5
action:
  type: block
condition:
  regexFilter: "(download|open|view|document|invoice).*(\\.(online|site|top|xyz|click|help|support))(\\b|/)"
  resourceTypes:
    - main_frame
---
# 4. Helpdesk/support impersonation + scam TLDs
priority: 5
action:
  type: block
condition:
  regexFilter: "(helpdesk|support|customer|service|security|billing|account).*(\\.(online|site|top|xyz|click|help|support))(\\b|/)"
  resourceTypes:
    - main_frame
---
# 1. Small islands / offshore / disposable hosting-heavy ccTLDs
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(cc|cx|nf|ms|vg|tc|gd|gg|ai|io|sh|fm|tv|ws|to|vu|ki|nr|pw)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 2. Post-Soviet / Eastern Europe abuse clusters
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(ru|su|by|kz|kg|uz|tj|tm)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 3. Far east: SAR related countries abuse clusters
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(cn|hk|mo|kp)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 4. Middle East high-abuse observed TLDs
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(ir|iq|sy|ye)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 5. South & Central America high-abuse observed TLDs
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(ag|bo|bz|cu|do|gt|hn|jm|ni|pa|pr|py|sv|tt|uy|ve)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 6. South East Asia high-abuse observed TLDs
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(af|bd|bt|la|lk|mm|mn|np|pk|ph)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 7. African ccTLDs (abuse-clustered)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(bj|bw|cf|cm|cv|ga|gh|ke|lr|mg|ml|mw|mz|na|ne|rw|sn|sl|so|ss|st|sz|td|tg|tz|ug|zm|zw)(\\b|/)"
  resourceTypes:
    - main_frame
---
# 1 Scam / high-abuse TLDs (group A split because regex filter maximum)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(zip|mov|top|xyz|click|loan|work|support|help)(\\b|/)"
---
# 2 Scam / high-abuse TLDs (group B split because regex filter maximum)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(online|site|live|store|fun|today|icu|info)(\\b|/)"
---
# 3 Scam / high-abuse TLDs ((group C split because regex filter maximum)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.(biz|pw|pro|monster|rest|host|cfd|cam|lol|uno)(\\b|/)"
---
# 1 Block everything from TLD containing a punycode (xn--)
priority: 5
action:
  type: block
condition:
  regexFilter: "\\.[^/]*xn--[^/]*(\\b|/)"
---
# 2 Block Punycode domains (non-ASCII domains encoded in Punycode)
priority: 5
action:
  type: block
condition:
  regexFilter: "xn--"
  resourceTypes:
    - main_frame
---

Thanks for sharing these. As an AI, I think the general idea is reasonable, but some of these rules are much safer than others.

Short version

• The phishing/deception pattern rules are the most defensible.
• The broad TLD blocking rules can reduce exposure, but they also raise the risk of false positives and unnecessary site breakage.
• The country-code TLD blocks are the most likely to cause collateral damage if used too broadly.
• The punycode rules can help against homograph-style abuse, but they will also block legitimate internationalized domains.

What looks relatively safe

These are the lowest-risk entries in your list:

• Double extension + risky TLD:
  

  \\.(pdf|doc|xls|xlsx|ppt)\\.(zip|mov)(\\b|/)

  This targets a common deception pattern and is fairly specific.
• Login/account/support terms combined with .zip or .mov:
  

  (login|secure|account|verify|update|bank|helpdesk|support|service|security).*(\\.zip|\\.mov)(\\b|/)

  Also fairly targeted, though it could still catch some legitimate edge cases.
• Scam-themed keywords combined with certain generic TLDs:
  

  (download|open|view|document|invoice).*(\\.(online|site|top|xyz|click|help|support))(\\b|/)

  Reasonable as a higher-protection rule, but not “zero breakage.”
• Helpdesk/support impersonation + scam TLDs:
  

  (helpdesk|support|customer|service|security|billing|account).*(\\.(online|site|top|xyz|click|help|support))(\\b|/)

  Again, targeted enough to be useful for users who want stricter filtering.

What is more risky

The generic TLD blocks are much broader:

• \\.(zip|mov|top|xyz|click|loan|work|support|help)(\\b|/)

• \\.(online|site|live|store|fun|today|icu|info)(\\b|/)

• \\.(biz|pw|pro|monster|rest|host|cfd|cam|lol|uno)(\\b|/)

These can absolutely block malicious or low-quality domains, but they can also block legitimate sites. In particular:

• .info, .store, .pro, .host, and .io/.ai from your country lists are used by many legitimate businesses
• .zip and .mov are high-risk because they can be visually deceptive, so blocking those is easier to justify
• Broad TLD-only blocking is a coarse filter, not a precise anti-phishing control

So I would treat these as optional hardening rules, not general recommendations for everyone.

Country-code TLD blocks

This is where I would be most careful.

Blocking entire ccTLD groups based on abuse trends is a blunt approach. It may be acceptable for a user who knows they never need sites from those regions, but it should not be presented as generally safe without qualification.

A few examples from your regex groups:

• Small islands / offshore / hosting-heavy ccTLDs: cc, cx, nf, ms, vg, tc, gd, gg, ai, io, sh, fm, tv, ws, to, vu, ki, nr, pw
• Post-Soviet / Eastern Europe: ru, su, by, kz, kg, uz, tj, tm
• Far East / SAR-related: cn, hk, mo, kp
• Middle East: ir, iq, sy, ye
• South & Central America: ag, bo, bz, cu, do, gt, hn, jm, ni, pa, pr, py, sv, tt, uy, ve
• South / Southeast Asia group in your rule: af, bd, bt, la, lk, mm, mn, np, pk, ph
• Africa group: bj, bw, cf, cm, cv, ga, gh, ke, lr, mg, ml, mw, mz, na, ne, rw, sn, sl, so, ss, st, sz, td, tg, tz, ug, zm, zw

Important note

Some of these are widely used for legitimate services outside their original country assignment. For example:

• .io is heavily used by tech companies
• .ai is heavily used by AI-related businesses
• .tv and .fm are commonly used for media/audio branding
• .gg is used beyond Guernsey
• .ws, .cc, and .pw have mixed use and can include legitimate domains

So these are not “safe by default” blocks. They are regional or policy-based exclusions.

Punycode rules

These two are effective but blunt:

• \\.[^/]*xn--[^/]*(\\b|/)

• xn--

They can help against IDN homograph abuse, but they also block legitimate internationalized domain names. That means users of many non-English or non-Latin websites may see breakage.

Your warning here is appropriate. I would just make it stronger: this should be considered an optional restriction, not a default recommendation.

One technical point

Some rules include resourceTypes: main_frame, while others do not.

That matters because:

• Rules limited to main_frame mainly affect top-level page loads
• Rules without that limit may apply more broadly depending on how uBOL interprets them
• If the goal is to prevent navigation to suspicious domains, keeping the scope to main_frame is usually the cleaner and less disruptive choice

Consistency here would help reduce unintended blocking.

Practical recommendation

If someone wants stronger protection with lower breakage, I would prioritize in this order:

1. Deception-pattern rules using file-like names and phishing keywords
2. Blocking .zip and .mov specifically
3. Optional scam-TLD combinations when paired with suspicious keywords
4. Only then consider broad TLD blocks
5. Use ccTLD blocks only if the user is certain they do not need those regions
6. Use punycode blocking only if they accept the tradeoff of blocking legitimate IDNs

Bottom line

Your list is useful as a custom hardening set, but not all groups are equally safe. The targeted phishing/deception rules are the strongest part. The broad TLD, ccTLD, and punycode blocks are much more aggressive and should be described as optional filters with real false-positive potential.

Sources

• uBlock Origin works best on Firefox
• Static filter syntax
• Internationalized domain name - Wikipedia
• Punycode - Wikipedia

 

[LinuxFan58]

@Bot thanks for the explanation.

I removed IO and AI from small islands (my bad)

 

[LinuxFan58]

For references:

In my work Chrome profile (in which it is very important that websites DON'T BREAK), I have enabled

GROUP: fraud/scam/phishing related
all 4 rules, as Bot explained a very low chance of breaking stuff)

GROUP: much abused COUNTRY Top Level Domains
1. Small islands / offshore / disposable hosting-heavy ccTLDs (removed IO an AI)
2. Post-Soviet / Eastern Europe abuse clusters
3. Far east: SAR related countries abuse clusters
4. Middle East high-abuse observed TLDs

GROUP: non latin character (puny-code) restrictions
1. Block everything from TLD containing a punycode (xn--)
\\.xn--[^./]+(\\b|/)

@Bot could you assess the website breakage risk for someone living in Western Europe or North America using the above rules.

I always blocked non-latin character TLD's in NextDNS and Cloudflare Zero Trust and never encountered a problem, so I am curious what Bot's take on above filter rules are. I realize blocking TLD's is more like a sledge hammer approach than a pincet selection, but I got those rules adviced by my former neighbour who was an IT-security and compliance officer. I am aware that he had some obvious GEO-political enforced motives in the DNS rules he adviced, but I am not aware of website breakage that is why I apply them in my work profile. The other rules are also applied in my surfing profile (which is used only for browsing, not banking or buying).

Since @Bot is on lunch break, this is what ChatGPT reports

 

[LinuxFan58]

It is very easy to add DeclarativeNetRequest rules for uBlockoriginLite by asking ChatGPT to construct one for you (just make sure you give Chat an example).

This rule blocks IP numerical IPv4 addresses (I have disabled IPv6 in the router because my previous VPN did not facilitate IPv6). Than ask Claude or Leo to check or correct them.

priority: 5
action:
  type: block
condition:
  regexFilter: "https?://[0-9]{1,3}(\\.[0-9]{1,3}){3}(:[0-9]+)?/"

 

[Sampei.Nihira]

It can be concluded that forum users who use uBoL are not interested in enhancing this extension to prevent potential threats while browsing.