Trusted lists in uBO

[ryanbr]

Testing trusted-set-cookie, and then finding out uBO can't use any filters in Easylist Cookie/Annoyances, Can we cover more these lists as "trusted".

easylist/easylist@10770c5

[ryanbr]

It would expand and fix many exception rules used in ELC and Annoyances (that set cookies). Nothing nefarious.

[uBlock-user]

Currently, there are only two sources of TRUSTED filters -

• my Filters

• lists hosted at https://github.com/uBlockOrigin/uAssets

In the future, gorhill has said he may bring support for third-party lists being manually set to TRUSTED by uBO users.

[ryanbr]

I'm talking about trusted sources included in uBlock Origin. Just ELC/FB Annoyances could take adavantage of these. Improving reliablility of blocking, that would be a win for users.

With any lists included with uBO there must be some level of "trust", without it uBO blocking would be limited to its own lists.

I'm not trying to argue here, I'm just trying to change the decsion on what is "trusted".

[MasterKia]

some level of "trust"

How can a list be trusted by uBO when the uBO team has no write access to that list?

[ryanbr]

uBO includes many different (annoyances, regionals..) lists, and only handled by specific list author or authors. Including the list as part of uBO indicates some level of trust. Which is what I'm saying.

[Yuki2718]

Of note, we discussed very this before the first trusted scriptlet was added. This discussion rather sounds minus to us, because it's as if you underestimate the risk of those scriptlet.

[Yuki2718]

I'm just trying to change the decsion on what is "trusted"

The term "trusted" is misleading, we just followed AG's term but it does not mean we trust ourselves, no, we should not. There's no absolute way to prevent misuse of trusted scriptlets, e.g. trusted-click-element can be misused once a rules is made by anyone who has only partial access to the site, which has repeatedly been discussed since jspenguin added the clicker. Untrusted sciptlets can only break sites or just weaken site's security at worst, not at all comparable to the possible consequences of trusted scriptlets. What we can do is to minimize use itself and also access to the scriptlet; i.e. risk control. Having mutual review is expceted to reduce chance of unnecessary use, e.g. cookie set by a site having random value does not mean we need trusted-set-cookie as sometimes 1 works regardless of actual value. This is a matter of security model and possibly the one of responsibility.

[ryanbr]

I'm only talking in the best interests of users here, we have many exception rules that I would like to fix up. I already started to implement fixes https://github.com/easylist/easylist/blob/master/easylist_cookie/easylist_cookie_specific_uBO.txt#L285

I don't want Easylist Cookie to be a 2nd class citizen on uBO because of politics and hypothticals. Asking as a list author, Just allow certain urls/mirrors access to trusted elements to improve ELC/Annoyances further.

@gorhill

[stephenhawk8054]

How is that a requirement? or am I missing something

It's as what @MasterKia has said. These trusted scriptlets are dangerous, and I'm not being hypotheticals, politics or anything. They literally can create any arbitrary new contents of its kind (whether it's about document source, scripts, cookies, local storage...). These scriptlets are what uBO team agreed on when creating/adapting them, therefore the concept of trusting here is completely different to other kinds of filters before. It's not about what lists are currently be default here. If the scriptlets are on a list, at least some team members should have control within it. These are the ones we have discussed and debated for very long time, about its dangerousness and the security-risk on uBO, or how we should craft the filters.

If the above is not possible then we are totally fine. And just for your information, the https://github.com/uBlockOrigin/uAssets/blob/master/filters/annoyances-cookies.txt list could be merged to ELC version in uBO by default (which means when users enable ELC, those fixes with trusted scriptlets are automatically in there). That is the reason why it was created. It's similar to how other lists in uBO extend the fix with uBO's syntaxes. You can create PR for those cookie issues if you want to fix any sites.

[Yuki2718]

I already started to implement fixes

An accomplished fact does not help here. On Slack and here you keep showing a complete indifference about security risk they have and looking only potential utility, which is a red flag and we admonished ourselves for. Remember, (some of) trusted scriptlets can be abused even if the rule is made by the good hand - we can only control the degree of damage and no more potential incident itself. I said almost the same in our internal discussion too.

[Yuki2718]

the best interests of users

How much? In AG Cookie where trusted-set-cookie has been used for months, I only see 20+ rules of it. Generally, websites really needing trusted scriptlets are rare.

[gorhill]

@ryanbr The idea of having trusted- scriplets being valid only in uBO's own filter lists is that any additions/modifications of filters are made under the eyes of all volunteers here, something which is not possible with lists outside this repo.

Other blockers also have such requirements when it comes to security- or privacy-sensitive fitlers, this is not specific to uBO. This won't change.

What can be done though is submit pull requests to the repo here the same way volunteers here submit pull requests to EasyList repo when they want to submit a fix to EasyList-related lists.

---

Also, if not a PR, just a cc to someone here with a suggested fix is also fine to reduce overhead.

[gorhill]

@ryanbr This is how it should look in dev build once it updates with latest assets.dev.json:

[dportvine]

@ryanbr

I'm only talking in the best interests of users here

I just want you to know that. EasyList – Cookies Notices removed from uBOLite.
gorhill/uBlock@4ddfb3f
easylist/easylist@583f377
AdguardTeam/AdguardFilters@fd9f413

[gorhill]

For any trusted-... scriptlets, they need to be committed in uAssets. For example, for cookie-related stuff, this has to go in https://github.com/uBlockOrigin/uAssets/blob/master/filters/annoyances-cookies.txt, so as mentioned above, either a (bulk) PR or "cc @...". It's about having very strict rules regarding all trusted- scriptlets, if we start to make exceptions than it becomes arbitrary from an outsider's point of view.

Beside sticking to strict rules, other reasons to not allow trusted- scriptlets in other repos is to have full control of usage of these, and it's in line with other blockers. Should an issue arise in the wild with a trusted scriptlet, we can act immediately because they are all present in uAssets.

As shown in the screenshot above, the trusted-... scriptlets are virtually part of EasyList from a user's point of view, so EasyList -- Cookie Notices is not relegated to 2nd class citizen, someone selecting EasyList/uBO -- Cookie Notices will benefit from the trusted- scriptlets.

[ryanbr]

RIght. Can we fix up MV3 Easylist Cookie then?

[gorhill]

gorhill/uBlock@6a817b8, change effective in next version of uBOL.

[Yuki2718]

I'm sorry it took longer than expected, but I get so many requests each day, every day.

Actually we discussed this too, this was another context of #18589 (reply in thread)

[ryanbr]

Its a bit late here, I'll organise with the authors the best way to up the commits.