Hosts vs. Proxomitron

[8192]

Hello all,

I've been using Proxomitron with WinMe and IE6 (on dial up) for the
last few weeks and it works well. The only problem is that Proxo
noticeably slows my browsing down, page loads are slow.

So, I tried installing a Hosts file from :
http://www.mvps.org/winhelp2002/hosts.htm and installed NOHTTPD from:
http://www.cdhk.de/buck/nohttpd/nohttpd.php

Then I disabled active scripting from IE6's security settings. The
result is no popups, no advertising and the browser loads pages fast.

I would still like to use the other features of Proxo. So, instead of
using the Hosts file, is there any way to speed up Proxo with an
optimized configuration file?

[sponge]

On Wed, 17 Sep 2003 15:19:13 GMT, "YoKenny" <YKnot@home.invalid>
wrote:

>sponge wrote:

>> HOSTS will likely slow you down. The files out there today are
about
>> 450k in size, so if you visit a webpage with a dozen off-site
images
>> and scripts, you'll be going through 5.4 megabytes worth of DNS
>> lookups. That'll slow things down.
>
>How do you come up with that figure? DNS lookup are very small
packets
>and if the site is in the HOSTS file then nothing leaves the PC.

It's not the packet size that's the problem. It's the lookups
themselves.

Take a look at Yahoo's homepage, for example. It will load images, ads
and scripts from a number of different sites. Let's say,
ad.doubleclick.net, us.i1.yimg.com, rd.yahoo.com,
adfarm.mediaplex.com, images.x10.com, and a few others.

If none of these in your HOSTS list, then that means your browser's
DNS resolver has to search through the entire list for each domain
name before allowing it to pass. That's 2.25 Mb right there. Of
course, some of these actually are on the HOSTS file blocklist, so the
time will be shorter depending on the location of the entries withing
HOSTS. Even then, though, that's usually still quite substantial since
most entries won't be near the top of the list.

If the looked-up names are cached afterwards, then the lookup time
will shorten in subsequent uses, but that will only happen on the
names being sought and caches do expire. The whole HOSTS file isn't
cached: you'd overflow your cache a couple times over if it tried.

I guess I like Kong because I'm a speed and efficiency freak. I like
to wring as much performance out of a machine as I can while doing
what needs to be done. That's what years of writing assembly-language
programs will do to ya. :-)

Sponge
Sponge's Anti-Spyware Source
www.geocities.com/yosponge

[Jay T. Blocksom]

On 17 Sep 2003 09:34:39 -0700, in <alt.privacy.spyware>, yosponge@yahoo.com
(sponge) wrote:
>
> On Wed, 17 Sep 2003 15:19:13 GMT, "YoKenny" <YKnot@home.invalid>
> wrote:
>
> >sponge wrote:
>
> >> HOSTS will likely slow you down. The files out there today are
> about
> >> 450k in size, so if you visit a webpage with a dozen off-site
> images
> >> and scripts, you'll be going through 5.4 megabytes worth of DNS
> >> lookups. That'll slow things down.
> >
> >How do you come up with that figure? DNS lookup are very small
> packets
> >and if the site is in the HOSTS file then nothing leaves the PC.
>
> It's not the packet size that's the problem. It's the lookups
> themselves.
>
[snip]

But that's just it... If a given machine has an entry in in the local HOSTS
file, then there is *no* DNS lookup for that hostname, ever.

> Take a look at Yahoo's homepage, for example. It will load images, ads
> and scripts from a number of different sites. Let's say,
> ad.doubleclick.net, us.i1.yimg.com, rd.yahoo.com,
> adfarm.mediaplex.com, images.x10.com, and a few others.
>
> If none of these in your HOSTS list, then that means your browser's
> DNS resolver has to search through the entire list for each domain
> name before allowing it to pass.
[snip]

True, but that's much MUCH faster than doing a DNS lookup, at least
presuming a semi-modern and properly configured system.

> Of
> course, some of these actually are on the HOSTS file blocklist, so the
> time will be shorter depending on the location of the entries withing
> HOSTS.
[snip]

It will be shorter, period -- you *do* have your system's disk caching set
up halfway sanely, don't you? (For that matter, at least some versions of
Windows might explicitly hold the HOSTS data in memory anyway... not sure of
this one, but it stands to reason.)

> Even then, though, that's usually still quite substantial since
> most entries won't be near the top of the list.
>
[snip]

Actually, for an even number of entries in the HOSTS file (and ignoring
comment lines), exactly 50% will be nearer to the top of the list than to
the bottom. And vice versa. ;-) (For an odd number of entries, one will
be exactly in the middle.)

> If the looked-up names are cached afterwards, then the lookup time
> will shorten in subsequent uses, but that will only happen on the
> names being sought and caches do expire. The whole HOSTS file isn't
> cached: you'd overflow your cache a couple times over if it tried.
>
[snip]

You are correct that the browser only "remembers" the addresses of those
hostnames it actually looks for; but this has nothing to do with
"overflow[ing] your cache". Most browsers will use a dedicated buffer for
this data, not the "cache". OTOH, if "Browser X" does store this data in
the main cache, you then need only adjust the cache settings within your
browser, if they are inadequate; you said earlier that most of the commonly
distributed HOSTS files are ~450K -- that is *nothing* compared to what any
semi-modern browser is capable of caching.

Having said all this, I would be remiss if I failed to note that the HOSTS
file is really the wrong place to do wholesale blocking (and a perversion of
its intended purpose, for that matter), for several reasons. First, it is
_at_best_ inherently only "half the answer", since the HOSTS file can *only*
influence where your system goes to *ask* for data from certain named
machines; it *cannot* do anthing about data transfers initiated from outside
the local machine. Secondly, and even ignoring the foregoing, the HOSTS
file is a horridly inefficient and labor-intensive way to block entire
networks, subnets and domains, simply because it cannot support entries like
<*.doubleclick.net> -- you need a separate entry for each and every host in
that domain, which means you first must *know* each and every host in that
domain. Got any idea how many entries that would be, *just* to cover
DoubleClick? Phooey! It's FAR easier to just plug:

63.160.54.0./24
63.166.98.0./24
63.168.198.0/25
65.167.64.0./22
128.11.60.64/26
128.11.92.0./24
146.82.220.0./23
198.31.62.0./23
204.178.112.160/27
204.253.104.0./23
206.65.181.96/28
206.65.183.0./24
208.10.202.0./24
208.32.211.0./24
216.73.80.0/20

into your external router/firewall's DENY table, and be done with it.

--

Jay T. Blocksom
--------------------------------
Appropriate Technology, Inc.
usenet01[at]appropriate-tech.net


"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-- Benjamin Franklin, Historical Review of Pennsylvania, 1759.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
NOTE: E-Mail address in "From:" line is INVALID! Remove +SPAMBLOCK to mail.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Unsolicited advertising sent to this E-Mail address is expressly prohibited
under USC Title 47, Section 227. Violators are subject to charge of up to
$1,500 per incident or treble actual costs, whichever is greater.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -