New scriptlet type "simulate-event-poc"

[dimisa-RUAdList]

Prerequisites

• [X] I verified that this is not a filter issue (MUST be reported at filter issue tracker)
• [X] This is not a support issue or a question
• [X] I performed a cursory search of the issue tracker to avoid opening a duplicate issue
• [X] The issue is not present after wholly disabling uBlock Origin ("uBO") in the browser
• [X] I checked the documentation to understand that the issue I report is not a normal behavior

I tried to reproduce the issue when...

• [X] uBO is the only extension
• [X] uBO with default lists/settings
• [X] using a new, unmodified browser profile

Description

New scriptlet type "simulate-event-poc"

A specific URL where the issue occurs

consent.google.com

Steps to Reproduce

Scenario description

European ip is required, for example: Netherlands

Requires incognito mode

Step 1 Opening google.com or google.nl

At this step, a modal window pops up asking us to accept cookies. This is solved with: www.google.*##+js(abort-current-script, document.getElementById, CONSENT=YES)

Step 2 Opening from the bar menu in the upper right corner of news.google.com or news.google.nl

This step redirects to consent.google.com or consent.google.nl. And this is what needs to be addressed.

Install Adblock Plus and add there: consent.google.com,consent.google.nl#$#simulate-event-poc click button

This rule will automatically click on the reject cookie button. I propose to create a similar scriptlet, only more advanced in terms of targeting. The rule for Adblock Plus has to be made too general for it to work.

Yes, I know that uBlock Origin doesn't resolve cookie issues by default, but third party filters such as EasyList Cookie or BitBlock can resolve these issues. Also, the new scriptlet can be useful in other cases when you need to make a click, without which the actions are frozen.

Expected behavior

unknow

Actual behavior

unknow

uBlock Origin version

uBlock Origin development build 1.44.1b2

Browser name and version

Google Chrome 104.0.5112.102, Firefox 104.0

Operating System and version

Windows 7, macOS Monterey

[peace2000]

GDPR dialogs are as annoying as ads. Maybe even more. This would be very nice indeed.

[peace2000]

Currently, ABP use it two times in their Anti CV list:

https://github.com/abp-filters/abp-filters-anti-cv/blob/master/english.txt

www.linkedin.com#$#simulate-event-poc click 'xpath(//*[text()="Promoted" or text()="Sponsored" or text()="Dipromosikan" or text()="Propagováno" or text()="Promoveret" or text()="Anzeige" or text()="Promocionado" or text()="促銷內容" or text()="Post sponsorisé" or text()="프로모션" or text()="Post sponsorizzato" or text()="广告" or text()="プロモーション" or text()="Treść promowana" or text()="Patrocinado" or text()="Promovat" or text()="Продвигается" or text()="Marknadsfört" or text()="Nai-promote" or text()="ได้รับการโปรโมท" or text()="Öne çıkarılan içerik" or text()="الترويج"]/ancestor::div[@data-id]//video[@autoplay="autoplay"])' 10 ~~ ! Fallback www.youtube.com,m.youtube.com,music.youtube.com,youtube-nocookie.com#$#simulate-event-poc click button.ytp-ad-skip-button

