Thinking of considering _My filters_ pane as untrusted by default

[gorhill]

This would mark as invalid all filters requiring a trusted source.

The workaround to make My filters a trusted source would be to enable filterAuthorMode in advanced settings.

The reason is that I worry about users carelessly copy-pasting filters from random sources.

Thoughts?

[Yuki2718]

I agree, too many user are copying & pasting rules from obvously untrustful sources now for yt. OTOH this will make debugging filter issues a bit harder when trusted filters are involved as we have to ask him to enable filterAuthorMode.

[gwarser]

Generic procedural filters still are behind a pref, so why not?

[peace2000]

I think this is reasonable change. If it causes too much confusion, it can be reverted later (though it's probably fine).

Btw, now as we are speaking about trusted sources, can we also get an advanced option that allows to mark specific lists as trusted? (Something similar like userResourcesLocation switch?)

[gorhill]

Gave more thoughts to this, taking into account the other requests re. trusted scriptlets.

This will not be controlled by filterAuthorMode, I will add a new advanced setting, trustedListPrefixes. Possible space-separated values:

• ublock-: trust only uBO lists, exclude everything else, including My filters (default value)
• ublock- user-: trust uBO lists and My filters
• -: trust no list, essentially disabling all filters requiring trust (sysadmins or people who don't trust us may want this)

This way, one can also decide to trust lists maintained elsewhere. For example, for stock AdGuard lists add adguard-. Stock EasyList lists, add easylist-.

The token to use are the ones used in assets.json. You fully trust maintainer of List-KR? Add KOR-1.

The matching is made with startsWith(), hence why ublock- matches all uBO's own filter lists.

So this also opens the door to trust imported lists, for example: add https://raw.githubusercontent.com/brave/adblock-lists/master/brave-lists/ to trust all Brave lists. Add https://filters.adtidy.org/extension/ublock/filters/ to trust all non-stock AdGuard lists. Use the complete URL of a given list to trust only that one list.

[gwarser]

https:// ?

[gorhill]

It's an advanced setting, with many obstacle before reaching it. Are you suggesting in case of URL, we should at least limit to a specific domain name?

---

Ok, will limit for now overbroad directives.

[gwarser]

Yes.

[partingscientist]

Considering what people are sharing are filters they're asked to test by a maintainer (which will be outdated by the time it is shared), and the fact that people tend to share these for self-satisfaction (internet points), what's stopping them from sharing the entire testing step shared by a maintainer in the future?

I think this is a good change and obviously I don't have any suggestion, but I think I ought to make sure the maintainers know the problem from this angle.

[gorhill]

Of course we understand this, and just the same can be said about userResourcesLocation, it's not a new concern. The idea is that there are enough steps with warnings on the way.

[gwarser]

Does this make debugging more difficult when filter maintainer requests user to test some filters? How it's now handled with scriptlets logging available in dev version only?

[gorhill]

trusted "My filters" requiring advanced user

This would require toggling on advanced user mode to test filters, which is an issue if the user has any number of host rules maybe present due to past attempt at using advanced mode.

toggle of allowing trusted filters in "My filters" being automatically turned off after restarting browser

That sort of unpredictable behavior is user-hostile, nobody would want such behavior -- especially people using the setting wilfully and understanding the risks.

Many user will just check the box(es) without second thought.

Well the warning is there (including now permanently in mobile), the setting is disabled by default -- at some point we have to yield responsibility for using risky filters to the users. The checkbox just makes it more convenient.

Another idea:

Under uBlockOrigin, we create a new repo to hold ephemeral "lists", when we want a solution to be tried, we create a new "list" with all the filters we want to be tried, then we provide a link for the user to subscribe to the list. Internally, at launch time uBO will discard lists which URL starts with https://raw.githubusercontent.com/uBlockOrigin/gists/ to ensure proper cleanup of temporary trialed filters -- and at the same time we can git rm a list once we get the needed feedback. Forgot to mention, the lists under https://raw.githubusercontent.com/uBlockOrigin/gists/ would be automatically trusted internally.

[stephenhawk8054]

That sort of unpredictable behavior is user-hostile, nobody would want such behavior -- especially people using the setting wilfully and understanding the risks.

I think it depends on how we interpret that toggle. If we say it like Temporarily allow trusted filters, I don't think it will cause that much confusion. Or if we need even clearer, - until next browser launch at the end.

---

A temporary gist file means that if user restarts the browser to test, they should subscribe to that list again? And the issue is I don't know how long will that gist file be updated upstream if we modify it so we would be not sure which filter is being applied at user's machine, in case we need to test multiple times.

Actually I would choose a simple toggle as in the first suggestion (without automatic turning-off) rather than the gist file approach.

[gorhill]

as the first suggestion

Which one is this?

[stephenhawk8054]

I think it would be simpler if we offer users the choice of trusting the content of "My filters". How about a checkbox at the top of "My filters" pane:

• Do no reject filters requiring trust

Or however better way to state it in a concise manner.

Oh I mean this one: #2895 (reply in thread)

[Yuki2718]

at some point we have to yield responsibility for using risky filters to the users.

Okay, if Do no reject filters requiring trust button requires lower workload than ephemeral lists, that will be fine. There are just many more important issues.

[uBlock-user]

Could you also make it less restrictive by targeting domains instead of sub-domains for adding imported lists as trusted sources ? Example - https://pages.dev/ instead of https://sub-domain.pages.dev/ ?

[gorhill]

At this point I prefer to no longer change too much the matching code. Assuming I would agree for such change, asking that https://sub-domain.pages.dev/ matches https://pages.dev/ is not trivial, it's no longer a case of simply using startsWith(), which currently works well for the majority of cases. Anyways, in which real world case does adding distinct subdomains become an issue?

[uBlock-user]

in which real world case does adding distinct subdomains become an issue?

https://anti-circumvention-filterlist.pages.dev/ and https://ubo-personal-filters.pages.dev/

[gorhill]

That's just two directives, not worth to complicate the code, I rather keep it simple unless a more convincing case is made.

[uBlock-user]

Well the issue is of annoyance of having to add the sub-domains individually, so I don't think metric of convincing will apply here, as some people may not find that route annoying at all, but as you said before - the code changes are not trivial, so I digress.

[gorhill]

I want to add a warning sentence at the top of My filters, following the one already in there, but I am not confident enough about my English being correct. So I am thinking of:

Do not add filters from untrusted sources.

[ghost]

As a native English speaker, I can confirm what you have written is just fine @gorhill.

[iam-py-test]

Could there be a link to a Wiki page describing the issue in more depth next to that?
If so, should that explanation be added to the existing My Filters page or a new one?

[gorhill]

gorhill/uBlock@f1ce3b2

[u-RraaLL]

Considering people such as myself that are using widescreen monitors - I'm not sure the plain text warning at the very end of a single line will capture enough attention.

Perhaps font-weight: bold; would be a good choice here?

Originally I was planning to use color: var(--info3-ink);, but I feared people might complain it's annoying:

Yes, a color might be too distracting in the long run. Plus, it's difficult to choose a color for both themes (brown?).

In any case, some kind of distinction would be better. At the very least font-style: italic; might do the trick.

[MasterKia]

AdGuard lets users explicitly "trust" a third-party filter list using a GUI option, I don't know why it should be behind a hidden setting in uBO.

[Yuki2718]

Actually AG has three trust levels and what corresponds to uBO's trusted list (full trust) is never available to 3p lists.

[MasterKia]

But "My filters" is still trusted by default?

[Yuki2718]

Yes.

[THEtomaso]

So, it's safe to say that setting 'My filters' to untrusted will cause quite a few problems for people unaware of this change, when testing various rules.

[DandelionSprout]

I at least give my approval to the Advanced Settings option. After all, there's more than a few scriptlets I want to (or sometimes have to) learn by trial and error, a fair few of which are considered trusted.

[gwarser]

replace-node-text should have alias with trusted- prefix (and eventually be replaced).

Trusted filters should be marked somehow in editor.

[Yuki2718]

Being alias means no need to do so.

[gorhill]

The goal is to have all trusted scriptlets to be prefixed with trusted-, and rpnt stood out as the only exception. Eventually rpnt and replace-not-text will be deprecated, so yes, I suggest to re-edit them.

[BlazeFTL]

One Minor Suggestions...Trusted- Could Be Shorted To t-rpnt/tr/ts-rpnt...Using Shorter Names Would Be Great

[gorhill]

The idea of using trusted- is to make it obvious that the scriptlets have special status and to make it easy to find in lists. So trusted- it is. There the alias trusted-rpnt if you want.

[krystian3w]

You could do sc / trusted-sc, slsi / trusted-slsi, sssi / trusted-sssi, trusted-ce, sa / trusted-sa.

[Yuki2718]

BTW shouldn't the checkbox sync with trustedListPrefixes?

[gorhill]

I guess unchecking should also remove the now obsolete user- from the setting.

[Yuki2718]

Not the case on my 1.57 on Chrome. It seems if you added user-, the unchecking will never be saved.

[gorhill]

I meant it should as in it currently does not.