Skip to content
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

Differences in blocking main_frame requests with respect to uBO #1976

Open
eugenioemmolo opened this issue Jun 3, 2021 · 4 comments
Open

Comments

@eugenioemmolo
Copy link
Contributor

I found adblocker library behaving differently with respect to uBO in blocking main_frame requests.

As an example, by providing the library engine with the rule .com/track?$~object, a main_frame request towards https://www.ups.com/track?loc=en_US is blocked, but it actually isn't in uBO.

Doing some research, I found that uBO implements by default what it calls "strict blocking", which is a policy applied to decide whether to block a root document request.

@remusao
Copy link
Collaborator

remusao commented Jun 3, 2021

Hi @eugenioemmolo,

Thanks for opening an issue. Interesting finding, I guess I never encountered this issue because usually I handle these cases in the project making use of the adblocker library (e.g. handling of main_frame requests is done explicitly since blocking of page requires some UX).

I am not 100% sure if this behavior should be baked in the library to be honest. On the one hand it would be nice to have the same behavior as uBlock Origin since we recommend using these filters alongside the adblocker library. On the other hand, this behavior seems to deviates slightly from the explicit meaning of rules (e.g. .com/track?$~object should match any type other than main_frame). I am not a big fan of implicit behaviors such as this one. I think this makes sense to have in the end product/project, but I am not yet convinced that it should be implemented in the low-level library handling the blocking.

What do you think?
Best,
Rémi

@eugenioemmolo
Copy link
Contributor Author

Hi @remusao,

Thank you for your reply.

Within the project exploiting the adblocker library you mentioned, how do you handle these kind of scenarios?

As far as I can see, in order to handle these cases outside the library, it is necessary to startup the adblocker engine in debug mode to be able to apply some post-match logic to the raw rule causing the request block.
In my opinion, this is a reasonably low-level operation and could be worth to be handled directly in the library.

On top of that, by looking around, I also noticed that Brave adblock engine is basically implementing a similar behaviour for what concerns main_frame requests, as you can check out in their repository.

Considering the above, I think it would be great for this adblocker library to provide such uBO-like behaviour in treating main_frame requests.

Best,
Eugenio

@remusao
Copy link
Collaborator

remusao commented Jun 5, 2021

Hi,

That makes sense. I will investigate a bit more about how to best implement this, I am not convinced that the change needs to happen on the parsing time; I was more thinking about some extra check when we match each filter.

I am not sure when I will be able to work on it but hopefully soon. If you have some more insights or ideas please feel free to share!

best,
Rémi

@eugenioemmolo
Copy link
Contributor Author

Hi,

Thank you for your willingness, the effort is highly appreciated.

Regards,
Eugenio

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants