Web Browsing


Blocking Connections to

Performance-Degrading

'3rd-Party' Internet Hosts

Home > RefInfo menu > Computer topics menu >
This Web Browsing (Blocking Connections to Performance-Degrading Internet Hosts) page

! Note ! A few more notes and images may be added,
if/when I revisit this page in the future.

INTRO     HOST BLOCK LISTS     QUESTION1     QUESTION2     QUESTION3     QUESTION4    

A SMALL LIST     HOST BLOCK EFFECTS     DISGUSTING PEOPLE     RUINERS of the Internet     SUGGESTED LAWS

INTRODUCTION :

In 2014, I found that I was getting more and more frustrated with encountering web pages that took minutes --- not seconds, MINUTES --- to load into my web browser.

I noticed that at the bottom of my web browser, there is a 'status line' which shows the web hostnames that are being accessed (connected to) --- as the web page is being processed by my web browser.

I could tell which web hosts were causing a page to load slowly --- because the web host name would be 'frozen' in the status line for many seconds --- sometimes a minute or more.

    (I like to use the Mozilla 'Seamonkey' web browser --- because it has a robust 'Bookmarks Manager' --- to deal with the thousands of bookmarks that I have collected over the years. The Seamonkey web browser is similar to the Mozilla Firefox browser in many ways.)

    (I often browse the Internet on a little netbook computer, while watching TV --- to have something useful to do while the cable TV channels --- FOR WHICH I PAY A VERY HEALTHY MONTHLY FEE --- bombard me with a half-dozen to a dozen ads at a time --- many times per hour. The old Intel Atom N450 chip on that netbook computer is rated less than half as fast as higher level Intel chips --- such as 'i3' or 'i5' or 'i7' --- but it still should browse most sites quickly. The pages of my site --- this site --- come up quickly on that netbook computer --- as does the simple Google search page.)

Often a web page would appear to be completely loaded, but my cursor would be 'spinning' --- showing that the web browser was still 'busy' --- and a hostname would be 'frozen' in the status line while my web browser program was apparently trying to connect to that host --- apparently with little success. (OR that Internet host was trying to collect a heck of a lot of information from my computer --- OR that host's processing was caught in a loop of its own twisted making.)

Some web hostnames would flash by so fast I could not read them. But some would stay in the 'status line' for many seconds --- hostnames like those marked with an exclamation point in the image at the top of this page:

  • ad.doubleclick.net
  • pubads.g.doubleclick.net
  • apis.google.com
  • www.google-analytics.com
  • partner.googleadservices.com
  • pagead2.googlesyndication.com
  • www.googletagservice.com

These are all Google related. (Google bought DoubleClick in 2008.) Some other web hostnames would also appear 'frozen' in my web browser status line. Names like

  • fbstatic-a.akamaihd.net
  • js-agent.newrelic.com
  • edge.quantserve.com
  • media.richrelevance.com
  • recs.richrelevance.com
  • b.scorecardresearch.com

These are all '3rd party' hosts that are getting between me (the 'first party') and the web site (the '2nd party') that I am trying to visit. Typically I arrive at a web page because a web search has led me to a page at the web site --- web pages at sites like

  • arstechnica.com
  • foxnews.com
  • huffingtonpost.com   (a site with horribly-written, very-slow web pages)
  • officedepot.com
  • scribd.com   (another site with processing-hungry pages)
  • target.com
  • tigerdirect.com
  • tomshardware.com
  • walmart.com
  • washingtontimes.com   (like many news sites, slow --- but horribly slow)

The web pages of sites like these --- shopping sites, news sites, technical information sites --- are 'heavily-loaded' with MULTIPLE invocations of '3rd-party' Javascripts.

Often I would see a 'gray-out' of the web-browser window as a Javascript invoked by the web page would cause my browser to experience a script that was 'in a loop'. Typically, not only would my web browser be so incapacitated that I could not 'back out' of the web page (or even close or exit the browser) --- but, also, my entire computer would be bogged down ('frozen up') by the immense amount of processing caused by the offending Javascript.

The occurrence of 'brown-outs' and 'freezes' like these were getting so annoying (and were becoming such a major time-waster) that I decided to look for a solution.

    To avoid slow-downs and freezes on web pages, sometimes I would turn off Javascript in the Seamonkey web browser, but that has issues. For one thing, there is no keyboard shortcut for toggling Javascript-interpretation on and off. In Seamonkey, one has to go through a chain of menus --- 'Edit > Preferences > Advanced > Scripts & Plugins' --- to enable/disable Javascript interpretation/processing.

    There are many pages on the internet that show you (with screenshots) how to turn off Javascript in about 5 different web browsers --- such as this page at tipsnext.com. In fact, that page says "once you disable it [javascript] you will see the difference. The browsing speed improves dramatically ... that is, you can notice that the web pages load fast compared to earlier."

    Unfortunately, up through early 2015, none of the available web browsers appear to have a keyboard-shortcut (or an always-visible button/icon) for disabling and enabling Javascript interpretation.

    Another problem is that some aspects of web pages do not work when Javascript is turned off. For example, at sites that show a list of products (such as computers or shoes), the 'sort by' option will usually not work with Javascript disabled.

    I found that I mainly needed to avoid connecting to certain hostnames that were not providing any service to me --- but presumably some service to the maintainers of the web site --- such as gathering my personal information or popping up 'monetizing' ads in my face. F**k that sh*t.


Host Block Lists

I found that when I did a web search on words like 'google-analytics slow web browsing', I found many pages with titles like 'Tired of waiting for www.google-analytics.com' and 'Why I removed Google Analytics from my website'.

I immediately found that some people were blocking connection to such hostnames via lines like

   0.0.0.0 www.google-analytics.com
OR
   127.0.0.1 www.google-analytics.com

added to a 'local hosts file'. On Linux operating systems, the fully-qualified name of that file is '/etc/hosts'.

I found that when I did a web search on words like 'hosts block list', the first hits that came up were at winhelp2002.mvps.org/hosts.htm --- titled 'Blocking Unwanted Connections with a Hosts File' --- and someonewhocares.org/hosts/ --- titled 'Using a Hosts File To Make The Internet Not Suck (as much)'.

These are sites that offer thousands of lines that you can add to your 'hosts file' to block connections to offending hosts.

I immediately had several questions:

  1. Should I use '0.0.0.0' or '127.0.0.1'?

  2. Isn't thousands of hostnames in the hosts file going to adversely affect performance as each hostname in a web page is compared to the huge list?

  3. How do I capture the hostnames that I should block, from the web pages that I visit? (I generally cannot read them from the status line of my web browser because they often 'zip by'.)

  4. Wouldn't it be better to use a blocking technique by which I could block out whole ranges of IP addresses --- like 'google' and 'doubleclick' and 'cloudfront' addresses --- for example, via 'iptables' commands on Linux?

It was not easy to find answers to these questions via web searches.

These questions are dealt with in sections below.


Question-1: '0.0.0.0' or '127.0.0.1' ?

There has been some controversy over whether '0.0.0.0' or '127.0.0.1' results in faster blocking.

As far as Linux goes (in 2015 --- or, more specifically, with Ubuntu 9.10), there appears to be no significant difference. I found that when I made an '/etc/hosts' file containing lines like

   0.0.0.0 www.google-analytics.com

and when I tested by doing a 'ping' of such a host, I got the following type of result:

   $ ping www.google-analytics.com
   PING www.google-analytics.com (127.0.0.1) 56(84) bytes of data.
   64 bytes from localhost (127.0.0.1): icmp_seq=1 ttl=64 time=0.040 ms
   64 bytes from localhost (127.0.0.1): icmp_seq=2 ttl=64 time=0.049 ms
   64 bytes from localhost (127.0.0.1): icmp_seq=3 ttl=64 time=0.040 ms
   64 bytes from localhost (127.0.0.1): icmp_seq=4 ttl=64 time=0.039 ms

Note that although I had '0.0.0.0' in the /etc/hosts file, the 'ping' was indicating that the hostname was being 'automatically' translated to '127.0.0.1'.

Furthermore, note that the 'pings' were being resolved in hundredths of a millisecond rather than the typical tens or hundreds of milliseconds. Example:

   $ ping www.google.com
   PING www.google.com (74.125.137.104) 56(84) bytes of data.
   64 bytes from yh-in-f104.1e100.net (74.125.137.104): icmp_seq=1 ttl=46 time=30.1 ms
   64 bytes from yh-in-f104.1e100.net (74.125.137.104): icmp_seq=2 ttl=46 time=29.7 ms
   64 bytes from yh-in-f104.1e100.net (74.125.137.104): icmp_seq=3 ttl=46 time=30.6 ms

So the '0.0.0.0' statements in the /etc/hosts file are doing their job of blocking the connection to an external host --- by fooling the web browser (and 'ping') into trying a local connection.

    NOTE:
    The blocking was occurring about 1,000 times faster than contacting a remote host --- and this does not include the other processing that would occur in connecting to the host over the Internet and then performing the processing that that host wants to do --- which might involve the exchange of many, many packets between the remote host and my computer.


At one time, the 'winhelp2002.mvps.org' site said that there was no difference in using '0.0.0.0' or '127.0.0.1'. However, in 2015 Jan, I see the page winhelp2002.mvps.org/hosts.htm contains the following sentence.

    The HOSTS file now contains a change in the prefix in the HOSTS entries to "0.0.0.0" instead of the usual "127.0.0.1". This was done to resolve a slowdown issue that occurs with the change Microsoft made in the "TCP loopback interface" in Win8.1.

So, on some operating systems, you may find a difference between using '0.0.0.0' and '127.0.0.1'.

I am using '0.0.0.0' on my Ubuntu 9.10 (2009 October, Karmic Koala) version of Linux.


By the way, the following image indicates how I edit (add hostname lines to) my /etc/hosts file.

I backed up my original /etc/hosts files to /etc/hosts_ORIG by using a 'sudo cp' command.

Nowadays I go into edit mode on the 'hosts' file using a command like 'sudo gedit hosts'. I enter (or paste) new hostname lines into the editor window. I simply use the 'Save' option when done.

I also use 'Save As...' to make a copy to a backup file with a name like 'hosts_2015jan30'.


Question-2: Huge Hosts File Affects Performance ?

In doing web searches on this question, I found a few people who claimed that you can have many thousands of entries in the 'hosts file' without impacting performance in the 'host lookups'.

However, I finally found a web page (a 2009 posting at 'discussions.apple.com') that indicated that a really big 'hosts file' (16,000-plus lines) can have a really bad impact on computer performance (using 100% of all 8 cores of an 8-core CPU --- for 'Directory Services').

The bottom line is that I believe that I will never encounter thousands of the hosts in the hosts files at winhelp2002.mvps.org/hosts.htm and someonewhocares.org/hosts/.

I prefer to assemble my own /etc/hosts file --- adding hosts as I encounter them.

And if I find that I am accumulating many thousands of hostnames, I may comment out many of the ones that seem to 'resolve' very quickly.

The hostnames that actually show up in the 'status line' of my web browser for at least a second or two, I will enter (or leave uncommented) in my /etc/hosts file.


    The site 'winhelp2002.mvps.org' points out that none of their web pages have references to Javascript that must be fetched from '3rd party' hosts.

    HOWEVER, the web page at 'someonewhocares.org/hosts/' has a reference to the Javascript 'http://stats.g.doubleclick.net/dc.js'.

    Tsk. Tsk. Does 'someonewhocares' really need money (or whatever) from 'doubleclick' so much that they need this Javascript on their web page?


Question-3: How to capture offensive hostnames from a web page ?

The status line ? (NO)

Since many of the offensive hostnames 'zipped by' on the 'status line' of my web browser, I needed to find a different way to gather the offensive hostnames from a web page.

The web page source ? (NO)

Browsing the source of a web page would be very tedious and time-consuming. So using the 'View > Page Source' option of my web browser was not going to cut it --- even if I would save the page-source to a file and apply a script to that file to extract the pertinent hostnames. (It would be a challenge to write such a script.)


The 'tcpdump' command ? (NO)

Another solution I considered was using the 'tcpdump' command --- just before loading a web page --- to capture the hostnames from SYN or ACK packets.

However, I found that rather than capturing names like 'www.google.com', the 'tcpdump' command was showing names like 'yh-in-f104.1e100.net' --- the names after they had been converted to another hostname. This was probably not going to work well --- to block the connection to the original hostname.


The 'Page Info' option of Seamonkey ? (YES)

In searching the interface of my Seamonkey web browser, I tried out the various icons on the periphery of the web browser window.

On the lower-right of the browser window, there was a pad-lock icon as seen in the following image. It referred to 'security information'.

When I clicked on the pad-lock, the following 'Page Info' panel appeared.

When I clicked on the 'Links' tab of the window, the following list appeared. Note the references to 'text/javascript' and 'Script' --- and 'googletagservices'.

When I scrolled down to the bottom of the 'Links' window, a few more references to 'text/javascript' and 'Script' and '.js' files were revealed.

In a simple HTML page with no Javascript, the column on the right is filled with the word 'Anchor' --- there are no references to 'text/javascript' or 'Script'.


When there are icons on an application window, typically the icon function is also available via a drop-down menu from the top 'toolbar' of the application window. So I started looking for such a drop-down menu.

I found the 'View > Page Info' option in the Seamonkey drop-down menu --- as seen in the following image.

When I clicked on this 'Page Info' option, the 'Page Info' panel appeared --- but it looked a little different from the 'Page Info' panel that I got from clicking on the pad-lock icon.

The following image indicates that the text in the 'General' tab is shown --- whereas the text in the 'Security' tab is shown when you click on the pad-lock icon.


Clicking on the 'Links' tab revealed a listing of 'Scripts' --- and 'Related Items' and 'Stylesheets' --- similar to the 'Page Info' list above.

And scrolling to the bottom of the 'Links' window revealed the same 'Script' lines as in the 'Page Info' list above.

So I find that I can collect 3rd-party hostnames by looking for hostnames in the 'text/javascript' or 'Script' lines of the 'Links' window. In other words, I scan the 'Name' and 'Type' columns for a 'script' reference and get a hostname from the 'Address' column.

And I can see the 'PageInfo > Links' window for any web page by any of 3 methods:

  • click on the pad-lock icon on the lower-right of the browser window,
  • use the 'View > Page Info' drop-down menu,
  • use the 'Ctrl+I' keyboard shortcut.


Question-4: Block by IP-address-ranges rather than individual hostnames ?

I have seen that some of these 'offensive' 3rd-party hosts refer to themselves as providers of 'SaaS' (Software as a Service).

I look at them as providers of 'SaaD' (Software as a Dis-service).

Unfortunately, there are unscrupulous 'SaaD' people out there who are purposely making it hard for people to block their hosts. They do this by generating essentially hundreds of possible hostnames in their 'domain'. Examples:

Example-1 :   (intellitxt)

'intellitxt' adds customer/company names to some hostnames that they use to provide their 'dis-service'. Example:

   tomshardware.us.intellitxt.com

They have other 'fixed' hostnames, such as 'images.intellitxt.com' --- which I block.

I am reluctant to add, to my 'hosts' file, the hostnames with customer-ID's in the hostname. I may end up with hundreds of such hostnames in my 'hosts' file.

Example-2 :   (cloudfront)

In January 2015, it appeared that 'cloudfront' added today's date --- in the form yyyy-mm-dd --- to some of the hostnames that they were using to provide their 'dis-service'. Example:

   2015-01-26-10.cloudfront.net

(That fourth set of digits is probably an hour-of-the-day.)

In February 2015, I found that 'cloudfront' was apparently generating 'randomized' hostnames, about 13 or 14 characters long, such as the following.

   d8rk54i4mohrb.cloudfront.net  # at lifehacker.com (2015feb17)
   d3v27wwd40f0xu.cloudfront.net # at tigerdirect.com (2015feb17)
   dnn506yrbagrg.cloudfront.net  # at linuxjournal.com (2015feb17)

When I pinged them 4 days later, they were still ping-able --- at the following IP addresses.

   d8rk54i4mohrb.cloudfront.net  # at 54.230.17.227 = server-54-230-17-227.iad12.r.cloudfront.net
   d3v27wwd40f0xu.cloudfront.net # at 54.230.18.168 = server-54-230-18-168.iad12.r.cloudfront.net
   dnn506yrbagrg.cloudfront.net  # at 54.240.160.26 = server-54-240-160-26.iad12.r.cloudfront.net

It is not clear to me, yet, for how long these 13/14-character 'cloudfront.net' hostnames will be 'defined'. But 'cloudfront' may use some method of changing the hostnames that they use, over time.

(In any case, their hostnames will probably still be associated with IP addresses of their 'more permanent' hosts --- which may continue to use 'server-*-cloudfront.net' hostnames.)

    Note that 'cloudfront' is an Amazon entity. Amazon started Cloudfront in 2008.

    Amazon has other such companies, such as Goodreads, started in 2007, which has hostnames such as 's.gr-assets.com' --- which I block because it was causing some serious slowdowns.

    It is somewhat ironic (and very disgusting) that two of the most useful websites on the Internet --- www.google.com and www.amazon.com --- are also responsible for a large part of the shenanigans (and slowdowns) that are going on 'underneath the covers' via organizations like 'doubleclick' and 'cloudfront' and 'goodreads'.


It appears that these 'cloudfront' and 'intellitxt' A-holes are going to lead us 'end-users' to look up the IP-address ranges that have been assigned to them, and then block the entire IP-address ranges.

There are plenty of web pages on the Internet showing how to block incoming IP-address ranges (for example, from China and Korea) by using the 'iptables' command on Linux operating systems. Example:

iptables -A INPUT -s 203.194.0.0/18 -j DROP
iptables -A INPUT -s 60.208.0.0/12 -j DROP
iptables -A INPUT -s 202.96.0.0/12 -j DROP
iptables -A INPUT -s 60.0.0.0/11 -j DROP
iptables -A INPUT -s 222.192.0.0/11 -j DROP
iptables -A INPUT -s 203.193.128.0/18 -j DROP

However, we will need to block the outgoing connection attempts from our web browser. Presumably, we will be able to do that with commands like

iptables -A OUTPUT -p tcp -d 69.171.224.0/19 -j DROP

I would probably drop the '-p tcp' parameter, because I would want to block ALL output to the IP address range --- whether the protocol was TCP, UDP, or whatever.

I will add more information here after I accumulate more experience with using 'iptables' to block these 'SaaD' people from degrading and destroying my Internet browsing experience.

As a preliminary example, here is how I may proceed to write a script to block lots of 'cloudfront.net' addresses:

    #!/bin/sh
    
    ## From 'man iptables':
    ## -F, --flush [chain]
    ##	      Flush the selected chain (all the chains in the table if none is
    ##	      given).	This is equivalent to deleting all the rules one by one.
    
    iptables -F
    
    ## Say I want to block groups of IP addresses 'around' the
    ## cloudfront.net hosts listed above:
    ##   d8rk54i4mohrb.cloudfront.net  # at 54.230.17.227
    ##   d3v27wwd40f0xu.cloudfront.net # at 54.230.18.168
    ##   dnn506yrbagrg.cloudfront.net  # at 54.240.160.26
    ##
    ## At a website like 'ipinfo.io', you can enter the address 54.230.17.227
    ## and find that it is an address of Amazon network AS16509.
    ##
    ## If you follow the 'ipinfo.io' link to the AS16509 page,
    ## it shows many, many Amazon address ranges, including the
    ## following that include the above 3 addresses:
    ##   54.230.16.0/22
    ##   54.240.160.0/23
    ## So one can try the following OUTPUT-DROP statements.
    
    iptables -A OUTPUT -d 54.230.16.0/22 -j DROP
    # iptables -A INPUT -s 54.230.16.0/22 -j DROP
    
    iptables -A OUTPUT -d 54.240.160.0/23 -j DROP
    # iptables -A INPUT  -s 54.240.160.0/23 -j DROP
    
    ## And I would add some OUTPUT-DROP statements for 'intellitxt.com'.
    
    

    You can verify that '54.230.17.227' and '54.230.18.168' are in the IP address list given by CIDR (Classless Inter-Domain Routing) notation '54.230.16.0/22' by using this CIDR-to-IP-list Converter at magic-cookie.co.uk.

    The IP address list can be rather long. To get a range (simply min-address and max-address), you can try this CIDR-to-IP-range Converter at tools.tracemyip.org.

Whenever I want to block more IP address ranges, I would add OUTPUT-DROP statements to this script --- then simply rerun the script. (And I would probably un-comment and use the INPUT-DROP statements as well.)

If you wanted to block entire countries, you could try a script like one at howtoforge.com. In case this link goes dead, here is the sample script.

    #!/bin/bash
    ### PUT HERE A COMA SEPARATED LIST OF COUNTRY CODES ###
    ###     Example: Afghanistan and Argentina          ###
    COUNTRIES="AK,AR"
    WORKDIR="/root"
    #######################################
    cd $WORKDIR
    wget -c --output-document=iptables-blocklist.txt http://blogama.org/country_query.php?country=$COUNTRIES
    if [ -f iptables-blocklist.txt ]; then
      iptables -F
      BLOCKDB="iptables-blocklist.txt"
      IPS=$(grep -Ev "^#" $BLOCKDB)
      for i in $IPS
      do
        iptables -A INPUT -s $i -j DROP
        iptables -A OUTPUT -d $i -j DROP
      done
    fi
    rm $WORKDIR/iptables-blocklist.txt
    

If I ever implement scripts like these, I plan to report interesting experiences here.


A simple, small addition for your 'hosts' file :

You can probably experience a much faster, smoother internet browsing experience by simply adding a set of about 15 statements to the bottom of your 'hosts' file --- like these:

0.0.0.0 ad.doubleclick.net
0.0.0.0 pubads.g.doubleclick.net
0.0.0.0 apis.google.com
0.0.0.0 www.google-analytics.com
0.0.0.0 partner.googleadservices.com
0.0.0.0 pagead2.googlesyndication.com
0.0.0.0 www.googletagservice.com
0.0.0.0 fbstatic-a.akamaihd.net
0.0.0.0 js-agent.newrelic.com
0.0.0.0 edge.quantserve.com
0.0.0.0 media.richrelevance.com
0.0.0.0 recs.richrelevance.com
0.0.0.0 b.scorecardresearch.com

That is because a huge number of web pages on the internet contain Javascripts that are fetched from these sites --- and connection to these hosts (and incurring their processing and input/output) significantly degrades your web browsing experience.

As I pointed out above, the web pages of

  • news sites (such as newspaper and magazine sites ... trying to 'monetize')
  • shopping sites
  • technical information sites

are 'heavily-loaded' with invocations of '3rd-party' Javascripts. For pages like these, you can MARKEDLY improve your web browsing experience by blocking about 15 to 20 hosts, like those above. (At least, that was the situation in early 2015.)

In 2015 September, I had about 300 '3rd party' hosts in my hosts file --- with very pleasing results. I do not provide my file here, because some of my '3rd party' host blocks cause some web pages to display in an almost unreadable format. And some '2nd party' web sites I block completely, because their web pages are such extreme processing hogs.

I am willing to tolerate those kinds of inconveniences, but others would probably prefer to see pages that I have blocked or 'partially blocked' via my hosts file. I suggest that people collect their own entries for their hosts file --- tailored to the sites that they have visited.


Some effects of host blocking on web pages :

Blocking some of these 'internet ruining' hosts can have some effects that you will notice in web pages --- or in their popups.

For example, when you went to 'phoronix.com' (in early 2015), you were always greeted with a popup advertisement --- in a window like the following.

In this case, you can see the hostname 'ad.doubleclick.net'. Blocking this hostname did not stop the popup, but it stopped the processing that would have been incurred by connecting to 'ad.doubleclick.net' and fetching the ad and placing it in the popup window.

In some cases, you can see this 'Failed to Connect' image in places on web pages where images (fetched from a '3rd party' host) were supposed to be displayed.

Another example:

Whenever I visted 'target.com' web pages, I noticed that the hostname 'Img1.targetimg1.com' was appearing for seconds at a time in the 'status line' of my web browser --- and the 'target.com' web pages were very slow to load on my old netbook. I blocked that hostname for a while, but I found that the 'target.com' web pages were coming up with no images. That affected the readability of the web page. The text was scattered around the web browser window --- making it hard to decipher the intended web page content.

So I commented out the '0.0.0.0 Img1.targetimg1.com' line in my '/etc/hosts' file. But, in the future, if I find 'Img1.targetimg1.com' is slowing down the showing of 'target.com' web pages to an annoying degree, I will un-comment that block-line and simply try to read the 'target.com' web pages without the images --- AND visit 'target.com' less frequently --- AND maybe block 'www.target.com' entirely. (I do not want to accidentally go there via a web search and have my computer lockup.)

I had a similar experience with the hostname 'www18.officedepot.com'. Images were being fetched --- slowly --- from this hostname, for web pages at 'officedepot.com'. I blocked the 'www18.officedepot.com' hostname for a while, but I commented the '0.0.0.0 www18.officedepot.com' when it was making it hard to read the 'officedepot.com' web pages.

However, like with 'target.com', if this images-host slows down my viewing of 'officedepot.com' web pages to an annoying degree, I will un-comment that block-line and simply try to read the 'officedepot.com' web pages without the images --- AND visit 'officedepot.com' less frequently --- AND maybe block 'www.officedepot.com' entirely with a '0.0.0.0 www.officedepot.com' line in my 'hosts' file.


DISGUSTING PEOPLE :

There are a lot of disgusting classes of people in this world:

  • Islamic terrorists
  • Dick Cheney and other lovers of torture
  • serial killers
  • serial rapists
  • predatory priests (and Boy Scout leaders)
  • Wall Street (and Main Street) investment scammers
  • Mexico (and U.S.) drug gangs
  • drive-by shooters
  • armed robbers
  • arsonists
  • spouse beaters
  • gun runners
  • medical doctors performing unnecessary surgeries
  • medical doctors over-prescribing and mis-prescribing drugs
  • medical doctors scamming the medical system of billions of dollars
  • pharmaceutical companies selling chemicals that don't quite kill, as drugs
  • pharmaceutical companies selling insufficiently tested drugs
  • pharmaceutical companies selling chemicals that barely helped less than 10% of testees
  • people in the Food and Drug Administration who approve these chemicals for sale
  • burglars
  • counterfeiters
  • crooked car dealers
  • crooked construction contractors
  • forgers
  • pimps
  • etc.

  • etc.
    (They are scattered throughout local, state, and federal government agencies such as the 'Bureau of Land mis-Management', the EPA - blocking clean water protections, the FDA - blocking food poisoning protections, the SEC - shielding their buddies at Goldman Sachs and elsewhere, etc. etc.)

And right up there, we have the 'ruiners and burglars of the internet'. Below is a list of many of the companies (their web domain names) that are the '3rd parties' that have either ruined my web browsing experience or offer nothing that I need and nothing that I want.

I do not want these 'remote hosts' interfering with my/our viewing the content of a web page --- by bombarding me/us with

  • popups,
  • images/video/audio/text that we do-not-need-nor-want (DNNNW),
  • network and computer processing that we do-not-need-nor-want.

I will not go into the personal-data-gathering (PDG) that many of them do --- and how well/poorly they protect that data --- and what they do with it. That is a huge area for discussion. I will just say that it is not their right to do that PDG without our consent.


Some '3rd-party' ('internet-ruiner') domain/company names:

'google*.com' (in its various forms, see above), 'doubleclick.net' (a Google company, as noted above), 'cloudfront.net' (an Amazon company, as noted above), 'goodreads (gr-assets.com)' (an Amazon company, as noted above), and many more :

  1. 'advertising.com' (a Baltimore, Maryland company)
  2. 'akamaihd.net' (a Cambridge, Mass. company)
  3. 'acxiom-online.com' (an Arkansas company)
  4. 'addthis.com' (a Virginia company)
  5. 'adroll.com' (a San Francisco company)
  6. 'amazonaws.com' and 'amazon-adsystem.com' (a Seattle company)
  7. 'adsonar.com' (owned by Quigo = Advertising.com, an Israeli/NewYorkCity company)
  8. 'adzerk.com' (a North Carolina company)
  9. 'bazaarvoice.com' (a partner with the ECircle email marketing and digital marketing provider headquartered in Munich, Germany)
  10. 'blogger.com' ("supports Google's AdSense service as a way of generating revenue" ; I have suffered 'brown-outs' too many times in going to Google Blogger pages ; for now, I simply block 'www.blogger.com' - any connection to this host)
  11. 'bluekai.com' ("enables companies to personalize online, offline, and mobile marketing campaigns ... collects PC and smartphone users' data to enhance ad marketing" ; bought by Oracle in 2014 ; started in Cupertino, California ; "has received criticism because users feel services like those they provide are an invasion of privacy")
  12. 'bootstrapcdn.com' (uses MaxCDN, a Los Angeles company. CDN = Content Delivery Network)
  13. 'brightcove.com' (a Boston company; pushing out video that I can do without)
  14. 'chartbeat.net' (a New York City company)
  15. 'chitika.com' (a Massachusetts company)
  16. 'clicksor.net' (an Ontario, Canada company)
  17. 'clicktale.net' (an Israeli company)
  18. 'cloudflare.com' (a San Francisco company)
  19. 'criteo.com' (serves personalized online display advertisements - HQ in Paris, France)
  20. 'demdex.net' (acquired by Adobe in 2011)
  21. 'disqus.com' (a San Francisco company)
  22. 'dotomi.com' (acquired by ValueClick in 2011 ; ValueClick changed its name to Conversant in 2014 ; Conversant is a California company)
  23. 'ensighten.com' (a 'market attribution' company - quantifies the influence each advertising impression has on a consumer's decision to make a purchase decision)
  24. 'exelerator.com' (info pending)
  25. 'exoclick.com' (a Barcelona, Spain company)
  26. 'feedburner.com' (bought by Google in 2007)
  27. 'gigya.com' (a Mountain View, California company)
  28. 'gravatar.com' (serves avatar images - bought by Automattic in 2007
  29. 'gravity.com' (acquired by AOL in 2014 ; based in Los Angeles)
  30. 'imonomy.com' (inserts ad images alongside web page content - an Israeli company)
  31. 'instantservice.com' (acquired by ATG in 2010 ; Oracle acquired ATG in 2011)
  32. 'intellitxt.com' (developed by VibrantMedia)
  33. 'kaltura.com' (pushes out video that I do not need-want ; a New York company)
  34. 'kontera.com' (provides obnoxious keyword advertising pop-ups - acquired by Amobee in 2014)
  35. a 'krxd.net' hostname (beacon.krxd.net) translated (via 'ping') to an Amazon 'amazonaws.com' Web Services server name.
  36. another 'krxd.net' hostname (cdn.krxd.net) translated (via 'ping') to a 'fastly.net' hostname. (Fastly is a CDN company used by Firebase Hosting.)
  37. 'lowermybills.com' (generates banner ads often including video clips - HQ in Los Angeles)
  38. 'monetate.com' (a Pennsylvania company)
  39. 'mybuys.com' (a San Mateo, California company)
  40. 'newrelic.com' (a San Francisco company)
  41. 'omtrdc.net' ("extensive data collection" via cookies --- "tracking the user's behavior across many sites" ; bought by Adobe in 2013)
  42. 'optimizely.com' (a San Francisco company)
  43. 'outbrain.com' (an Israeli/NewYork company -- related to adsonar/Quigo above)
  44. 'owneriq.net' (a Boston company with offices around the U.S.)
  45. 'pingdom.net' (based in Sweden ; bought by SolarWinds in 2014)
  46. 'playwire.com' (one of more than 200 websites/webhosts blocked in India)
  47. 'pubmatic.com' (There is a link to the Pubmatic page on this Wikipedia list of advertising technology companies.)
  48. 'quantserve.com' (a San Francisco company)
  49. 'richrelevance.com' (a San Francisco company)
  50. 'scene7.com' (a media software company headquarted in San Francisco ; owned by Adobe Systems)
  51. 'scorecardresearch.com' (owned by comScore, a Virginia company)
  52. 'servebom.com' (another Amazon company)
  53. 'sharethis.com' ("can be deployed on any site to ... track the sharing of content" ; started by Dr. Goldberg of the University of Illinois ; headquarters in San Francisco and Cincinnati)
  54. 'shoprunner.com' (a shopping site with "a seasoned team of internet and ecommerce professionals based in San Francisco, New York, and Philadelphia")
  55. 'skimresources.com' (another Amazon company)
  56. 'stumbleupon.com' (founded in Canada, later based in San Francisco)
  57. 'tapad.com' (headquarters in New York City)
  58. a 'tiqcdn.com' hostname (tags.tiqcdn.com) translated (via 'ping') to an 'edgecastcdn.net' hostname. (Edgecast has headquarters in Santa Monica, California, and was acquired by Verizon in 2013.)
  59. 'toptenreviews.com' (a website owned by Purch, headquartered in Utah)
  60. 'trafficjunky.net' (an ad network owned by 'MindGeek' of Luxemburg)
  61. 'truste.com' ("allows companies to safely collect and use customer data to power their business" --- Safe for whom? ; a San Francisco company)
  62. 'typekit.net' (an Adobe font service)
  63. 'vibrant.com' (associated with Cloudflare, above - a San Francisco company)
  64. 'viglink.com' ("outbound traffic monetization service", a San Francisco company)
  65. 'voicefive.com' (a market research company ; uses cookies 'in support of survey efforts' ; a subsidiary of analytics company ComScore Networks. It began in the year 2000 in Reston, Virginia.)
  66. 'webcollage.com' (a 'syndicator' of web content)
  67. 'yieldmo.com' (a New York City company)
  68. 'ytimg.com' (a YouTube company, and thus a Google company)
  69. 'zedo.com' (a San Francisco company ; "Zedo's servers send advertisements to users' browsers. Zedo uses an HTTP cookie to track users' browsing history resulting in targeted pop-up ad and pop-under ads. The cookie is often flagged by spyware and adware removal programs.")
  70. 'zendesk.com' (a San Francisco company)
  71. 'zergnet.com' (a company backed by Mark Cuban)
  72. 'zopim.com' (a Singapore company (?) ; taken over by Zendesk, above ; Royston Tay, a graduate of Hwa Chong Institute, Singapore, in 2000, was CEO and co-founder)

This list is just 'the tip of the iceberg'. This is just a sampling of less-than-useless-to-me 3rd-parties that I have discovered so far in web pages I have visited. And there is another one of these companies born (funded by venture capitalists) every day.

Note that the list of 'big dogs' acquiring these 'internet ruiners' is quite disgusting --- in alphabetical order: Adobe, Amazon, Google/YouTube, Oracle, Verizon, and more.

There is no doubt in my mind that Intel, HP, Dell, Lenovo, Cisco, Netgear, Motorola, AT&T, Sprint, Apple, Microsoft, semi-conductor manufacturers, and others are more or less directly involved in 'CDN' development --- or at least approve of it (and/or don't want to expose it 'to the light of day') because it is good for their business --- for example, good for selling more powerful computers (and/or routers) to people who think that having a faster processor and more memory is going to somehow deal with what is mostly a network latency (waiting for a response) issue.

The 'SaaD' 'CDN' people of the world rank somewhere within the above list of classes of people on the 'disgusting and do-not-deserve-to-live-on-this-planet' ranking scale.

The CEO's of these 'CDN' companies --- and the venture capitalists who support them while these company's salaries continue to outpace their revenues --- should get a soul and find another line of work. They are ruining the Internet. If they can't find gainful employment in a more socially-friendly job, they should do everyone a favor and simply die.

These 'monetizing' people can't seem to understand that it is way more than 'impolite' to shove ads and other crap in people's faces --- and to bog down their computing devices and networks --- without even offering their 'monetizing targets' an option (like a link on a web page with a brief explanation of what is being offered). Their techniques border on criminality. They steal peoples' time and their computing resources --- and run-up their cell phone bills. The victims' time is money --- and their cell phone bills are certainly money. The victims should have a legal basis to sue to get their time-equals-money and phone-bill-money back.

There are strong similarities of 'SaaD' people with the horribly anti-social classes of people listed above --- especially with 'investment scammers' --- as these 'SaaD' 'CDN' people desperately seek ways to 'monetize' the Internet --- somewhat like 'investment scammers' seek ways to 'super-monetize' the investment business, which is already heavily monetized. (The investment business is money looking for more money.)

    I should point out that the 'CDN' companies are the enablers (or sources) of most of this network latency --- but it is really the customers of the CDN companies (and the web page designers of those customers) that are responsible for a major part of the problem. CDN-customers --- such as owners of news sites, shopping sites, and tech-info sites --- are designing their pages such that they do not give the web site visitors any options to avoid the horrible slow-downs.


Suggested laws :   (and punishments)

These people are ruining the internet. There should be laws to rein in these cretins. For example, web sites should be required to put a '3rd Party Javascripts Opt-In' button on every web page that contains javascripts that connect to 3rd-party ('external') companies.

The javascripts are only executed if 'OptIn' is chosen by the user. There is no single-OptIn-for-all-time. Each time a person 'visits' the page, they are to be offered the 'OptIn' button. However, an OptOut-for-all-time option would be desirable --- like the national do-not-call list.

There should be no 'you-have-to-Opt-Out' nonsense that is hidden in small print someplace. We get more than enough of that 'OptOut' nonsense. Namely, we are initially opted-in --- unbeknownst to us --- by our banks, money lenders (userers), investment companies, credit card companies, insurance companies, telephone companies, Google, Facebook, and the like.

In summary, we should be provided an 'Opt-In' button (on each 'external-Javascript-page' that we visit) --- and, in an ideal world, there should be an 'OptOut-for-all-time' facility.

    There is to be no 'settlements without admission of guilt' nonsense. Penalty for first offense (omission of an Opt-In button on a page) is the CEO or CEO's of the offending company or companies serving a week in jail. (No finger pointing. Send them all to jail.)

    Second offense: one year in jail. Third offense: Ten years in jail. Fourth offense: life in prison, surfing the internet --- enduring thousands and thousands of unwanted, useless, inapplicable (does-not-apply-to-me/you), product-never-to-be-used-by-me/you ads --- and unrequested popups and unrequested video/audio.




For some opinions in the same vein as I have expressed on this page, see this text version of a 2015 October talk on Web Obesity, by Maciej Ceglowski. He injects some humor along with much disgust over how web sites are composed these days (circa 2015). An excerpt that pretty much sums up:

"Here is the web pyramid as we observe it in the wild:

  • A base layer of HTML
  • A huge pile of crap
  • On top of it all, a whole mess of surveillance scripts."

and ...

"... it's not just videos and banner ads, but file after file of javascript."

Bottom of the page on Web Browsing - Blocking Connections to Performance-Degrading '3rd-Party' Internet Hosts.

To return to a previously visited web page location, click on the
Back button of your web browser a sufficient number of times.
OR, use the History-list option of your web browser.
OR ...

< Go to Top of Page, above. >

Page was created 2015 Jan 30. Page was changed somewhat 2015 Sep 30.
Page was changed 2015 Dec 06. (Added about 4 'ruiners of the internet'.) Page was changed 2016 Jan 10. (Added a link on 'web obesity'.)

Another example of looking for 'offending' Javascripts.

Following are three images of the 'Links' panel of the
'Page Info' window of the Seamonkey web browser --- showing
the top, middle, and bottom of a 'duckduckgo.com'
web-search-results web page. See comments below each image.


Note that there are about 8 javascripts at the top of this 'Links' list,
but, at least, they are all fetched from the same host that I am visiting,
NOT from some '3rd party' hostnames. It is unlikely that 'duckduckgo.com' is going
to slow down their search results web pages by allowing a '3rd party' to
possibly 'hang-up' the 'duckduckgo' search results display.


Note that, here in the middle of this extract from the HTML code of
the web-search-results page, there are lots of 'Anchor' statements,
but no calls to Javascripts. This is typical of most web pages.
Most of the Javascript calls are at the top and bottom of the HTML code.
Usually the Javascript in the middle of the page, if any, is
'inline' code, being executed from 'this page' at 'this site'.


Note that there is a javascript at the bottom of this 'Links' list,
but, at least, it is fetched from the same host that I am visiting,
NOT from some '3rd party' hostname. Like with the scripts at the top
of the HTML code, it is unlikely that 'duckduckgo.com' is going to
slow down their search results web pages by allowing a '3rd party' to
possibly 'hang-up' the 'duckduckgo' search results display.

This is not to say that 'duckduckgo' is not doing some extra processing ---
such as collecting information on your web searches (for internal use, say)
--- but, at least, if they are doing 'extra' processing, it is
probably all 'localized' and relatively fast.

By the way, if you look at the 'Links' list of this 'host blocking' web page
(the page you are reading right now), you will see that there is nothing but
'Anchor' in the 'Type' column --- no 'Script' --- not even a 'Stylesheet'
or 'Related Item' or 'Form Submission'.

'Anchor' statments are 'nice' in the sense that the user has to click on
a 'link' in the web page before the web browser will take you to the 'location'
that you see in the 'Address' column. IOW, the user has the power to opt-in to an anchor
--- like the 'IOW' anchor at the beginning of this sentence.

'Anchor' statments are also 'nice' in the sense that you can see the hostname
of the 'link'. When I move the mouse cursor over the 'link', I can see the
hostname and web-page filename that the link will take me to --- in the
'status-line' at the bottom of my browser window.

Bottom Line:
Javascript, in the wrong hands, can be like a burglar --- entering your
home (computer) unbeknownst to you and rifling through your belongings.