Some trustedListPrefixes don't work and some allow too much

Description

I have a local web server that delivers my custom filter list to uBO. This works fine, except all rules coming from this source are inherently untrusted. I tried both with plain HTTP and self-signed HTTPS. Adding https://127.0.0.1 to trustedListPrefixes does nothing. I'm guessing the issue here is the certificate is self-signed.

Is there a way to have uBO inherently trust filters coming from 127.0.0.1, either via plain HTTP or self-signed HTTPS?

Steps to Reproduce

Have a webserver running on 127.0.0.1, hosting a filter list. Make sure the list contains filters requiring trust.
Add this local filter list to uBO.
Update uBO filters.
Review (eye icon) the local list in uBO.

Expected behavior

All filters are accepted and used.

Actual behavior

Filters requiring trust are marked red with a message "Invalid filter: Filter requires trusted source".

uBO version

1.67.0

Browser name and version

Kiwi Browser 137.0.7337.0

Operating System and version

Android 15

ravilov: I tried both with plain HTTP
ravilov: either via plain HTTP

HTTP is not supported, like already mentioned in documentation:

https://github.com/gorhill/uBlock/wiki/Advanced-settings#trustedListPrefixes :
URLs not starting with https:// or file:/// will be rejected, i.e. http://example.org/ will be ignored.

ravilov: [ENHANCEMENT] Allow trusted filters from 127.0.0.1

It's not a matter of an enhancement, as the requested feature already exists in uBO and works fine for me in: Desktop Firefox, Desktop Chromium, and Mobile Firefox, for example the following works fine for me:

(local list) https://localhost:11443/mylist.txt (trustedListPrefixes: https://localhost:11443/)
(internet list) https://raw.githubusercontent.com/AdguardTeam/FiltersRegistry/master/filters/filter_2_Base/filter.txt (trustedListPrefixes: https://raw.githubusercontent.com/AdguardTeam/)

Also it doesn't seem that the re-compilation issue exists anymore: #3175 as it seems uBO currenlty re-compiles automatically after adding prefixes.

It means it's something wrong on your side or in Kiwi.

To determine whether your issue exists only in Kiwi or not, try on Firefox Mobile, Firefox Desktop, Chrome Desktop.

But anyway, Kiwi is not supported by uBO, like already mentioned in documentation:

https://github.com/gorhill/uBlock/wiki/About-Safari-and-Canary-support#kiwi :
uBlock most likely will work in Kiwi, but since Kiwi is not officially supported by uBlock, some issues might occur, see related issues: https://github.com/uBlockOrigin/uBlock-issues/issues?q=in%3Atitle+kiwi

Thanks for your reply. I'll try with localhost instead of 127.0.0.1 - shouldn't make a difference, but it's worth a shot. I'll also try with some other browsers/versions, as you suggested. I'm glad to know this is at least supposed to work.

HTTP is not supported, like already mentioned in documentation:

Yeah, I know that. I was hoping there could be an exception made specifically just for localhost/127.0.0.1. Dealing with a self-signed certificate is messy and awkward and can be a real PITA, even at best of times when everything works as intended.

All this said, I would think deciding whether a source is trusted would be down to uBO alone, and not depend on a specific browser/version. uBO surely knows where filters came from, and can decide internally if the source is trusted.

UPDATE: I just tried with IronFox (fork of Mozilla Fennec) version 144.0.2, same device, same uBO version, same setup (exported and then imported). The same thing happens - my local source is considered untrusted and any filters within requiring trust are invalid/marked red and not applied.

I am looking at the code and https://127.0.0.1 should definitely work.

Thanks for checking. Is there a reason uBO would consider a source untrusted based on the certificate? I'm now getting suspicious about my local webserver.

ravilov: UPDATE: I just tried with IronFox (fork of Mozilla Fennec) version 144.0.2, same device, same uBO version, same setup (exported and then imported). The same thing happens

In such a case, maybe try a different local web server app and then also maybe a different device if necessary.
Also make sure you don't have any typos in your filter list URL and the prefix URL, they both should begin with same: https://127.0.0.1 (means: not http://), alse check for typos in Advanced settings: once, I accidentally added prefixes to noScriptingCSP script-src http: https: instead to trustedListPrefixes ublock-

ravilov: Is there a reason uBO would consider a source untrusted based on the certificate?

It should not matter, it works for me even with self-signed certificates.

I'll try to find a different local webserver app that has HTTPS support. Unfortunately I don't have any other devices at the moment.

For reference, here's my setup:

Advanced Settings (only modified parts):

filterAuthorMode true
noScriptingCSP script-src http: https:
trustedListPrefixes ublock- user- file: https://127.0.0.1
userResourcesLocation https://127.0.0.1:4096/ublock/resources.js https://raw.githubusercontent.com/uBlock-user/uBO-Scriptlets/master/scriptlets.js

(noScriptingCSP wasn't modified though, this is the default value. Included mostly for completeness.)

Custom filter sources:

https://127.0.0.1:4096/ublock/filters.txt

Errors in filter preview:

"Offending" filters from above:

||amazon.*/gp/aw/d/*$uritransform=/gp\/aw\/d/dp/
||amazon.*/*/dp/*$uritransform=/[^\/]+\/dp/dp/
||target.com/p/*/-/A-*^$uritransform=/\/p\/[^\/]+\//\/p\//

Incidentally, all flagged rules seem to have to do with $uritransform. Could that be the issue? I understand this modifier is "candidate for deprecation" which is kind of unfortunate - what is to replace its functionality?

I would be grateful if someone would try this setup on their end, particularly the offending filters/rules. I know Kiwi is officially not supported, but somehow I don't believe this has to do with any particular browser. Could be wrong though.

I can confirm the issue OP experiences, using just https://127.0.0.1 or https://localhost in trustedListPrefixes doesn't work. But appending a port: https://127.0.0.1:4096/ makes it working.

But the whole issue is broader than a port, here is a full sheet of what works and what not, it looks like some sort of a parsing bug:

Works fine:

https://127.0.0.1:4096/ublock/filters.txt
https://127.0.0.1:4096/ubl
https://127.0.0.1:4096/
https://127.0.0.1:4096
https://localhost:11443/mylist.txt
https://localhost:11443/myl
https://localhost:11443/
https://localhost:11443
https:/
https:
htt

But the following doesn't work:

https://127.0.0.1:409
https://127.0.0.1:
https://127.0.0.1
https://127.0
https://localhost:1144
https://localhost:
https://localhost
https://local
https://

Thank you. I deliberately left out the port, I wanted flexibility to potentially have no port at all as well as an arbitrary port instead of a fixed one. Sinve uBO doesn't support wildcards here, leaving it out was the only solution. I wouldn't think that would cause this issue. I can also confirm adding the port makes the offending rules work.

I'm also glad the issue isn't with $uritransform, I'd hate it if I had to drop it.

On a side note: You mentioned how adding just htt also makes it work. Would that suddenly make http://... (insecure) URLs work as well? 😄

(I still think allowing insecure local URLs (http://127.0.0.1) would be beneficial and wouldn't cause any security issues, btw. Can even be limited to just the IP, doesn't have to accept localhost, if that is deemed better for security - localhost can theoretically be DNS-spoofed.)

If your list URL is https://127.0.0.1:4096/ublock/filters.txt, try using https://127.0.0.1:4096/ as trusted prefix. Internally uBO normalizes URL-looking prefix through new URL(...), so prefix such as https://127.0.0.1 will internally become https://127.0.0.1/, and https://127.0.0.1:409 will become https://127.0.0.1:409/.

Hmm, I see. Yes, I tried adding the full URL complete with port, and that works as expected. It makes sense now, knowing uBO normalizes URLs like that. That would mean those "prefixes" are not really true (string) prefixes though, as they get silently transformed at runtime. Bit unfortunate for me, it means there's no good way I can deploy my "clever" trick of leaving my prefix open-ended (no port or trailing slash) in order to encompass any port, including no port. It also means for example there's no way to declare entire IP subnets as trusted if one should want that, by omitting the last octet (https://192.168.1.).

Possibly something to look into in the future, but for now at least I have a way of getting this to work as intended. I guess this issue can be closed (for now).

It doesn't seem it's about just slash.

ravilov: changed the title to Trusted filters don't work with "https://127.0.0.1", but work with "https://127.0.0.1/" (trailing slash)

How does https://127.0.0.1/ work for you? It doesn't work for me.
Also this one doesn't work either, despite having trailing slash: https://

ravilov: On a side note: You mentioned how adding just htt also makes it work. Would that suddenly make http://... (insecure) URLs work as well? 😄

I've just checked and yes, htt or h allows insecure http://... - not sure whether it's by design (a feature) or a parser bug & security hole (but for you in your case it's desired it seems).

I didn't check so far whether fil or f will allow file:/// scheme URLs, I guess it will, but since file scheme URLs don't seem to work in uBO in both Firefox and Chrome anyway, therefore it's rather a theoretical issue than practical. However I'm not sure about Safari or chrome forks like Edge or Brave.

I've just checked and yes, htt or h allows insecure

Yes, there will be a fix for this in next dev build.

It doesn't seem it's about just slash.

ravilov: changed the title to Trusted filters don't work with "https://127.0.0.1", but work with "https://127.0.0.1/" (trailing slash)

How does https://127.0.0.1/ work for you? It doesn't work for me. Also this one doesn't work either, despite having trailing slash: https://

To be honest, I didn't try specifically https://127.0.0.1/. I changed the title mainly for clarity and simplicity, believing it all largely has to do with the trailing slash. Now I'm not really sure what to think. Maybe this area in uBO does in fact need reviewing?

ravilov: On a side note: You mentioned how adding just htt also makes it work. Would that suddenly make http://... (insecure) URLs work as well? 😄

I've just checked and yes, htt or h allows insecure http://... - not sure whether it's by design (a feature) or a parser bug & security hole (but for you in your case it's desired it seems).

Interesting. I tried the same, and it didn't work for me. If I add htt to trusted prefixes and add a http://... filter source, the filters do get pulled, but ones requiring trust still get blocked.

I didn't check so far whether fil or f will allow file:/// scheme URLs, I guess it will, but since file scheme URLs don't seem to work in uBO in both Firefox and Chrome anyway, therefore it's rather a theoretical issue than practical.

Actually, file:/// URLs do work in Chromium on mobile. You have to enable access to "file" URLs in extension options in settings. Even then, the access (at least on Android) is limited to very specific areas, such as /sdcard/Android/data/<browser-package-name>/*. But in the end, if you stick with these strict rules, it does work. 🙂

I've just checked and yes, htt or h allows insecure

Yes, there will be a fix for this in next dev build.

Can you also allow insecure access for local IP range (http://127.x.x.x)? Slim chance, I know, but worth a shot. 🙂

I won't make more changes for this beyond fixing the undue over-allowing when using h.. tokens, anything else would be a burden beyond what I am willing to undertake.

Fair enough. Thanks.

Fix custom prefixes unduly assigning trust to external lists

ravilov, after my last comment I was hoping you will change the title, because it's very misleading:

the issue is not limited to 127.0.0.1, neither limited to local addresses, it affected any addresses, including public
not to mention what I already said (and you agreed): that https://127.0.0.1/ did not work either

Would be much better to change to something more generic, like:

" Some trustedListPrefixes don't work and some allow too much " or
" trustedListPrefixes parser bugs "

ravilov: Actually, file:/// URLs do work in Chromium.
You have to enable access to "file" URLs in extension options in settings.

Yes, I forgot about this switch.

No problem. Title changed.

Fix custom prefixes unduly assigning trust to external lists

This has been bothering me for quite a while now. Demanding HTTPS for local origins has caused mostly issues for me with no significant benefits. That's why I created this small patch to allow non-secure local origins to be trusted. There really shouldn't be any relevant security implications in this scenario. Plus, the whole thing is centered around uBo's advanced settings, which already assume the user knows what they're doing.

Here's the patch:
gorhill/uBlock@87f4f72

uBo's repo has PR creation disabled, or else I'd create a PR directly.

Hope this gets merged in, it would be a significant quality of life improvement for me. Thanks.

Navigation Menu

Repository navigation

Some `trustedListPrefixes` don't work and some allow too much #3843

Description

Steps to Reproduce

Expected behavior

Actual behavior

uBO version

Browser name and version

Operating System and version

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Some trustedListPrefixes don't work and some allow too much #3843

Description

Description

Steps to Reproduce

Expected behavior

Actual behavior

uBO version

Browser name and version

Operating System and version

Activity

freezer2022 commented on Oct 31, 2025

ravilov commented on Oct 31, 2025

gorhill commented on Oct 31, 2025

ravilov commented on Oct 31, 2025

freezer2022 commented on Oct 31, 2025

ravilov commented on Oct 31, 2025

freezer2022 commented on Nov 1, 2025

ravilov commented on Nov 1, 2025

gorhill commented on Nov 1, 2025

ravilov commented on Nov 1, 2025

freezer2022 commented on Nov 1, 2025

gorhill commented on Nov 1, 2025

ravilov commented on Nov 1, 2025

ravilov commented on Nov 1, 2025

gorhill commented on Nov 1, 2025

ravilov commented on Nov 1, 2025

freezer2022 commented on Nov 2, 2025

ravilov commented on Nov 2, 2025

ravilov commented on Oct 23, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Some `trustedListPrefixes` don't work and some allow too much #3843