JD wrote:

> I thought I posted this once before but it didn't ever show up so I'll
> try again.
>
> On more than one web page, I can't connect to Live Chat because it goes
> through liveperson.net.
>
> Examples: https://www.1800contacts.com/ Chat with us.
> http://www.iherb.com/info/Contact I don't even see the chat button but
> I think that's a setting in my SeaMonkey prefs that blocks an image of a
> link that is blocked by my HOSTS file.
>
> I see the following entries in my HOSTS file:
>
> 127.0.0.1 sales.liveperson.net #[Tracking.Cookie]
> 127.0.0.1 sec1.liveperson.net
> 127.0.0.1 server.iad.liveperson.net
>
> Is it really necessary to block liveperson.net or is it over-kill?

You see the following because what you omitted to mention is that you
are using someone else's pre-compiled 'hosts' file, like maybe the one
from MVPs. There will be lots in entries in those pre-compiled 'hosts'
files with which you may not agree but are you really going to review
the thousands upon thousands of entries in those 'hosts' files?

Because you didn't compile the list in the 'hosts' file, because they
must specify hostnames and not just domains (and domains can change
hostnames and even accept any hostname to resolve to an internal host
which means you'll never have a complete list for that domain), and
because there is no easy means within the web browser to switch on/off
the use of the 'hosts' file, it is an overreaching and clumsy approach
to ad/content blocking. If you use an ad-blocker with your web browser
(or IE's Inprivate Filtering feature), you can still review the list of
blocks to determine if you want them plus it's easy to switch on/off the
blocking for when it gets in your way. While I build my own IE8 list
for its Inprivate Filter (since I don't agree with many of the entries
in the pre-compiled 'hosts' file), there is one pre-built list over at
http://www.quero.at/adblock_ie_xml.php. There was another I found in
some forum via a Google search but I don't how often its author
maintains his list. There are also some differences in interpreting how
the entries are to be coded in the XML file. Most users don't
understand regex so they add entries like ".doubleclick.net" which is
incorrect because it will match on "udoubleclick.net" since the period
character means match on any 1 character in that position. You use
"\.doubleclick\.net" to escape the special characters used by regex.

If you don't agree with a block listed in the pre-compiled 'hosts' file,
start to build your own or edit someone else's pre-compiled list you
chose to use.

Personally I see no reason to add hosts into the 'hosts' file just to
block tracking cookies. What web browser nowadays doesn't have
sufficient options to let users configure their web browsers to flush
all cookies on exit from the web browser? If you don't want some site
(you visit later) from tracking where you've been before during a web
browser session, add a toolbar button that exercises your web browser's
purge function. Besides, focusing on tracking cookies does nothing to
prevent tracking by using DOM and local storage available to all newer
web browsers where a site can store info on your host - unless you
disable those features in the web browser (and I do). In fact, you may
need those tracking cookies for a site to function properly since they
use them to monitor your session there and qualify if you can visit
other of their web pages (since Referrer isn't reliable anymore)
although they can also track by using a handle attribute on the web
browser window they set before letting you visit another page that then
inspects that attribute's value.

Blocking tracking cookies is a waste of space in pre-compiled 'hosts'
files and the bloated size means longer to scan through the 'hosts' file
to check if the lookup succeeds there rather than having to do a DNS
lookup. Scanning in linear from top to bottom. No memory copy is saved
to speedup the scan. Everytime there is a hostname to lookup, the web
browser starts at the top of this list, has to parse its way down, and
that takes time. With 'hosts' file reaching many thousands of entries,
this slows the lookup process (not a lot but each scan takes time).

If you're going to use someone else's pre-compiled 'hosts' file then you
are allocating to them the authority of deciding where you can visit or
to where your web browser connects. Extremely few users of pre-compiled
'hosts' files ever review the list to determine if they agree or
disagree with all of the entries.