modify-attr?

[DUOLabs333]

I don't know if this is possible, but would it be possible to add the ability to modify the attribute of an element, instead of simply removing it? For example :modify-attr(class,"/hello (.*)/", "hello world") will take the class attribute of the element and replace all values like hello it's me to hello world (I don't know whether this should be done once, or for all matches)

[peace2000]

Doing something like that is possible, but it's not supported by uBO. Do you have use cases where that would be useful?

[DUOLabs333]

Yes, sometimes anti-adblock/paywalls is implemented by blurring the article text. To remove it, I only need to remove the blurred part of the class attribute --- trying remove-attr(class) will ruin the formatting of the page.

[DUOLabs333]

And yeah, currently, I use Tampermonkey, but because this is a common occurrence, I have to copy the code for each new script (adjusting values when needed). Having it either builtin to uBO, or some provided scriptlet would be great.

[gorhill]

The solution for this is usually to override the blurring with CSS declaration such as ...##*:style(filter: none !important)

[DUOLabs333]

This works! This was the main usecase --- maybe for instances where some things are meant to be blurred but other things are not (though for that case, I'm pretty sure you could be selective with it, like ##div[classA]:style(...), right?)

[ghost]

@gorhill

I will post it here since it is related, but for the case of the OP since that should be done through :style() as you told the OP, but for 'modifying an attribute', it could be accomplish 'easily' by a trusted-set-attr, I know you followed Adguard for the set-attr, but why is there no a trusted-set-attr, now that trusted lists have a good foundation?

Few uses for this could be how a link opens if _blank, _self, etc etc, so setting that attribute would be important,

Another most useful usage is about the Input HTML element and how anything you 'input' gets added to the autocomplete.
That behavior can be stopped by having the autocomplete="off" and in some instances it can be achieved if the input has autocorrect="off", you the normal set-attr can do it, just copy the value from it and done, but many input don't have more than the ID and the name for example, so no way to copy it from anywhere.

My solution is to take the set-attr and remove the restriction for the value and call it it 'trusted-set-attr', and done, but it would be nice to have it officially and not just for me, in case I need to help someone, or so Brave adblocker can have it without resources having to be 'hacked', especially on mobile where only rooted phones have access to the resources file.

[stephenhawk8054]

set-attr is suggested to deal with the anti-adblock in some sites without the need of excessive whitelisting for ads and trackers requests, and those sites constantly fought towards anti-adblock too.

Are there any real world cases related to ads and trackers which cannot be solved by other current methods and need trusted-set-attr?

[gorhill]

why is there no a trusted-set-attr

We don't add scriplets because people ask us to do so, we add scriptlets when we determine they would solve filtering issues on many websites, not solvable otherwise. Any code we add to uBO is future technical debt, code which needs to be maintained and tested, so it has to be fully justified, and only actual, real world cases justify adding new scriptlets.

[ghost]

Thanks for the answer.

But since there is already set-attr scriptlet, this is technically not a 'new scriptlet', so that's why my question, the reason why an existing scriptlet that got restricted by Adguard for lame 'security reasons' can't have a trusted version = remove only the validValues logic, like the other 'security risk' scriptlets like Set-Cookie?

My quick fix to use set-attr as trusted was to use const validValues = value; because it is the easiest way to maintain it, rather than remove the whole validValues logic.

But problem is there are no real case scenario for set-attr to even exist in the first place, and there is currently only one filter that uses it in 2022 list, but does that mean it is useless? not really, but what was the reasoning to add it? and therefore what's wrong with a trusted version that removes the 'validValues' if the scriptlet already exists?

You know adblocking has evolved to be more than just for adblocking, and set attributes is not used for ads and trackers, but rather, to fix BS web developers aren't doing or are doing, through attributes that can't be modified or overridden by :style()

About what web developers don't do, well, last time I helped someone to find a filter to workaround about searxng saving autocomplete, because for some reason it didn't have the autocomplete="off" for the searches (now they seem to have it), and then I found a workaround about it by using autocorrect attribute, but not all input allow that, and not all inputs should be set to save, especially if something like a search engine where you are searching ANYTHING, and not just that but it gets synchronized by the browser synchronization system, so input elements become a privacy nightmare for the way they work, where only the 'name' needs to match for they to display in other websites, and therefore the only way to stop that is by setting autocomplete to off, and if there is no a off attribute to copy from, then, there is no workaround about it, than manually open Devtools and temporary add it, something that can't be done in mobile.
So, instead of creating more 'validValues' for the set-attr, which I am sure "Adguard" will appear in the sentence, like happened few days ago in an issue for Trusted-set-cookie that have limited values and it doesn't allow -06 because Adguard says 'stay with our limited list' for compatibility reasons, then the only solution is a trusted-set-attr, to fix any subsequent scenario where only setting an attribute will solve an issue, especially if they are related to privacy, and only because Searxng already includes the autocomplete off, doesn't mean others will do the same.

Anyway, that's all I was asking, what the reason for an existing restricted scriptlet not to have the trusted version for people's freedom. But I guess only if Adguard adds it it will be the reason to add it in uBlock... I mean, that's the only thing I can ssume now, when set-attr was added in the first place with no real world case scenario at all, and only 1 filter use it across 160K+ filters.

Have a good day.

[stephenhawk8054]

set-attr was added in the first place with no real world case scenario at all

set-attr was added due to the sites rocketnews24.com,soranews24.com,youpouch.com constantly hid the images if using blockers.

https://github.com/uBlockOrigin/uAssets/issues?q=is%3Aissue+soranews24
https://github.com/uBlockOrigin/uAssets/issues?q=is%3Aissue+rocketnews24

It rampaged from using other safe filters to excessively whitelisting many ads and trackers requests in order to make the images appear for the users: #2347 . Whenever the volunteers whitelisted some requests, they adjusted it so we had to whitelist more other requests.

And it actually did not follow exactly what Adguard scriptlet did, we extended it to exactly solve the issues in these websites: #2347 (comment)

We have other scriptlets that were pulled off due to the ads/privacy issues occurring to the websites without the needs of referencing Adguard's scriptlets (rpnt, spoof-css, xml-prune, m3u-prune...), and that has always been the cases for uBO development: ads/privacy issues occur -> could not solve with current methods -> add new methods to counter.

For the scriptlets that both uBO and Adguard use, it's always better to have common standards for compatibilities, since uBO also compiles with many Adguard lists. If you want to extend the feature, always give exact issues with exact steps to reproduce, and we will check if the issue is too far off uAssets goals or not.