|
|
||
Ad Blocking© Copyright Darrell Anderson. (February 2007) Despite my recent improved performance with configuring the Firefox web browser, my efforts left me without any ad blocking. I dislike advertisements of all types, in any medium. Advertisements do not succeed with me and do not sway my opinion. I neither believe nor embrace the philosophy of advertising. The web is no different and for the past many years I have used various schemes to impede web ads. Yes, I know some web site owners use ads to generate revenue, but I never paid attention to ads in magazines and the web is no different for me. I will ignore ads to my pleasure. Without an ad blocker extension installed in Firefox I was not about to use that browser with any seriousness. So I returned to using K-Meleon. No sooner had I done that when I realized that out-of-the-box K-Meleon used some sort of ad blocking technique. I never had any reason to examine that aspect of the browser, but then I did. I discovered that the K-Meleon developers were using a simple CSS (cascading style sheet) scheme to block ads. I perused the document and then saw no reason why the style sheet could not be used in Firefox. I copied the document to my Firefox profile chrome directory, added the necessary import command to my master userContent.css style sheet, and then started Firefox. As expected the ad blocking style sheet succeeded just fine. I had successfully blocked the ads from appearing in Firefox, but technically I was not actually blocking the ads. The ads still downloaded to my computer and the style sheet merely prohibited displaying the ads. Therefore I was consuming unnecessary bandwidth. Although I now am on a broadband connection, I continue to treat the web much the same as I did when I was stuck on dial-up. I dislike wasting bandwidth in any sort of manner. I began researching for more information. I knew about the time-tested trick of using a hosts file to block ads. That was the method I used long ago, in the original hey-day of everybody trying to stop web ads. Yet as the hosts file grew, I began to notice some slowness associated with those look-ups. Additionally, a hosts file can stop look-ups only at the top domain level. The file cannot be used to stop look-ups for sub levels in a domain. After ad blocking became a standard feature in Firefox, which back then was my sole browser, either through style sheets or a browser extension, I stopped using the hosts file to block ads. Today I use that file only as a quick-and-dirty DNS server for my browser bookmarks and small home network. With some additional research I discovered I could extend the use of the hostperm.1 file to block ads. I also knew I could use my Squid caching proxy to block ads. Which approach would be best? I really did not know. I use three browsers: Firefox, K-Meleon, and Opera. None are ideal and I tend to use them all. Therefore I preferred the Squid approach because then I could use any browser and not worry about configuring each browser individually. Using a lengthy URL list I created previously from my days of using an exhaustive hosts file, along with a new list snatched from a web site dedicated to blocking ads, I used the handy sort and uniq command line tools to create an exhaustive Squid ACL (access control list) and configured Squid accordingly. I indeed stopped all ads. The Squid approach was functional. Not only was this strategy stopping the display of ads, but DNS look-ups too. Definitely a nice bandwidth saving strategy. However, I then had to contend with the numerous Squid error messages inside those boxes where the ads normally would display. Because the ad boxes are smaller than the full-page Squid error messages, all I could see was the top half of the word ERROR. I knew what the error message displayed and that the messages were harmless, but having a web page filled with these partial messages was distracting. I next decided to try the hostperm.1 approach. I disabled the Squid ad server ACL and restarted Squid. I then migrated the same URL information into a large hostperm.1 file. I blocked all images from those same URLs. That stopped the display of all ad server images, but was no longer stopping the DNS lookups. After some additional research I decided to improve the hostperm.1 file by not only blocking all images from the ad server URLs, but also all objects, subdocuments, scripts, and cookies. I have long used a cookie white list approach in all browsers, but I liked the idea of at least blocking cookies to ad servers in case I somehow manually enabled cookies for a particular site and then forgot to disable cookies. (Yes, I still have Firefox and K-Meleon configured for treating all cookies as session cookies should I forget.) Stopping all scripts from those same ad servers also seemed cautious in case I manually enabled JavaScript and forgot to disable when moving to another web site. All of these blockage directives increased the size of my once very modest hostperm.1 file to a hefty 325 KB. Would such a large file impede the browsing performance of Firefox or K-Meleon? The surprising answer was no, not at all. Although I have no way to provide quantitative measurements, my gut response and observation is that the hostperm.1 strategy improves web surfing better than the Squid ACL approach. My unscientific wild guess is because the look-up process stops directly at the browser rather than at some step further down the line. The browser sees the block directive to a particular URL or IP address and never makes any related requests. I’m presuming Squid and a browser must communicate with one another every time the browser requests something from a URL blocked by Squid, but blocking items directly at the browser level precludes any such digital conversation. The hostperm.1 file works with any Gecko based browser. In addition to the elements I mentioned previously, the file supports install, popup, document, stylesheet, and refresh. I later added the document and stylesheet elements to my new hostperm.1 file. A significant challenge to using the hostperm.1 file is that none of the Gecko browsers provide a user interface for all of the elements. Users must add those elements manually with a text editor. Additionally, although many people seem aware about using the hostperm.1 file to block images, unless the other elements are blocked then significant bandwidth is still wasted downloading those related files. One additional shortcoming of the hostperm.1 file is that there is no global all element, which would reduce the size of the file and avoid needing to itemize every element. If you are interested I have posted a copy of the relevant portion of my hostperm.1 file here at my web site. Download and append that file into your existing hostperm.1 file. Of course, make a backup to your existing hostperm.1 file in case there are problems so you do not lose any of your current configuration information in that file. One additional note about that file, in case downloading my copy seems to fail: all of the information in that file is tab-delimited. That is, everything in that file is separated by the tab character, not spaces. Be careful when importing that text not to convert the tabs to spaces. Also know that my copy is an aggressive list of URLs and IP addresses. Should you discover that certain elements of a web page no longer display correctly, check your new hostperm.1 file. Be aware that because of the size of the file, accessing the hostperm.1 file through the Firefox Preferences, such as the Images or Cookies Exception lists, will take several seconds longer than normal. The same technique seems to succeed for the Opera browser. The file to use is the filter.ini file, stored in the Opera user profile directory. The format is different but I have posted a copy of my file here as well. For Opera you might need to manually edit your opera6.ini file to include the filter.ini file. In the section titled [Adv User Prefs], enter the following key name and value: URL Filter File=Location\Of\Opera\Profile\filter.ini I imagine the same technique would work with the Konqueror browser, but I have not tried to migrate the hostperm.1 file to the Konqueror format. Liking what I saw with the hostperm.1 file, I also re-enabled my Squid ACL. I have noticed no decline in web surfing speed with these two tools. To block web ads and other unwanted files, some people might recommend Privoxy. I did notice this option during my research, but I wonder if Privoxy must communicate with a browser much like Squid with each blocked request and hence actually impede browsing sessions. And unlike Squid, which merely ignores requests to specified domains, or the hostperm.1 file, which stops requests at the browser level, Privoxy must actually manipulate the html code on-the-fly. That exercise must require some processing time and impact overall web surfing speed. I do not know the answer to that question, although I am trying to learn more about Privoxy. Like Squid, Privoxy would seem to provide more flexibility in a multi-browser or multi-user environment. The browsers I use today provide me the ability to individually manage cookies and images. That is, creating white lists with the browsers is straightforward. Possibly I could (or should) continue blocking ads at the browser stage, which now seems the most efficient method, and use Privoxy for additional filtering such as removing web bugs, killing auto-refresh, and creating white lists for using JavaScript, HTTP Referrers, user agent requests, and GIF animations. Although I could learn to accomplish the same with style sheets, I’m curious whether Privoxy can filter or modify web pages to eliminate obnoxious bright and fluorescent colors. Privoxy probably would provide me a one-stop solution to spoofing user agent information and providing the correct information for those few web sites I visit and trust. Currently in Windows I still use Proxomitron for that task, but in Slackware I have no such tool, especially now that I have uninstalled the User Agent extension with my recent tweaking adventure. Hence my interest in Privoxy. In Firefox I now use the PrefBar extension to modify the user agent string as needed. K-Meleon and Opera provides some of their own similar strings. I don’t think Konqueror provides any handy way to quickly modify the user agent string. Some people might ask why bother with user agent strings? At one time long ago I was concerned about protecting my privacy, which was why I then spoofed the user agent info. Which browsers I use is really nobody’s business and I am not interested in puffing anybody’s web site statistics. Today, however, my primary concern is that I am a silent protester against idiots who cannot design a browser-independent web site. I therefore spoof the user agent with ridiculous info. There is no reason whatsoever to design a web site to respond differently to all the various browsers. And I detest bandwidth-wasting JavaScript anyway. Some people might argue that a combination of hostperm.1 and CSS is best. Possibly, but using a CSS to hide those files not blocked by hostperm.1 means a user never sees those files to add them to the hostperm.1 file. Blocking access at the hostperm.1 level is more efficient to save bandwidth. Without using a CSS, those few files escaping the hostperm.1 block list are seen by users and then more easily added. With GNU/Linux, another option to block various domains is to use dnsmasq. Create a second hosts file containing only ad servers and enable the addn-hosts directive to the dnsmasq.conf file. Too bad Windows does not support anything as easy as that. Of course, all of these methods are brute force blockage, which is why a tool like Privoxy might be helpful. Update(June 2007) To keep my Squid and hostperm.1 files current, occasionally I visit this web page. I save the file and then use WinMerge to manually synchronize additions to my existing Squid ACL file. I wrote a script (Windows batch file) to help me maintain my ad blocking lists. I can manually add new URLs to my list as I discover them. The script adds the new URL to my Squid ACL file, and then modifies a copy of the new ACL file to amend my hostperm.1. The script also creates a second hosts file for dnsmasq. Using SCP I copy that updated dnsmasq file to my Linksys WRT54GL (1.1) router using DD-WRT. I am not a programmer and I cannot say for certain how all of this functions. However, I suspect that my hostperm.1 file blocks most of my unwanted URL requests. Then again, the hostperm.1 file might not be used to prevent URL requests, and might be doing little more than what a style sheet performs. That is, possibly all elements in a page are downloaded and the browser merely uses the hostperm.1 file to prohibit displaying those elements. If true, then I am not saving any bandwidth using a hostperm.1 file. Additionally, as I mentioned previously, the hostperm.1 file does not provide an all tag and therefore I suspect a few URL requests slip by the hostperm.1 file. Squid blocks those requests and as a second effort, my dnsmasq second hosts file at my router stops associated DNS lookups. Although the Adblock extension might be more flexible at blocking ads through the use of regular expressions, my approach seems as efficient (or better). As I mentioned previously, I notice no slowdown with this approach. Using the hostperm.1, the Squid ACL, and a second hosts file for dnsmasq, I pretty much block all unwanted ads. Regardless, if a person wants only to block ads, which primarily are image files, then the hostperm.1 file will stop displaying those files whether or not the images actually are downloaded. This would be a more straightforward approach for many people who do not want to write custom style sheets. Lately, however, I have been surfing without using the exhaustive hostperm.1 file. My current hostperm.1 file contains only my white lists for controlling images and cookies. I have noticed no difference in speed or page displays because I continue using the Squid ACL and dnsmasq files. Files: hostperm.zip (92KB Zipped) filter.zip (17 Zipped) Finis. |
||