Closed Bug 597808 Opened 15 years ago Closed 14 years ago

Omnibus ad-blocking bug for October/November/December 2010 & January/February 2011

Categories

(Camino Graveyard :: Annoyance Blocking, defect)

Product:
Camino Graveyard
Component:
Annoyance Blocking
Platform:
All
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: alqahira, Assigned: alqahira)

References

Details

(Whiteboard: [camino-2.0.8])

Attachments

(1 file)

Omniblocking!
11.66 KB, patch
phiw2
: review+
stuart.morgan+bugzilla
: superreview+
Details | Diff | Splinter Review
Here lies Overdone Internet Advertising, the scourge of the web.
On http://www.nytimes.com/slideshow/2010/10/05/sports/hockey/SPTSSWEATERS-5.html <div id="BigAdSlideshow" class="bigAd">
Summary: Omnibus ad-blocking bug for September/October 2010 → Omnibus ad-blocking bug for October 2010
I still see some ads on Facebook : div[class^="fbEmu"]
(In reply to comment #3) > I still see some ads on Facebook : > div[class^="fbEmu"] I'm not sure that is distinctive enough to use as a rule :(
I've been using this rule for a few days (with @-moz-document domain(facebook.com)) and I haven't had any false positive. But I'll try to find a more specific rule.
div[id="home_sponsor_nile"] seems to work too (and it even hides the "Commercial links" header).
Hum, on event pages, div[class^="fbEmu"] seems to be the only rule that hides ads but not legitimates related pages. (But, as I said "home_sponsor_nile" works fine for the homepage.)
Scattered around on http://www.japantimes.co.jp/ small image ads: (sample) <div id="PhotoNewsAd"> <a target="_blank" href="http://www.japantimes.co.jp/ads/cnt/?to=http://spelling-bee.japantimes.co.jp/&ads=a4"> <img alt="Spelling Bee" src="/images_jtads/JTO1.jpg"/> </a> </div> a[href*="/ads/"] img and text ads (e.g. next to the search field): div[class^="ad_"] (not sure yet if this is a safe selector, though)
http://www.fredericknewspost.com/sections/news/display.htm?StoryID=111273 has ads all over the place. src*="_adsystem" will probably take care of it. cl
On http://www.marketwatch.com/ <div id="specialadfeatures" class="block"> The following ad_blocking.css blocks the "SPECIAL ADVERTISING FEATURES": div[id="specialadfeatures"],
On http://online.wsj.com/home-page <div class="adSummary offers"> All the ads on this page have (at least) the div class="adSummary", but class="adSummary offers" (the "OFFERS" banner ads at the bottom of the page) was the only one not blocked. The following ad_blocking.css blocks the "OFFERS" ads: div[class^="adSummary"], For comparison, here are the other (successfully blocked) "adSummary" divs from this page: <div class="adSummary advertisement" > <div class="adSummary msnlinks"> <div class="adSummary partnerCenter"> <div class="adSummary specialAdvertising">
On http://www.bing.com/search?q=coupons Header text ads: <div class="sb_adsWv2"> Footer text ads: <div class="sb_adsWv2 sb_adsW2v2"> Right column text ads: <div class="sb_adsNv2"> An aggressive CSS rule to match these ads might be: div[class^="sb_ads"]
On http://www.google.com/search?q=coupons Header text ads: <div id="tads" class="c wads"> Bottom text ads: <div id="tadsb" class="c wads"> But sometimes the class="wads" without "c ", so a minimal rule might be: div[id^="tads"][class$="wads"],
On http://movies.nytimes.com/pages/movies/index.html <div class="adHeader"> <div class="bigAd"> <div class="cColumn-TextAdsBox"> <div class="cColumn-TextAdsLeft"> <div class="cColumn-TextAd"> div[class="adHeader"], div[class="bigAd"], div[class="cColumn-TextAdsBox"],
http://al3x.net/ <div id="fusionad"> <span class="fusionentire">
On http://www.linuxforums.org/forum/ Multiple banner ads and a huge floating ad. They all have: <div id="beacon_SOMERANDOMSTRING"> where "SOMERANDOMSTRING" is something like "beacon_bdb194a074" and is unique for each ad on the page.
On http://www.linkedin.com/in/samuelsidler <iframe id="csp-ad" src="http://www.linkedin.com/csp/ads?f=f300x250&c=-134 02012&p=1&r=817395605">
Summary: Omnibus ad-blocking bug for October 2010 → Omnibus ad-blocking bug for October/November 2010
Step through the photo slideshow pages on http://s762.photobucket.com/albums/xx269/malonestahoecabin/ Most ads are blocked, but some random ads are shown on the top banner ad or the right column. * Top banner ads' div class and id: <div class=" headerAd"> (note the space character before headerAd!) <div id="bannerAd"> * Right column ads' div id: <div id="containerSqAd"> but sometimes: <div id="containerMredAd">
On http://www.google.com/search?q=camino, right column ads are back! (at least sometimes): div#rhs>div#rhs_block We can also add the table#mbEnd there if needed.
Seen on http://www.lemonde.fr/ - and I think on elpais.com (saw it flashing by in the statusbar) : SWF from elstatic.weborama.fr/adperf change embed[type="application/x-shockwave-flash"][src*="l3static.weborama.fr/adperf"], to embed[type="application/x-shockwave-flash"][src*="static.weborama.fr/adperf"],
MSNBC ads: Sidebar ad on: http://www.msnbc.msn.com/id/40745343/ns/technology_and_science-innovation/ div[class="ad adX2 matched"], Footer ads on: http://today.msnbc.msn.com/id/40749607/ns/politics-more_politics/ div[class="ad adSI matched"], div[id="adSlice"], div[class="ad adX1"], div[class="ad textads matched"],
The Apple.com front page has a hole… one of the 4 boxes under the main image is missing: a href="/iphone/gallery/ads.html" position="3" onclick="s_objectID="http://www.apple.com/iphone/gallery/ads.html_1";return this.s_oc?this.s_oc(e):true" add in the apple whitelist: a:link[href*="ads."] img,
On http://mikecanex.wordpress.com/2010/11/07/the-photo-foretelling-apples-doom/ div[class="adcode"] I'm also seeing a few sites that are using div[class*="googleAds"]; our current rule is div[class*="googleads"], and CSS parsing has been case-specific since Gecko 1.9, so we should probably add the camelCaps version.
Summary: Omnibus ad-blocking bug for October/November 2010 → Omnibus ad-blocking bug for October/November/December 2010
(In reply to comment #25) > Seen on http://www.lemonde.fr/ - and I think on elpais.com (saw it flashing by > in the statusbar) : > SWF from elstatic.weborama.fr/adperf and when Flash is not available, I get animated images :-( img src="http://elstatic.weborama.fr/adperf/ blocking on img[src*="static.weborama.fr/adperf/"] ---- Randomly seen on Salon.com, a black bar that is part of an overlay layer containing ads (ads are blocked but that black bar doesn't close) --> div#videoAdPlayer
On ainonline.com: div[id*="dhtml_advertisement"] (There's also a div with id="dhtml_advertisement_screen" if we'd rather use an exact-matching rule.) We block the ad itself, but not the JS-triggered overlay, similar to the one in comment 29.
On glennbeck.com: div id="adsTop" class="ads clearfix" and div class="ad dart-ad minibar widget widget-container" These rules would match, but they might be too wide a net: div[class^="ad "], div[class^="ads "]
Seen on http://www.spiegel.de/international/ (top of page) <a target="_blank" href="http://atemda.com/ClickThrough.ashx?ad2vps=mxfIr6e0K2CQ7H11xWnfUNRoSOPtbDNyxnNQrABoo4uInm03TosdhpIdRQW7qAgBA3pe%2f%2b9U9Yf2dzFZqqlH2w%3d%3d"> <img width="728" height="90" border="0" src="http://admeta.vo.llnwd.net/e1/static/ad2/1937/1146/1e1ec2b868fd4099bca5de0e7fe22476.gif"/> </a> img[src*="/ad2/"] deals with it or a:link[href*="atemda.com"] img (with Flash disabled)
On http://www.ripoffreport.com/ Many ads on the right column have these div class properties: div[class="ad_framed"], div[class="ad_framed_promos"], div[class="ads_left"], div[class="ads_right"], div[class="bannerAd"], div[class="bannerAd alignCenter"], div[class="boxAd"], div[class="miniAdContainer"], But these rules could be simplified something like to: div[class^="ad_"], div[class^="ads_"], div[class^="bannerAd"], div[class="boxAd"], div[class="miniAdContainer"],
(In reply to comment #5) > I've been using this rule for a few days (with @-moz-document > domain(facebook.com)) and I haven't had any false positive. > But I'll try to find a more specific rule. I have been using @-moz-document domain(facebook.com) { .fbEmuEgoUnitFirst, .fbEmuEgoUnit{ display: none !important } } for months now without any false positive.
I've only recently started running with ad-blocker on, so apologies if I'm doing something wrong or have misunderstood something. On gamespot.com, some but not all (Flash) videos fail to display with ad-blocking on. I am not blocking Flash, and I tested with a fresh profile. Here are two examples where they don't: http://www.gamespot.com/pc/action/alice/video/6275871/alice-madness-returns-teaser-trailer http://www.gamespot.com/wii/action/legostarwarsiiitheclonewars/video/6298319/lego-star-wars-iii-the-clone-wars-launch-trailer But here's an example where it does (in case it's useful?) http://www.gamespot.com/showcases/fable3-lc
Found an ad we don't seem to be blocking with a recent nightly (Version 2.1a2pre (1.9.2.15pre 20110222001022)): URL: http://www.f1fanatic.co.uk/2011/03/03/exploded-f1-model-mercedes-benz-world/olympus-digital-camera-15/ Ad markup: <a target="_blank" href="http://www.fightglobalwarming.com"><img height="90" width="728" border="0" src="http://media.contextweb.com/creatives/defaults/adc_gw_bulb_728x90.gif"></a> <iframe scrolling="no" height="1" frameborder="0" width="1" allowtransparency="true" marginwidth="0" marginheight="0" src="http://bh.contextweb.com/bh/drts?Rand=1863805581"></iframe> <div style="display: none; width: 0pt; height: 0pt;"><iframe scrolling="NO" height="0" frameborder="0" width="0" allowtransparency="true" marginheight="0" marginwidth="0" src="http://pixel.quantserve.com/pixel/p-01-0VIaSjnOLg.gif?tags=CONTEXTWEB.,527878,749,996,,,728X90"></iframe></div>
On: http://www.mmorpg.com/showFeature.cfm/feature/5029/General-The-Way-Back-Machine-WoWs-First-Impressions.html Intermittent (Battlestar Galactia game) banner ad: object id="ad_banner_example" Intermittent werewolf article ad: div class="padd_5 center admarker" and div id="contentinlineAd"
Seen on http://search.japantimes.co.jp/ (random) <iframe width="468" scrolling="no" height="60" frameborder="0" allowtransparency="true" marginwidth="0" marginheight="0" vspace="0" hspace="0" noresize="" src="http://as.sr.impact-ad.jp/hserver/acc_random=36490120/SITE=JAPANTIMES.RB/AREA=NEWS/AAMSZ=REGULAR/OENCJP=SJIS/GENERIC=JAPANTIMES.RB/AAMGNRC1=NEWS/AAMGNRC2=REGULAR/AAMGNRC3=468/AAMGNRC4=60/LIMITOFROTA=5/DUR=30000/"/> --> iframe[src*="impact-ad.jp"] we already block flash and images from impact-ad.jp
Microsoft cloud ads on Gmail, below the mail body: div.z0DeRc (in our gmail @-moz-document block).
Attached patch Omniblocking! — — Splinter Review
(In reply to comment #14) > On > http://www.google.com/search?q=coupons > > But sometimes the class="wads" without "c ", so a minimal rule might be: > > div[id^="tads"][class$="wads"], Apparently they've now dropped the "wads" class entirely, so I've adapted that rule. div[id^="tads"][class="c"], should cover the new top blocks (comment 23 should get the side ones). (In reply to comment #17) > On > http://community.nytimes.com/comments/www.nytimes.com/2010/10/20/opinion/20dowd.html > > <div class="remoteAds"> Those seem to be, despite the name, internal links (e.g., to the travel section), so I don't think we should block them. (In reply to comment #30) > On ainonline.com: > > div[id*="dhtml_advertisement"] > > We block the ad itself, but not the JS-triggered overlay, similar to the one You'll have to counteract the JS overlay's suppression of the body's scrollbars yourself: @-moz-document domain(ainonline.com) { body {overflow: auto !important} } (Note that I don't expect this to be an issue on other sites where that rule may match, if any; if it is, we can go back to not blocking it or some other fix, as we've done for other nasty overlays that use JS to break scrolling.) With those caveats, this fixes everything from this bug and bug 636238. Since there are so many rules this time (oops!) and cpeterso provided a bunch that I took wholesale, and also since I didn't poke phiw about most of the rules while developing this patch, I'm going to run it through him for review first ;)
Assignee: nobody → alqahira
Status: NEW → ASSIGNED
Attachment #518997 - Flags: review?(phiw)
Comment on attachment 518997 [details] [diff] [review] Omniblocking! Looks good. I'm slightly worried about div[class="adHeader"] in comment 15 and div[id="SponLink"] in comment 16 (esp as I don't see that one on my side), but we can give them a try, I guess.
Attachment #518997 - Flags: superreview?(stuart.morgan+bugzilla)
Attachment #518997 - Flags: review?(phiw)
Attachment #518997 - Flags: review+
Comment on attachment 518997 [details] [diff] [review] Omniblocking! >+div[id^="beacon_"], "beacon" is a pretty generic term, thus potentially prone to false-positives. Do we have reason to believe this is an ad on such a large number of websites that it's worth the risk? sr=smorgan otherwise.
Attachment #518997 - Flags: superreview?(stuart.morgan+bugzilla) → superreview+
(In reply to comment #42) > I'm slightly worried about div[class="adHeader"] in comment 15 and > div[id="SponLink"] in comment 16 We have other "sponsored link" constructs already blocked, and given that these tow use exact matches (rather than *), I think we're safe. (In reply to comment #43) > >+div[id^="beacon_"], > > "beacon" is a pretty generic term, thus potentially prone to false-positives. > Do we have reason to believe this is an ad on such a large number of websites > that it's worth the risk? On the web, "beacon" is almost always synonymous with tracking of some sort (i.e., "web beacon"), which type of thing we've blocked before. I think that there's a benefit to blocking it here, and from my perspective ^beacon_* is unlikely to be used for legitimate content.
Per irc, we're going to go ahead with "beacon_" and keep our eyes peeled for any problems. http://hg.mozilla.org/camino/rev/2a65cce782c6
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Flags: camino2.0.7?
Resolution: --- → FIXED
Summary: Omnibus ad-blocking bug for October/November/December 2010 → Omnibus ad-blocking bug for October/November/December 2010 & January/February 2011
I landed these two on the CAMINO_2_0_BRANCH and moved the tag for 2.0.8 to include them, since they've been well-tested by now and they were therefore simple, low-risk fixes from the forgotten-in-the-mayhem "camino-2.0.8?" group.
Flags: camino2.0.8? → camino2.0.8+
Whiteboard: [camino-2.0.8]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: