-
Notifications
You must be signed in to change notification settings - Fork 435
Re. Strict Blocking - Should we do Domain blocking based on URL part itself? #1128
Comments
I did not see this, I could login seamlessly. I greped |
Was able to reproduce here, did reproduce on first try, second try & afterwards went fine. |
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.
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)... 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..
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 -
not the part of the URLs like
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.. |
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". |
What requests?
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. |
Forgot to mention issue number in commit message of a1da6df. |
I'm talking about filters like :
... 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 |
@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 |
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)
The text was updated successfully, but these errors were encountered: