Web Browsing
Performance
Blocking Connections to
Performance-Degrading
'3rd-Party' Internet Hosts
Web Browsing
|
|
! Note !
A few more notes and links may be added,
if/when I re-visit this page in the future.
Sections of this page, below:
|
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:
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
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
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 of Others 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:
It was not easy to find answers to these questions via web searches. These questions are dealt with in sections below.
Question-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 (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 (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: 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'.
Unfortunately, the 'hosts.deny' and 'hosts.allow' files are
not typically used to block communication to certain hosts
from web browsers because those two files work with a
tcpwrappers
system which is oriented more toward stopping
ssh (login ... *incoming*) attacks. The 'hosts.deny' and
'hosts.allow' files 'apparently' cannot be used to block *outgoing*
TCP communications --- from apps such as web browsers
using the HTTP protocol.
These two files would be a great option, because they
allow for
blocking (or allowing) entire ranges of IP addresses with
a single control statement. (See 'iptables' notes below.)
Question-2: 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: 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:
Question-4: 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.
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
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 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
|
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:
People with corrupted-minds like these 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, in the middle of these horrible-mind-people --- say, between 'predatory priests' and 'spouse beaters' --- 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
which, by the way, are driving up the cellphone bills of millions, if not billions, of people. 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 :
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, Alphabet/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 CEO'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, and an option to opt-out). 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:
and ... "... it's not just videos and banner ads, but file after file of javascript." |
|
For more info : To find more info on 'horribly slow rendering web pages' and 'slow web browsing due to 3rd party hosts' and 'host blocking', you may find it instructive to try WEB SEARCHES on keywords such as |
|
Bottom of this page on 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. >
|
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 essentially nothing but 'Anchor'
in the 'Type' column --- essentially no 'Script' lines
--- and, essentially, 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.