I have seen people occasionally complaining (not sure if it was here https://github.com/uBlockOrigin/uAssets/issues/7636 or on Reddit) that uBO has slipped through ads on Youtube. That doesn't happen often but few times that has happened to me too. That kind of "fallback" that they have on Anti CV could maybe help to tackle those randomly slipping through ads.

[krystian3w]

Dropped long time ago when jspenguin tried fix cookie walls.

https://github.com/uBlockOrigin/uAssets/pull/2099

[Yuki2718]

Yes, it's a duplicate. Clicker brings whole new class of security risk which can not fully be patched even if limited to privileged list: an attcker who gained partial access to a site and knows uBO auto-clicks an element can exploit this. This is becoming more risky than in past as nowadays even state-sponsored actor tends to combine social-engineering for user's single click. Regarding cookie nug, IMO a scriptlet which should first be introduced will be set-cookie. This solves a lot of currently-unfixable dialog and setting an empty cookie whose name is restricted to be one of pre-defined names is far less risky than auto-click. But gorhill declined this too as is not willing to add something not exist. One reason I love and trust uBO is that he always takes serious consideration of security and privacy before adding a feature. Those who don't and take every nice or convenient feature demanded suffer vulnerability. Prevention is better than cure.

[MasterKia]

Clicker brings whole new class of security risk which can not fully be patched even if limited to privileged list

Those who take every nice or convenient feature demanded suffer vulnerability. Prevention is better than cure.

AdGuard is allowing auto-clicks (e.g. for cookie dialogs) through vanilla JS rules in the trusted lists.

[krystian3w]

I don't Care about Cookies also have click scripts, so hacker can break popular page if addon is bug free.

[dimisa-RUAdList]

Another example: https://mcrypto.club/?go=sskN > https://coinsparty.com/sskN

For Adblock Plus: coinsearns.com,mcrypto.club#$#simulate-event-poc click .wpsafelink-button

[gorhill]

We will need the concept of trusted lists before we think of allowing such capabilities.

[troysjanda]

We will need the concept of trusted lists before we think of allowing such capabilities.

Exactly, this can be dangerous to allow auto clicking, or for that matter auto anything. Just my opinion.

[peace2000]

Imo, actually, if uBO would handle GDPR dialogs, in some cases it could be considered as an act of privacy.

E.g. When you use Google, you'll have to either accept or reject Google's permission to use cookies to show personalized ads.

If uBO would click "Reject all", that would be for the benefit of the user's privacy. It's at least better than "Accept all". Many people might just click "Accept all" without thinking, not knowing that they could also click "Reject all".


[Yuki2718]

Most websites just take none-click (by hiding GDPR notice or not) as acceptance. So it's rather opposite and in fact some people prefer not hiding them because of this. For the security reason we should limit auto-click only on sites no other solution works even if the scriptlet is adopted. Clicking all cookie-notice is security-nightmare.

[peace2000]

@Yuki2718 I agree.

[krystian3w]

Using an external tracker will block EP, rather few people know how to write a good module from scratch or rename a piwik/matomo anymore.

[krystian3w]

If ASAP you can write clickers in Polish Cookie Consent:

• https://chrome.google.com/webstore/detail/polish-cookie-consent/bniijddcmabghibaojbkbnngbedopbno?hl=en
• https://addons.mozilla.org/en-US/addon/polish-cookie-consent/

• Firefox Beta: https://github.com/FiltersHeroes/PolishCookieConsent#vii-fennec-f-droidfirefox-betanightly-android

Possible of clickers:

https://polishannoyancefilters.netlify.app/en/PolishCookieConsent/syntax/

If css selector does not work then was limited to xPath syntax by hawkeye. For now addon do not scope frames to safe performance of website.

[YoshiTabletopGamer]

See this commit going for the beta https://github.com/gorhill/uBlock/commit/7af88b025d What happens to the concerns about security issues? As Yuki (erroneously?) said,

Yes, it's a duplicate. Clicker brings whole new class of security risk which can not fully be patched even if limited to privileged list: an attcker who gained partial access to a site and knows uBO auto-clicks an element can exploit this. This is becoming more risky than in past as nowadays even state-sponsored actor tends to combine social-engineering for user's single click. Regarding cookie nug, IMO a scriptlet which should first be introduced will be set-cookie. This solves a lot of currently-unfixable dialog and setting an empty cookie whose name is restricted to be one of pre-defined names is far less risky than auto-click. But gorhill declined this too as is not willing to add something not exist. One reason I love and trust uBO is that he always takes serious consideration of security and privacy https://github.com/uBlockOrigin/uBlock-issues/issues/46#issuecomment-391303700. Those who don't and take every nice or convenient feature demanded suffer vulnerability. Prevention is better than cure.

[YoshiTabletopGamer]

Do not trust Github's search tool Adguard has had trusted-click-element for more than 10 months, and I found by a search on the filters and it's currently used 8 times. That's less than once a month per filter.

[YoshiTabletopGamer]

A committer to the Adguard Scriptlets repository had worries too

[YoshiTabletopGamer]

gorhill once worried about this

I want to think more about this, basically I want to figure what could go wrong by having filters which can automatically click stuff. These make me uncomfortable. My first thought is that this should at least apply only to visible elements. The question to answer is how could this be misused by either filter list maintainers or site owners.

[peace2000]

gorhill once worried about this

I want to think more about this, basically I want to figure what could go wrong by having filters which can automatically click stuff. These make me uncomfortable. My first thought is that this should at least apply only to visible elements. The question to answer is how could this be misused by either filter list maintainers or site owners.

This comment was made before the concept of "trusted lists". https://github.com/uBlockOrigin/uBlock-issues/issues/2229#issuecomment-1250269437

Clicking scriptlet is only allowed in uBO's own internal lists and in the custom filters of a user.

[iam-py-test]

only allowed in uBO's own internal lists

There is still the risk that uBO's lists could be compromised.

[YoshiTabletopGamer]

Edit: Malicious webpages can use Javascript click() to do these, actually.

We should not forget how using trusted-click-element on a website with some CSS selector can cause problems (site owner case):

1) Website (or website user that can modify CSS) uses CSS selector for something we don't want 2) Filter maintainer adds filter that uses trusted-click-element 3) A malicious website owner or anyone with some partial control to this website can:

