-
Notifications
You must be signed in to change notification settings - Fork 82
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New scriptlet type "simulate-event-poc" #2229
Comments
GDPR dialogs are as annoying as ads. Maybe even more. This would be very nice indeed. |
Currently, ABP use it two times in their Anti CV list: https://github.com/abp-filters/abp-filters-anti-cv/blob/master/english.txt
I have seen people occasionally complaining (not sure if it was here uBlockOrigin/uAssets#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. |
Dropped long time ago when jspenguin tried fix cookie walls. |
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. |
AdGuard is allowing auto-clicks (e.g. for cookie dialogs) through vanilla JS rules in the trusted lists. |
I don't Care about Cookies also have click scripts, so hacker can break popular page if addon is bug free. |
Another example: For Adblock Plus: |
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. |
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". |
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. |
@Yuki2718 I agree. |
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. |
If ASAP you can write clickers in Polish Cookie Consent:
Possible of clickers: https://polishannoyancefilters.netlify.app/en/PolishCookieConsent/syntax/ If css selector does not work then was limited to |
See this commit going for the beta gorhill/uBlock@7af88b025d
|
Do not trust Github's search tool |
gorhill once worried about this
|
This comment was made before the concept of "trusted lists". #2229 (comment) Clicking scriptlet is only allowed in uBO's own internal lists and in the custom filters of a user. |
There is still the risk that uBO's lists could be compromised. |
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 |
It really depends on your threat model |
This can already be accomplished by malicious parties without them having to wait for a |
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). |
I wonder if @Yuki2718 also forgot about the fact malicious webpages can already use 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 (#2229 (comment)) |
addressed in gorhill/uBlock@7af88b025d |
|
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 |
That search tool does not return all instances, I find 130 hit on |
@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 (#2229 (comment)) |
Or do you believe the concept of a trusted list is enough? |
@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 |
The only "concrete argument" I have against trusted scriptlets is here: The current hosts and CDNs of the Ublock Origin filter lists
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. |
That's not specific to uBO, this can happen to all projects hosted on these CDNs. |
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. |
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. |
Firefox simulates click to close cookie dialogs too https://github.com/mozilla/cookie-banner-rules-list#test-rules |
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. |
Thank you! Maybe I'm just too paranoid (lol) |
I also imagine something like logging all trusted filters ever used in the extension. Although that will probably have performance issues. |
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). |
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 |
You could grep it, sure, but that would envolve downloading multiple lists and searching each one |
I imagined something like a button in the interface to show in a new window all trusted filters currently active |
This may help https://github.com/gwarser/filter-lists-tools/blob/master/download-assets.json-all.sh |
Prerequisites
I tried to reproduce the issue when...
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
orgoogle.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
ornews.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
The text was updated successfully, but these errors were encountered: