VanguardLH wrote:
> 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.
>

OK.

--
JD..