Hi Matthew,

On 2002.09.25_09:39:35_+0000, Matthew Schalit wrote:
> I've seen a lot of that  www.blahblahblah.org/ads/* too.  In fact, I
> get more ads from creative urls than from doubleclick.
> 

That's why I mention the other options of ad filtering on the previous
reply.

> The problem with filtering ads is that some big money companies that
> have a lot invested in their site, like financial ones, tie the
> loading of their pages into the successful loading of the ads and the
> responses the adserver gives.  So when blocking doubleclick, sometimes
> your page will wait minutes to timeout and finish loading, if it even
> does.

Can you explain the methods they used to enforce this?  I haven't seen
anything about this so far. When using the dnscache method, the address
of doubleclick is directed to localhost, which hopefully will reject the
packets instead of dropping them. This will result in immediate
"Connection refused" reply.  For redirector, usually an administrator
will redirect the URLs to local server, fetching a tiny 1x1 pixel blank
image. It also takes a very short time.

My guess is they are using JavaScript or anything of a kind to check
that. Can you confirm that and explain a bit?

> The users will function best if they can have some control of when/who
> to block ads from.  If they can't adjust the rules that apply to them,
> a diverse user base will revolt against the best ad blocking software,
> perhaps.  Donuts in the morning and pizza later on has been known to
> quash the rebellion.

Agree. In a diverse user base environment, choosing this is sometimes
not an option. If the environment is at a big company, the policy have
to decide about this. If the policy decided to be flexible, there would
be some methods of authentication to know that an authenticated user
preferences. This has to be done because the preferences will always be
on the server side. Presuming a client browser will never have an option
to disable banner. I may be wrong on this presumption.

Now, if this flexibility would be implemented on an ISP, where you can't
have strict policy, it is much more difficult to enforce this. It is
absolutely not an option to have a user authenticated before he/she can
browse. Not the mention the trouble and delay introduced when
implementing one on a cache proxy.
 
> What I've found makes my surfing experience reasonably calm is
> disabling javascript from opening windows I don't request, using
> Mozilla's preferences, Advanced --> Windows and Scripting.

Opera's preferences on JavaScript popup: 1. Accept popup.  2. Reject
popup.  3. Open popup window in the background.

Easily switching between 2 and 3 would be very nice. Not that I wanted
some ad, but sometimes a popup is really not an ad.

> Or an .edu.
>

Yes, I wonder how I can miss this one. *g*
 
> And on the subject of dnscache and loading it up, people often wonder
> about extending the TTL, time to live, of the cached data so that the
> entry is available for longer.  How bout a week?  Well it turns out to
> be a bad idea apparently, because the whole DNS scheme is centered
> around timeouts on the order of a 1/2 hour, at least the responses you
> get from various servers are.  It's rare to see it over 3hrs.  Now you
> can set a TTL on your cache, but there's TTLs on each entry that came
> with the entry, and the TTL that came with the entry takes precedent
> over the global value you can set on your cache.  Your 1 week TTL you
> placed on the cache will never get a chance to get used, becuase the
> 1/2 hr - 3 hr TTL entry on each data will expire them long before a
> week ever rolls around.  It's better this way so that when a server at
> some ip address goes down, it's dns entry can be changed to point to a
> new ip address, and basically nobody will cache the old address for
> more than 3 hrs.  But you guys knew that already, I'm sure.

TTL is not an issue for the OP. Because the dnscache will always consult
local and private content DNS server. When TLL is short, the caching dns
will query the local content dns again. Or am I missing your point here?

> And finally, you can increase the size of your dnscache to greater
> than the 2 MB that's set aside for it in your conf files.  I still
> haven't found a way to determine my cache size on the fly.  So I never
> know if it's near 2MB.  If I was handling a busy site, it might be
> something to think about.  Those djbutils become more useful then.

You can adjust dnscache cache on the fly: 

http://cr.yp.to/djbdns/faq/cachex.html#cachesize

To determine your optimal cache size while running, you have to monitor
your cache motion:

http://cr.yp.to/djbdns/faq/cachex.html#cachemotion

> Regards, Matthew
> 

-- 
H. D. Lee


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html

Reply via email to