- Make a new element with the same CSS selector - This could mean: ~~ - Autoclicking advertisements~~ - Autoclicking the download of some file, trying to trick the user into confirming the download (Firefox has a download confirmation window, unlike Chrome which by default does not) and executing malware

A malicious website owner could do malicious behavior with users of that filter, as if to punish content blocker users in a much more aggressive way

[iam-py-test]

To be fair, website owners can already write scripts to automatically click anything. Still worrying

[YoshiTabletopGamer]

only allowed in uBO's own internal lists

There is still the risk that uBO's lists could be compromised.

With this scriptlet and apparently replace-node-text, we must therefore trust however hosts Ublock Origin lists that they don't secretly add click events to certain users.

Prior to this beta, the trusted scriptlets were these:

trusted-set-constant
trusted-set-cookie
trusted-set-local-storage-item
trusted-replace-fetch-response 
replace-node-text

trusted-click-element seems to have much bigger effect than these

For the remaining safer trusted scriptlets, ideally, I imagine signing (by, for instance, adding signatures of maintainers to the filter files) Ublock Origin's filter lists, such that they could be distributed as text from any host without worrying about their integrity)

[iam-py-test]

trusted-click-element seems to have much bigger effect than these

FYI, replace-node-text is pretty much code execution - trusted-click-element is not the only concern.

I imagine signing (by, for instance, adding signatures of maintainers to the filter files)

Given how much they are updated, I wonder how easy that would be.

[YoshiTabletopGamer]

Do we know of a situation where an attacker can control HTML, but not JavaScript of a webpage?

I currently don't know of a way a website could do something malicious with trusted-click-element This means we have the filterlist maintainer situation

• Commits are logged on Github This apparently means the addition of replace-node-text and trusted-click-element is dangerous if the host (or whoever controls the host) of the trusted filterlists (Github or whatever host the trusted lists come from) makes an attack (solved by signing).

[YoshiTabletopGamer]

If the filterlists were signed, both the (in this case malicious) contributor of a malicious filter and the host would need to collude. This is extremely unlikely if the host is itself trustworthy

[YoshiTabletopGamer]

It really depends on your threat model

[gorhill]

Autoclicking advertisements Autoclicking the download of some file, trying to trick the user into confirming the download (Firefox has a download confirmation window, unlike Chrome which by default does not) and executing malware

This can already be accomplished by malicious parties without them having to wait for a trusted-click-element injection. They also can write code which auto-click whatever they would want to be auto-clicked. I don't see why you think trusted-click-element creates this scenario, any site can already do this with or without a content blocker involved, and with or without trusted-click-element involved, they have access to the same JS capabilities.

[YoshiTabletopGamer]

I have made the retraction of a particular comment more clear. I saw Yuki's comment, and thought this might be worrying, even though we do not have "concrete" examples (yet).

[YoshiTabletopGamer]

I wonder if @Yuki2718 also forgot about the fact malicious webpages can already use HTMLElement.click().

---

In short, if your threat model involves the trusted filterlist host altering the trusted filterlists behind the scenes to use trusted events against you, this may be worrying depending on the context.

There are multiple hosts responsible for Ublock Origin's trusted lists (https://github.com/uBlockOrigin/uBlock-issues/issues/2229#issuecomment-1765018694)

