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

Re. Strict Blocking - Should we do Domain blocking based on URL part itself? #1128

Closed
harshanvn opened this issue Mar 30, 2015 · 26 comments

Comments

@harshanvn
Copy link

commented Mar 30, 2015

Steps to Reproduce:
  1. Login gmail.
  2. You will see the below error -

ublock incorrect block

Not sure if it is necessary to block the whole domain based on the part filter (i.e., /Checkcookie? ...)

uBlock v0.9.2.4-dev2

Filter Lists: Ads (2, 5) Privacy (All) Malware Domains (1, 4) Social (1) Multipurpose (All)

@harshanvn harshanvn changed the title Re. Strict Blocking - Should do Domain blocking based on URL part itself? Re. Strict Blocking - Should we do Domain blocking based on URL part itself? Mar 30, 2015

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

You will see the below error

I did not see this, I could login seamlessly. I greped /checkcookie? in all filter lists and I could not find any matching filter.

@Betsy25

This comment has been minimized.

Copy link

commented Mar 30, 2015

Was able to reproduce here, did reproduce on first try, second try & afterwards went fine.
FF nightly 39, Win7, latest commit with default filters.

@harshanvn

This comment has been minimized.

Copy link
Author

commented Mar 30, 2015

Yes. Only able to reproduce it for the first time. Not happening from 2nd time. I did make sure, i did not add any exclusions..

Its in Fanboy ultimate...

ublock checkcookie filter

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

Ok, it's Fanboy's Annoyance list, not a default list. Forgot grep is case-sensitive by default.

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

Even with Fanboy's Annoyance, I can't reproduce. You guys need to give me more precise steps to reproduce.

@Betsy25

This comment has been minimized.

Copy link

commented Mar 30, 2015

I think it's merely a server side decision when this specific action takes place, perhaps If the user had been logged in long enough during a previous session. That's probably the reason why it cannot be reproduced rapidly after it's first occurence.

@harshanvn

This comment has been minimized.

Copy link
Author

commented Mar 30, 2015

There is no special clauses in reproducing it.

  1. type gmail.com
  2. login it to it. And you see this error.

However, this seems to be occurring only once. After that it works fine, no more blocking. I did it for 2 machines and same behavior...

Let me try to reset the addon and retry..

@Betsy25 I am browsing thru inprivate mode. Even then after repoening browser to login for second time, it works fine.

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

I can't start to create exceptions to the rule, or I might as well just scrap the whole thing, as it become somewhat arbitrary.

What I can do however is to provide a better way to deal with this kind of situation by adding the choice of disabling strict blocking permanently for the site and proceed at once:

Disable strict blocking for the site (at your own risk)...
temporarily and proceed or permanently and proceed.

So clicking the second button would get rid of the issue forever.

@harshanvn

This comment has been minimized.

Copy link
Author

commented Mar 30, 2015

Resetting the addon (After reset, only change in the config setting is i enabled fanboy ultimate), didn't help it. :(.

So, have looked for another test case..

  1. Open the following link - http://wplu.vr-zone.net/assets/images/socialicons/pinterest.png
  2. You will see the fetching of the resource blocked because of the filter /socialicons/

May be to reproduce the original issue on gmail.com, one might need to create a new profile and install the addon and try it. However i am not at liberty to do it at work place now..

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

Actually I just reproduced it inadvertently, not by going to gmail, but by going to the Chrome store -- with Fanboy's Annoyance enabled.

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

At least it is explained why the page was blocked, and a course of action is suggested -- which course of action I will improve as said above.

But to me, it feels pretty good to know uBlock has my back when navigating somewhere, and if it's obviously because of a false positive, then it's not really a big deal if the only thing I need to do is to click one button to get rid of the false positive forever for a given site.

@harshanvn

This comment has been minimized.

Copy link
Author

commented Mar 30, 2015

Yes, true the reason was given when it was blocked.

Why i brought this to your attention is, my feeling is that domain blocking functionality may need to be based on the filters actually carrying domain name, like -

||baddomain.com
or an ip address
1.1.1.1

not the part of the URLs like

/checkcookie?
/socialicons/

Otherwise there could be many FPs making the really good useful feature, a little annoyance, i think (how ever with this feature, i did have one FP only after 2 days of browsing)

fyi, there seems to be another reported incident at wilders..
http://www.wilderssecurity.com/threads/ublock-a-lean-and-fast-blocker.365273/page-31#post-2475137

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

How about we road-test this first before we decide to create exceptions (which is not that obvious):

d

@harshanvn

This comment has been minimized.

Copy link
Author

commented Mar 30, 2015

Sure gorhill. We have to yet it thoroughly and see if we have to create exceptions...

@Betsy25

This comment has been minimized.

Copy link

commented Mar 30, 2015

As mentioned in the widerssecurity, wouldn't it be better to have it the other way around, disabled by default, enableable on a site basis ?

Before the implementation of this, those requests were silently blocked yet everything worked as expected, now the whole seems rather "broken".

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

Before the implementation of this, those requests were silently blocked

What requests?

adobe-plugin.tk is a site listed in one of the malware domain lists.

ABP won't prevent you from loading a web page at that site. uBlock will not load pages from that site from now on, without your consent.

The point of the feature is to not load something in the browser before it's too late -- which would be the case if the setting was reversed.

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

Forgot to mention issue number in commit message of a1da6df.

@Betsy25

This comment has been minimized.

Copy link

commented Mar 30, 2015

What requests?

I'm talking about filters like :

/checkcookie?
/socialicons/

... in filter lists, am I right that these were, before strict blocking got implemented, all simply ignored ?

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

Strict blocking is explained here.

@Betsy25

This comment has been minimized.

Copy link

commented Mar 30, 2015

Thanks, I red that, I'm not talking about domain blocking, I never expected a non-domain filter like /checkcookie? now suddenly block people from logging into their gmail ?

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

Never mind, bad example.

@gorhill

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

Alright, I think I am getting convinced that this is the proper way to go.

@Mikey1993

This comment has been minimized.

Copy link
Contributor

commented Mar 30, 2015

I have updated the wiki about strict blocking based on the updated image. (https://github.com/gorhill/uBlock/wiki/Quick-guide:-popup-user-interface)

@gorhill It's time to make a clean image for the wiki?

@gorhill gorhill closed this in 5b34efc Mar 30, 2015

@gitarra

This comment has been minimized.

Copy link

commented Apr 4, 2015

@chrisaljoudi @AlexVallat So if I understood correctly currently the strict blocking should only block site loads based on the domain? If so, strict blocking probably shouldnt be enabled for .org/ad- here http://download.gna.org/ad-free-libre/?

capture

@chrisaljoudi

This comment has been minimized.

Copy link
Contributor

commented Apr 5, 2015

@gitarra basically, yes.

More precisely, the requirement is that the match starts within the domain name (before the 'path' part of the URL).

In the case of .org/ad- and the URL http://download.gna.org/ad-free-libre/, the match starts with .org, which is part of the domain name.

@gitarra

This comment has been minimized.

Copy link

commented Apr 5, 2015

Ah, okay. I was wondering whether its intended as the only match in the domain space is the TLD.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.