11 years ago
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.
11 years ago
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 :)
Created attachment 240795 [details] [diff] [review] preliminary patch 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).
11 years ago
Oops, there's superfluous comments in there that I'll wack in the final patch.
Created attachment 240854 [details] [diff] [review] patch for checkin (spurious comments removed)
October is bug 355073.
Checked in on trunk and 1.8branch.
1.8.0 fix is in bug 359557