Page 1 of 1

full domain blocking

PostPosted: Wed Oct 23, 2013 1:10 pm
by mapx

by N/A » Wed Oct 23, 2013 12:39 pm

I'm sure there are some users who only see ABP as an ad blocker. Yet it is really a multi-purpose tool. It is a simple ad blocker (EasyList), a privacy threat blocker (EasyPrivacy) and a security threat blocker (MalwareDomains). Being able to block all requests to a domain, including those caused by a user clicking on a link, is absolutely necessary to the privacy and security threat cases, and it is even useful for the ad blocking case for those rare (?) cases where links redirect you through an ad page. ABP's usefulness is seriously weakened by this limitation. Yet the hole is left open. Why?

I think it obviously best if subscriptions could make use of total domain blocking, but even if someone were against that for some reason, there would be the option of creating special filter syntax that only works in custom filters.

Isn't it kind of ridiculous for people to add another addon when ABP could easily support full domain blocking and that support would improve ABP dramatically?

Re: full domain blocking

PostPosted: Wed Oct 23, 2013 7:02 pm
by famlam
Just some thought, but you could make this the behavior of $document if no @@ is present. Currently rules like
Code: Select all
do nothing, they only work when they're preceeded by @@.
Downsite of blocking an entire domain is that you would be staring at an empty screen, when blocked. I'm not that sure if that's very user friendly...

Re: full domain blocking

PostPosted: Thu Oct 24, 2013 8:43 am
by Gingerbread Man
This feature (called "Site Blocking") was removed all the way back in Adblock Plus 0.6. I wouldn't expect it to be re-implemented.

Re: full domain blocking

PostPosted: Thu Oct 24, 2013 10:20 am
by mapx
that one was buggy

could be also very useful for the links you click on the background images, for redirects

Re: full domain blocking

PostPosted: Thu Oct 24, 2013 6:55 pm
by N/A
For convenience:

"Site blocking" was a feature in Adblock 0.5 that allowed filters to be applied to web pages as a whole and prevent you from navigating to a page that matched some filter on your list. The main reason why this function wasn't kept in Adblock Plus 0.6 is: preventing you from seeing a page you explicitly requested doesn't have much to do with ad blocking. Also, the way it was implemented in Adblock was flawed in a number of ways:

Instead of leaving you on the page where you were before, Adblock would show you an ugly error page.
The way this error page was displayed often caused browser issues like dysfunctional tabs.
Any filter on your list was used for site blocking even though only a few were intended to be.

Yet there are still people who need this functionality. And therefore I am happy that there is an extension now that can prevent the browser from navigating to certain web pages better than Adblock ever did: BlockSite. This extension supports the same filter syntax as Adblock Plus 0.7. And instead of displaying an error page this extension will notify you via info bar, similar to when a popup is blocked — you don't leave the page you are currently viewing.

The error page issues I can understand. Perhaps those problems can be eliminated (now). If not, there is the info bar. The "what filters should this apply to" issue I can also understand. Perhaps through creative thinking that issue can be solved nicely. If not, a new type of filter rule could be created. As for the "main reason" listed above, it doesn't seem very strong to me. First we should remember that users can accidentally click on a link, and they often don't know where a link is really going to take them. So we can't use "you clicked on the link, you must want to see the page" type logic. Next we should remember that ABP is an engine that helps subscriptions & filters accomplish their mission. As mentioned in the other thread, the MalwareDomains subscription seems like the clearest case where you would want everything blocked. EasyPrivacy would be another good example. Many of the domains that are a privacy threat in third-party context are also a threat in first-party context. It would be good to be able to cover both scenarios with one filter rule. Including the scenario where a link triggers a request to the site you are interacting with but it gets redirected to some other site. As for routine ad blocking, which also plays a big role in shielding users from privacy threats and security threats, how can you (with the current design) block a link on website1 from bouncing you off website2 which serves interstitial ads, responding with a pure text ad html page with a N second meta-refresh or responding with an image file ad with a N second Refresh HTTP header?

Even if you wanted to blow off improvements to ABP that would make subscriptions work better and custom filters work better, is BlockSite a good substitute? Does it have built-in support for auto-updating of subscriptions?

Re: full domain blocking

PostPosted: Thu Oct 24, 2013 7:09 pm
by mapx
blocksite or blocksite plus (for firefox) "blocks websites of your choice", do your own list. The list can be imported / exported, so, probably can be use some script to generate the list (in blocksite format) using malware domains for example

Re: full domain blocking

PostPosted: Thu Oct 24, 2013 7:26 pm
by N/A
That's what the screen shots suggested to me: manual import/export. Which would be fine for some things and some people. Not ideal for others though.

Re: full domain blocking

PostPosted: Fri Oct 25, 2013 8:10 am
by lewisje
I can confirm that with current filter-lists, blocking the main document results in some severe false positives, like any forum thread about "ads" or "advertising" or "adsense" gets blocked because of what is in the address bar; I implemented it in my experimental fork of ABP that was mostly centered around a variety of null-content redirection, and I'm thinking that blocking the main document is only viable if another option were made (like maybe $main) that would need to be explicitly set for a filter to block the main document (link goes to post where you can download the build): viewtopic.php?p=82629#p82629

A little later in that thread, you can see me musing about a better redirection for the main document (about:blank made it impossible to figure out where you were trying to go and is less helpful than cancel:true, which keeps the blocked URL in the address bar and tells you that an extension blocked the page).