Omnibus ad-blocking bug for June/July 2008

RESOLVED FIXED

Status

RESOLVED FIXED
11 years ago
11 years ago

People

(Reporter: alqahira, Assigned: alqahira)

Tracking

({fixed1.8.1.17})

unspecified
All
macOS
fixed1.8.1.17
Bug Flags:
camino1.6.4 +

Details

Attachments

(1 attachment)

Here an ad, there an ad, everywhere an ad-ad…
New Flash ads on freep.com from adtechus.com:

http://www.freep.com/apps/pbcs.dll/article?AID=/20080611/SPORTS03/80611062/1118/rss

Ad coming from:

http://aka-cdn-ns.adtechus.com/apps/369/Ad50545St3Sz154Sq208814V0Id3/160x600_Detroit.swf?targetTAG =_blank&clickTarget=_blank&athTAG=http%3A//aka-c dn-ns.adtechus.com/apps/369/Ad50545St3Sz154Sq208814V0Id3&closeTAG=javascript%3AcloseAdLayer215373%28%29&openTAG=javascript%3AopenAdLayer215373%28%29&expandTAG=javascript%3Aexpand215373%28%29&coll apseTAG=javascript%3Acollapse215373%28%29&clickta rget=_blank&clickTarget=_blank&clickTARGET=_blank&CURRENTDOMAIN=www.freep.com

I suspect we could, in theory, block the entire adtechus.com domain, although I'm not sure we want to be that aggressive. (The alternative may be to play whack-a-mole with the many adtechus.com ad servers.)

cl
Hardware: Macintosh → All
Movies not visible on 
http://www.apple.com/ipodtouch/ads/

They are wrapped in a div[id="ad"]

That one was added in bug 387424, if I'm not wrong.
(In reply to comment #3)
> Movies not visible on 
> http://www.apple.com/ipodtouch/ads/
> 
> They are wrapped in a div[id="ad"]

Fun :P  We can add that to our existing Apple exception, I guess.
(In reply to comment #4)
> (In reply to comment #3)
> > Movies not visible on 
> > http://www.apple.com/ipodtouch/ads/
> > 
> > They are wrapped in a div[id="ad"]
> 
> Fun :P  We can add that to our existing Apple exception, I guess.

Given that it's Apple, we might want to cherry-pick that rule for 1.6.2.
(In reply to comment #5)

> Given that it's Apple, we might want to cherry-pick that rule for 1.6.2.
> 

I filed bug 439793 for that one.

I cross-landed bug bug 439793 for comment 3-6 so we wouldn't be in a weird position two months hence trying to figure out what needed to land on branch for 1.6.3.
Ads on sltrib.com, for example:

http://www.sltrib.com/news/ci_9714554 (the "improve your credit" Flash skyscraper on the right)

Coming from 

<iframe src="http://preview.leadmediapartners.com/nac/tribune/education/pilot_ad.html" scrolling="no" width="160" height="600" frameborder="0"></iframe>
Summary: Omnibus ad-blocking bug for June 2008 → Omnibus ad-blocking bug for June/July 2008
Lots of ads on this article

http://www.herald-dispatch.com/sports/x1103451892/Rodriguez-deal-leaves-funny-smell-in-Michigan

pretty much all coming from crow.herald-dispatch.com or media.herald-dispatch.com/AdList/ .
Text ads on IMDB in a "sponsored links" block coming from

<iframe src="http://content.pulse360.com/C6C7561A-492E-11DD-9179-2C743BF8694A" width="410" height="245" frameborder="0" scrolling="no"></iframe>

Example on

http://www.imdb.com/name/nm2105255/bio
(random) ads on the NYT
http://www.nytimes.com/2008/07/15/opinion/15brown.html?_r=1&oref=slogin

The link is pointing to 
http://www.nytimes.com/adx/bin/adx_click.html?
image comes from
http://graphics8.nytimes.com/adx/images/ADS

nested in div[id="adxLeaderboard"] (masthead) and div[id="adxBigAd"] (sidebar)
We block Flash and iframes from trafficmp.com, but not images; I've seen a few of them sneaking by.
On http://news.cnet.com/8301-13509_3-9984637-20.html?hhTest=1

iframe[src*="bwp.cnet.com"]

(we already block the versiontracker and macfixit versions of this ad-frame server)
Assignee: nobody → alqahira
(In reply to comment #1)
> New Flash ads on freep.com from adtechus.com:

> I suspect we could, in theory, block the entire adtechus.com domain, although
> I'm not sure we want to be that aggressive. (The alternative may be to play
> whack-a-mole with the many adtechus.com ad servers.)

I think we'll just whack the whole thing at once; adding that specific server is ugly.

 (In reply to comment #2)
> Ads on Hulu.com:

div[id^="banner-ad"] gets that.

(In reply to comment #9)

> pretty much all coming from crow.herald-dispatch.com or
> media.herald-dispatch.com/AdList/ .

With all due respect to the good people of Huntington and members of the Thundering Herd, I can't see blocking something as site-specific as foo.herald-dispatch.com, and there's nothing in the ad-rotator url that seems blockable, either.  We can block about half of the ads there with rules that are more generic (could apply widely), but this half will need to be custom userContent-type rules.

(In reply to comment #11)
> (random) ads on the NYT

> nested in div[id="adxLeaderboard"] (masthead) and div[id="adxBigAd"] (sidebar)

I made those ^ rules to catch the "adxBigAd2" and friends id variants.
Status: NEW → ASSIGNED
Created attachment 332298 [details] [diff] [review]
Jun-Jul Omnibus ads

This takes care of everything in this bug and philippe's rule from bug 436766 (with the one exception mentioned in comment 14).
Attachment #332298 - Flags: superreview?(sfraser_bugs)

Comment 16

11 years ago
Comment on attachment 332298 [details] [diff] [review]
Jun-Jul Omnibus ads

You should probably find someone else to review these next time.
Attachment #332298 - Flags: superreview?(sfraser_bugs) → superreview+
Landed on cvs trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Landed on the MOZILLA_1_8_BRANCH in advance of 1.6.4.
Flags: camino1.6.4? → camino1.6.4+
Keywords: fixed1.8.1.17
You need to log in before you can comment on or make changes to this bug.