Loading…
Re. Strict Blocking - Should we do Domain blocking based on URL part itself? #1128
6 participants
harshanvn
changed the title from Re. Strict Blocking - Should do Domain blocking based on URL part itself? to Re. Strict Blocking - Should we do Domain blocking based on URL part itself?
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.
Was able to reproduce here, did reproduce on first try, second try & afterwards went fine.
FF nightly 39, Win7, latest commit with default filters.
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...
Ok, it's Fanboy's Annoyance list, not a default list. Forgot grep is case-sensitive by default.
Even with Fanboy's Annoyance, I can't reproduce. You guys need to give me more precise steps to reproduce.
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.
There is no special clauses in reproducing it.
- type gmail.com
- 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.
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.
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..
- Open the following link - http://wplu.vr-zone.net/assets/images/socialicons/pinterest.png
- 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..
Actually I just reproduced it inadvertently, not by going to gmail, but by going to the Chrome store -- with Fanboy's Annoyance enabled.
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.
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
How about we road-test this first before we decide to create exceptions (which is not that obvious):
Sure gorhill. We have to yet it thoroughly and see if we have to create exceptions...
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".
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.
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 ?
Strict blocking is explained here.
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 ?
Never mind, bad example.
Alright, I think I am getting convinced that this is the proper way to go.
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?
@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/?
@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.
Ah, okay. I was wondering whether its intended as the only match in the domain space is the TLD.
Steps to Reproduce:
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)