Closed Bug 351124 Opened 18 years ago Closed 18 years ago

Omnibus ad-blocking bug for September

Categories

(Camino Graveyard :: Annoyance Blocking, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Camino1.5

People

(Reporter: alqahira, Assigned: alqahira, NeedInfo)

References

Details

(Keywords: fixed1.8.1)

Attachments

(1 file, 1 obsolete file)

We need to block iframes with src matching "RealMedia/ads", src matching "precisionclick.com/ad/", and flash coming from precisionclick.com.
(In reply to comment #2)
> We need to block iframes with src matching "RealMedia/ads", src matching
> "precisionclick.com/ad/", and flash coming from precisionclick.com.

Is there anything legitimate from precisionclick that we *shouldn't* be blocking?

cl
(In reply to comment #3)
> Is there anything legitimate from precisionclick that we *shouldn't* be
> blocking?

I think we should attempt to target their ad servers, and not just block everything from their domain.
OK, the flash ads on anandtech.com are bugging me. Let's block this somehow:
http://images.anandtech.com/banners/Biostar/1_T-series125x300_08012.swf
Amazingly annoying ad covers the content here:

http://www.canmag.com/news/4/3/5053

I'm not sure there's anything we can do about it, though.
That's hilarious:
        Hide Advertisement- Internet Explorer
        Hide Advertisment- Firefox
and guess which one works when you click in Camino?

It also has a tracking bug from http://content.ipro.com/images/pixel.gif that we should block, which is also connected with www.spotsitemedia.com.

The floater has id="demodiv" which is a bit too generic to block, unless we use site-specific CSS. I don't think this site warrants it, though.
There's a Flash interstitial in ESPN College Football (and MLB, and NFL) GameCasts that looks blockable, but I can't figure out a URL. Clear your cookies first (as it appears they only show the interstitial once per session or so) to ensure you get the ad.

cl
Further investigation shows the ad to be coming from

adsatt.espn.go.com

a host from which we probably ought to be blocking all content.

cl
Simon, should we tack a license header onto this file in the next update?  Or is this a "trivial, empty, very short or auto-generated file" and therefore exempt?
I think it deserves a license. We've spent much time tuning it.
We're blocking the iTunes button images from this page:
  http://www.itsfreedownloads.com/
The images are at:
  http://ax.phobos.apple.com.edgesuite.net/images/badgeitunes61x15dark.gif
They are wrapped in hrefs like:
  http://click.linksynergy.com/fs-bin/stat?id=...
which is maybe why we block them.
(In reply to comment #12)
> They are wrapped in hrefs like:
>   http://click.linksynergy.com/fs-bin/stat?id=...
> which is maybe why we block them.

How do we differentiate between "good" linksynergy links and "bad" ones?  Or do we simply remove the 
  a:link[href*="linksynergy.com"] img
rule?

Maybe that page is getting revenue from click-throughs on the iTunes buttons. In which case, maybe we should block them :)
Attached patch preliminary patch (obsolete) — Splinter Review
Yeah, linksynergy is some sort of affiliate marketing thing.  I seem to remember a previous issue with either iTunes buttons or linksynergy, but I can't find it now.

Since blocking those images really breaks the function of the page (and it's iTunes, on top of that free iTunes, and not really annoying advertisements at all), I'm tempted to put this rule in the override section despite the fact someone is getting money from people's clicks:

  a:link[href*="linksynergy.com"] img[src*="apple.com"]

The other thorny problem is some Flash ads (including ads that should be blocked by existing embed rules :/) on de.yahoo.com and de.entertainment.yahoo.com (bug 350554 comment 5 and 6).  Because of the way those pages are set up and the urls of the Flash ads
  http://eur.a1.yimg.com/java.europe.yahoo.com/eu/any/foo.swf
without blocking embeds from all of eur.a1.yimg.com (which seems like too generic of a Yahoo media server and might have legit content), the best rule I can manage is what seems to me like a real hack:

  div#ad * object > embed[type="application/x-shockwave-flash"]

If it's too much of a hack, I guess we live with it?

Attached is a preliminary patch (make sure I got all the licensing details right) that addresses everything here, bug 353219, and most of bug 350554 (there are some non-blockable ads on some of those sites).  The 2mdn rules that were removed were duplicates (not sure how that happened).
Attachment #240795 - Flags: superreview?
Attachment #240795 - Flags: superreview? → superreview?(sfraser_bugs)
Oops, there's superfluous comments in there that I'll wack in the final patch.
Target Milestone: --- → Camino1.1
Attachment #240795 - Flags: superreview?(sfraser_bugs) → superreview+
October is bug 355073.
Status: NEW → ASSIGNED
Flags: camino1.0.4?
Whiteboard: [needs checkin]
Checked in on trunk and 1.8branch.
Status: ASSIGNED → RESOLVED
Closed: 18 years ago
Keywords: fixed1.8.1
Resolution: --- → FIXED
Whiteboard: [needs checkin]
1.8.0 fix is in bug 359557
Flags: camino1.0.4? → camino1.0.4+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: