H. D. Lee wrote: > 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.
And they are good options for sure. I think it's a losing battle overall, but some things you mention below certainly help. >>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've not bothered to figure it out, but I suspect javascript as you do. > 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. What mechanism rejects the packets sent to localhost? Don't the packets just hit port 80 which has nothing listening? When I think reject packets, I think reject them at eth1. > 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. That's a neat idea that I've not heard of. I don't understand how it works, but that's ok. I've little interest in web servers at this point. > My guess is they are using JavaScript or anything of a kind to check > that. Can you confirm that and explain a bit? Well, I only know Java2, so I'm not the one to comment on Javascript, but that's usually the coding mechanism used on the web. >>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. In Mozilla, you can right click on an image and ban images from that server. You can institute other simple rules, but I haven't messed with them. > 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. Yes that's a problem on big $$ sites also. I've had them kindly mention that I need to reenable their ability to popup a new window, which is not an ad. Lazy coding on their part? who knows :) >>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? No you have it correct. I was just refering to speeding up your web experience in general when resolving names, not to do with ads. Google one day is google the next. Sourceforge.net is still sourceforge.net the next day. Have to resolve these names constantly is sort of nuts. >>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 Thanks for the links, but I don't have a /service directory, so maybe I need djbutils. Someday :) Matt ------------------------------------------------------- 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
