138362 - PAC: Using PAC for ad-blocking ([e-mail]'s file)

Status: RESOLVED WONTFIX

(Core :: Networking, enhancement)

Description

[Brett Koonce]

I use a proxy configuration script 
(Pref->advanced->proxies->auto config script, type in
http://www-scf.usc.edu/~skoonce/adkill.pac )

To block ads.  A lot of people use these files as well.

So, when loading a webpage that uses, for example, doubleclick.net (see above),
I have to click through a pile of little popup windows that say "The connection
was refused by ad.doubleclick.net".

I don't think this is the same as bug 130077 or 75977, because I actually *want*
these domains to be blocked.

-Brett
RC1, XP

Comment 1

[Brett Koonce]

bug 75977
bug 130077

There you go, now you can click on it. ;-)

-Brett

Comment 2

[benc]

Temporarily "futuring" all PAC&SOCKS bugs to clear new-networking queue.

I will review later. (I promise)

If you object, and can make a case for a mozilla 1.0 fix, please reset milestone
to  "--" or email me.

Comment 3

[Brett Koonce]

A case?

Well, one of the main reasons I'm excited about Mozilla is the proxy auto-config
feature.  IE 5.1 on OSX doesn't have this feature, and I hate manually adding
IP's to my ban list.

This is one of the reasons I was looking forward to switching.

This bug kinda kills that feature.

That being said, this is a fairly trival thing with an easy workaround (don't
use a proxy or just hit okay).

And, seeing as there's other, similar bugs, it might be kind of hard to track
down.  So, in conclusion (hehe) I wouldn't worry about it if there's bigger fish
to fry.

However, a quick-n-dirty fix might be to turn off displaying this alert box if
the domain is doubleclick.com or tribalfusion.net (just add a simple boolean
search).  If that's possible, it might be fairly simple to implement a fix.

And, I just confirmed this on RC1, MacOS9.

-Brett

Comment 4

[Brett Koonce]

And I'll confirm it again under 10.1, RC1.

-Brett

Comment 5

[Brett Koonce]

And, for another arguement for proxy config:
bug 123771 	

-Brett

Comment 6

[benc]

-> NEW: this is a valid problem description.

I'm going to begin enforcing some PAC bug guidelines (that I will publish real
soon...).

summary updated to fit.
--
Brett, please enclose your PAC file as an enclosure, so it's archived.

Here's the answer to your question:

1- PAC sends to Proxy, so the error message being wrong is proxy service's
fault. There is a bug on that.

2- Some people don't like every connection failure to pop up. There is a bug on
that too.

3- PAC was intended to enable connectivity, not function as a filtering
mechanism, so there is no way to send to NULL. I had considered this one
possible feature of what we jokingly call "PAC2", so I'll file a bug on that.
The overall concern is that PAC files would become really huge if used for a
service like this. Many people have reservations about client-side blocking as a
technology, as well as via a PAC implementation.

Comment 7

[Brett Koonce]

Attachment: Adkill.pac (standard .pac adkill file editable .txt)

Well here it is.  It's basically a modification to another person's work
(http://www.schooner.com/~loverso/no-ads/).  I add a couple of domains that
piss me off as well.

Like or not, this 'hack' is here to say.  I use it for three main reasons: a) I
don't like messing about with configuring/seting up a proxy such as
junkbuster/proxminimon/or squid, b) adding ips manually to my machine's banned
list is a PITA/boring/not exactly child's play, and finally (and most
importantly) I use this .pac file on upwards of 10 machines now.  I can modify
my master file on my server and it will propogate itself.

Finally, the main ad domains that cause this are, as I've said before:
tribalfusion.net and doubleclick.com.

-Brett

Comment 8

[Stephen P. Morse]

I agree with chuang here.  Although it is tempting to use pac for ad blocking, 
this is not its intended feature.

But if you really want to do this, schooner describes two other ways to get what 
he calls a black-hole server.  See his comments labelled 2b and 2c in his 
no-ads.pac file.

Marking this as an enhancement request.

Comment 9

[benc]

Brett:

Based on looking at your PAC, it seems like you map the ad hits to "PROXY
localhost:<unused port number>"

This will probably not work at all now, because Darin has fixed the error
dialog, so when you connect to a proxy and it fails, you get an error message.

Using PAC to block ads is outside the intended use of the current version. There
is some consideration for adding such features in the future (by creating a
directive that points to nowhere). 

I do not like it when people hack /etc/hosts either (they file a lot of bogus
bugs with us), but what we need is a real ad blocking feature, built off
extensions of image blocking.