[uBlock-user]

addressed in https://github.com/gorhill/uBlock/commit/7af88b025d

[YoshiTabletopGamer]

I think we would still need to defend its (very low) usage

[Yuki2718]

I wonder if @Yuki2718 also forgot about the fact malicious webpages can already use HTMLElement.click().

This is why I said partial access.

[YoshiTabletopGamer]

I wonder if @Yuki2718 also forgot about the fact malicious webpages can already use HTMLElement.click().

This is why I said partial access.

Well, this is the interesting bit. I could not imagine a situation where partial access of a hacker to a website can make Ublock Origin go against itself

[gorhill]

I found by a search on the filters and it's currently used 8 times

That search tool does not return all instances, I find 130 hit on trusted-click-element just in https://github.com/AdguardTeam/AdguardFilters/blob/af3d12737c86c4a113dd8adafce2310580268d45/AnnoyancesFilter/Cookies/sections/cookies_specific.txt.

[YoshiTabletopGamer]

@Yuki2718, are you in favor of the scriptlet as-it-is? Major websites have been using anti blocker techniques more frequently, and I notice more trusted scriptlets are getting added to Ubo. What do you think? Your comment was the reason I started this conversation. The following is as concrete as I have made it (https://github.com/uBlockOrigin/uBlock-issues/issues/2229#issuecomment-1765125680)

[YoshiTabletopGamer]

Or do you believe the concept of a trusted list is enough?

[gorhill]

@YoshiTabletopGamer I don't understand the point of your comments. Instead of asking others what they believe, you should rather make the case with proof of concepts of why there are issues with the trusted filter options, then we can talk about something concrete that can be addressed. Both AdGuard and ABP have been supporting trusted-click-element (or equivalent for ABP) long before uBO, so I do feel confident about it in uBO given it has been "road-tested", and because it can only be used by trusted uBO volunteers.

[YoshiTabletopGamer]

The only "concrete argument" I have against trusted scriptlets is here:

The current hosts and CDNs of the Ublock Origin filter lists

• Github
• Cloudflare (pages.dev)
• jsdelivr
• statically.io

Can theoretically send malicious filters to users.

With the exception of userResourcesLocation, a supply chain attack used to not be a worry at all when referring to Ublock Origin's filter lists.

Signing filter lists would allow we to be sure, even without looking at them, that the file comes unaltered from the maintainers. Obviously, signing filter lists in a practical manner is something extremely difficult.

[gorhill]

Can theoretically send malicious filters to users

That's not specific to uBO, this can happen to all projects hosted on these CDNs.

[YoshiTabletopGamer]

By malicious, I mean one that can execute arbitrary code*. More specifically, trusted filters being altered by a malicious CDNs to some end users. I believe the most harm a non trusted filter can usually do is deface a website.

[YoshiTabletopGamer]

I'm not asking you to get rid these filters. They are great. I just noticed that in the past, such attacks (when trusted filters did not exist) were not possible at all. That's my only worry about this.

[gwarser]

Firefox simulates click to close cookie dialogs too https://github.com/mozilla/cookie-banner-rules-list#test-rules

[gorhill]

I could add an advanced setting allowing whoever to control the trust level, allowing that all trusted filters to be rejected. Eventually maybe a user interface for that control if we can figure an elegant one.

[YoshiTabletopGamer]

Thank you! Maybe I'm just too paranoid (lol)

[YoshiTabletopGamer]

I also imagine something like logging all trusted filters ever used in the extension. Although that will probably have performance issues.

[krystian3w]

Filtering the current state is unlikely to be difficult, just save yourself a snapshot of the AdGuard lists, uBo lists and one ABP list and filter by any method (grep in console, Notepad++ in GUI on Windows).

What may be more difficult is to efficiently extract outdated versions of scriptlets from their git history (At the same time, I don't see any use in catching an obsolete method).

[YoshiTabletopGamer]

What I mean is, hypothetically someone (a high risk user) who wants to use trusted filters can quickly look at all the trusted filters being used and verify they are not malicious

[YoshiTabletopGamer]

You could grep it, sure, but that would envolve downloading multiple lists and searching each one

[YoshiTabletopGamer]

I imagined something like a button in the interface to show in a new window all trusted filters currently active