Skip to content
This repository has been archived by the owner on Sep 9, 2022. It is now read-only.

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

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

Comments

@harshanvn
Copy link

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
Copy link
Contributor

gorhill 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
Copy link

Betsy25 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
Copy link
Author

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
Copy link
Contributor

gorhill commented Mar 30, 2015

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

@gorhill
Copy link
Contributor

gorhill 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
Copy link

Betsy25 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
Copy link
Author

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
Copy link
Contributor

gorhill 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
Copy link
Author

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
Copy link
Contributor

gorhill 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
Copy link
Contributor

gorhill 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
Copy link
Author

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
Copy link
Contributor

gorhill commented Mar 30, 2015

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

d

@harshanvn
Copy link
Author

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

@Betsy25
Copy link

Betsy25 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
Copy link
Contributor

gorhill 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
Copy link
Contributor

gorhill commented Mar 30, 2015

Forgot to mention issue number in commit message of a1da6df.

@Betsy25
Copy link

Betsy25 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
Copy link
Contributor

gorhill commented Mar 30, 2015

Strict blocking is explained here.

@Betsy25
Copy link

Betsy25 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
Copy link
Contributor

gorhill commented Mar 30, 2015

Never mind, bad example.

@gorhill
Copy link
Contributor

gorhill commented Mar 30, 2015

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

@Mikey1993
Copy link
Contributor

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?

@gitarra
Copy link

gitarra 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
Copy link
Contributor

@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
Copy link

gitarra 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 subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants