Closed Bug 140238 Opened 24 years ago Closed 22 years ago

Ability to block banner ads based on image/iframe size

Categories

(Core :: Graphics: Image Blocking, enhancement)

Product:
Core
Component:
Graphics: Image Blocking
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: bamm, Assigned: security-bugs)

References

Details

A pref checkbox to not download any images or iframe content whose size is 468x60 or 234x60 would be very much appreciated. If enabled, Mozilla should just leave a blank space where the image or iframe would have been, so as not to ruin the page layout.
Recommend "Wontfix", images can already be blocked using the "Block images from this server" item in the context menu.
He wants to only block banner-sized images, not all images. But that's exactly what BannerBlind does. http://bannerblind.mozdev.org/ Sweet.
-> image blocking
Assignee: Matti → morse
Component: Browser-General → Image Blocking
QA Contact: imajes-qa → tever
While the "Block Images from this Server" setting is good, it doesn't necessarily conflict with this one. In fact they complement each other. If I enable blocking of all banner size images, I would only have to use "Block Images from this Server" for ads with nonstandard sizes. In addition, this bug also proposes not loading the content of any iframe whose size is 468x60 or 234x60.
Bamm: Not every advertiser adheres to the "468x60" standard. You'd be forever adding new sizes to block.
adding that size directly into a browser would only end up this size to be changed. -> WONTFIX. Bamm: just block the ad-Server to add images - should do the same.
I don't totally understand the last three comments...mozilla ALREADY supports blocking banner-sized images, with a simple one-click installation of the browser extension BannerBlind off of mozdev.
> Not every advertiser adheres to the "468x60" standard. But 80% of them do. While it is true that many ads use different sizes, the converse is not true. All images this size can be safely assumed to be ads. Blocking will significantly reduce their number. > You'd be forever adding new sizes to block. Not as often as you'd be forever adding servers to block. :p > adding that size directly into a browser would only end > up this size to be changed. Not very soon. The 468x60 standard won't go away so fast. If and when it does, I'd have happily used this feature for at least a couple of years already. > just block the ad-Server to add images - should do the same. Although I love the blocking by server feature, they don't do the same. Blocking by size blocks more ads than blocking by server. > mozilla ALREADY supports blocking banner-sized images, with a > simple one-click installation of the browser extension BannerBlind > off of mozdev. Sophisticated users who want to block many image sizes would love BannerBlind. But for most users, blocking the most common size without installing 3rd party software would be just fine. To Everyone: I hope you imagine the impact of this on end users. They would love it as much as they loved the popup blocking. It would be one of those features we can use to talk people into using Mozilla. "Hey, try Mozilla. It has the option to block all banner-sized images, and you can block all popup ads too!" Wouldn't that sound like music to the ears of an IE user? :)
> "Hey, try Mozilla. It has the option to block all banner-sized images, > and you can block all popup ads too!" Put simply, Moz already does that. It has an image-blocker and a popup blocker. Besides, what happens when I use an image for my website that is also the size of a blocked banner ad image? Web developers would be forever ripping their hair out, and you'd have all the dreamweaver-weenies clogging up bugzilla and the newsgroups, saying "It works in IE but not in Moz. Moz sux0rz!!!" I still recommend wontfix.
> Besides, what happens when I use an image for my website > that is also the size of a blocked banner ad image? I only want to block 468x60 and 234x60 images. I don't want to give an option to add new sizes. If they want that, they can get BannerBlind. Any decent webmaster knows that he shouldn't use 468x60 for real images, because they can be mistaken for ads. Reason: people already involuntary filter out any image of that size. If you use that then people will probably just skip over your legitimate graphic. I did that once and got corrected badly. I recommend this size for blocking because it is the size that everybody already recognizes to be an ad. Besides, I am only asking for an *option* that is turned off by default. If a user turns it on then he would know because he turned it on himself. > Put simply, Moz already does that. It has an image-blocker > and a popup blocker. Blocking by size is more intuitive to an end user than blocking by server. Besides, there are hundreds of ad servers around the world and forever adding a server to block isn't appealing to the average user. Blocking sized-based images in one fell swoop is. No need to tell me that Moz already has an image blocker. I already know that. I am just proposing a more efficient and intuitive way to do it. Arachne graphical browser for DOS has this feature and it is a hit among its users.
I think this is a great idea. Omniweb implements a similar feature and its great to use. Another related nice feature is to allowed wild cards in blocked sites, for things like *.ads.* I tried using a firewall to block everything from ad sites, but the configuration tool I use doesn't allow wildcards and I don't know enough to do that sort of thing by hand.
> Blocking by size is more intuitive to an end user than blocking by server. > Besides, there are hundreds of ad servers around the world and forever > adding a server to block isn't appealing to the average user. Blocking > sized-based images in one fell swoop is. Plus some sites serve their own ads (CNN, I think does this) so you can't block their ads. However, for parity, a "block all images this size" would be nice rather than hard-coding some number of sizes into mozilla.
Erm. This sounds very bogus to me. I seriously doubt that among people blocking banner ads, the proportion of people blocking by size is very high; if so, we'd probably be seeing banner ads which vary by one pixel smaller or larger in different dimensions, which is unlikely to blow up layout but will defeat this technique.
The 468x60 and 234x60 sizes are internationally recognized ad sizes. If I would submit a banner to an ad company they would require me to submit this size. If it is off by a pixel, I would be probably asked to fix it first. This size does not just happen to be the most common size, it is an agreed upon standard. Therefore it deserves special mention among sizes to block. Besides, many ads use IFRAME instead of animated gifs, and inside the frame are a combination of HTML, flash, gifs, javascript and even forms. Thus you see ads like "Enter your email address to join" or "Click on the monkey to win".
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
I'm with comment #12, I don't see why implement only 2 sizes if we can have the option for more sizes and customized sizes. A context menuitem with "block images of this size" would be nice too. My suggestion is to change the summary of this bug.
A better summary would be: [RFE] Implement a built in size-based banner blocking system.
Bamm: "Internationally recognized" is meaningless in this context. The current "standard" of image sizes is completely de facto, with no official recognition. Moreover, if the servers of banner ads discover their click-through rate is coming down due to this type of blocking (and they certainly keep abreast of the techniques used by web-washing programs), there is no reason to believe they won't resort to things like 1-pixel changes to get around the blocking; 1 pixel of difference isn't going to have catastrophic effects on the pages incorporating the banner ads. To put it another way: this technique is inherently a very fragile method of discovering and blocking banner ads. There are only so many options we can add to the popup-blocking UI without cluttering it beyond usefulness, and I'd like to see us spend them on the most useful *and* robust methods for doing so.
So far I haven't seen anyone responding to the IFRAME issue I brought up.
Component: Image Blocking → Accessibility APIs
Doesn't the fact that a lot of ad blockers already use image sizes and the ads don't change say something? Possible interpretations: 1) Percentage of people people using ad blockers isn't that large. The same can be said of mozilla. Ad people aren't going to worry about a browser with ~few% market share, ~10% of whose users turn off ads. 2) Changing sizes isn't as simple as you think. Its not just images, but frames, etc that have to follow these sizes, and yes, scaling by a few pixels can screw you up. I'm not sure I'd even use this, but arguing agains someone who might want to do this to avoid starting a (possible) arms race, I just don't understand. Cluttering the menus, now there is an argument I understand.
I still don't understand why BannerBlind, which has every feature thus far requested, is unsatisfactory. Perhaps BannerBlind should be brought into the mozilla core, but the debate hasn't been along those lines, which confuses me. What don't people like about BannerBlind today?
-> Changed summary per Comment #17.
Summary: [RFE] Option to not download any images 468x60 pixels. → [RFE] Implement a built in size-based banner blocking system.
This is stupid! Really - Why would it be preferable to have more bloat built into allready bloated browser, instead of using an existing addon product that does everything that is described here! I personally would advise WONTFIX. (And btw - I don't use BannerBlinds, and I don't intend to - site specific blockikng is quite enough for me. As long as I don't find it useful - i'd be happy to know that this is not included in my browser either!)
Roland: Be calm. Actually, all I imagine is a checkbox in Privacy | Images that says [ ] Do not display banner-sized images. This shouldn't be much bloat shouldn't it? That's why I am just asking a very basic subset of this functionality. Users who want a full featured size-based ad blocker can install an add-on. Furthermore, I do not understand why you do not see the evangelism value of this RFE. Surely worth the few more kilobytes for this request. Finally: Until now no one has responded to my point on IFRAME. That alone debunks all arguments on the effectivity of server-based blocking vis-a-vis size-based blocking.
BannerBlind today only remove the ads after the page has been loaded (http://mozdev.org/bugs/show_bug.cgi?id=955), it still uses bandwidth for the banner download and I'm not sure if it's possible to prevent this download with XUL and Javascript :( If this download block could be implemented without changes in the Mozilla core, then #21 is ok to me, and we should be thinking on how to improve BannerBlind as an addon and then when it's finished, we can ask to include it in Mozilla, just like what happened with spellchecker.mozdev.org
Mozilla should not include an option to disable banner ads completely. 1) It would not work reliably on today's web. Unreliable prefs are bad. 2) We would start seeing tools that take animated gifs and shave off the rightmost pixel from each frame, making the pref even more unreliable, and hurting users who have a legitimate reason for wanting to block banner ads. 3) Banner ads are the second least obnoxious form of web advertising, so Mozilla should not discourage their use. We have an option to block pop-ups because pop-ups are obnoxious and arguably a security hole, not just because pop-ups often contain advertising. (Television advertising never makes switching channels a two-step process and never prevents you from turning of your TV, and you always know which channel is showing you an ad.) Mozilla already lets users disable particularly annoying ads using "block images from this server" and lets users disable animations. I think that's more than enough.
Component: Accessibility APIs → Image Blocking
Summary: [RFE] Implement a built in size-based banner blocking system. → [RFE] Block banner advertisements based on image size
Jesse: The situation you envision where advertising companies will mass-decide to change all their images' sizes in response to a new feature by a browser called Mozilla - simply will not happen. There are dozens of 3rd-party sized-based banner ad blockers for IE, which is undeniably the world's most popular browser, and one for Mozilla (BannerBlind), yet not a single ad has changed a pixel. That argument is not supported by facts, in fact the facts prove otherwise. -------------- However, let me ask all of you who this question. /If/ upon configuring Mozilla you encounter a checkbox that says: [ ] Do not display banner-sized images. Question: would you check this box? I am willing to bet that all of you who say that banner-blocking will not work will be among the first to check this box if it is already there.
Summary: [RFE] Block banner advertisements based on image size → [RFE] Option to block banner ads based on image/iframe size
Bamm: Gotta agree with you there... I'd tick it. However, I wouldn't be suprised if I still got ads. :-)
Blocks: 150224
*** Bug 150224 has been marked as a duplicate of this bug. ***
*** Bug 152191 has been marked as a duplicate of this bug. ***
a user stylesheet works for me: *[width="468"][height="60"] { display: none ! important; }
Target Milestone: --- → Future
Paul: That would ruin the layout of a page. There should be no difference in the rendering of the html page except that the image itself and/or the iframe content is not downloaded.
Comment 26 really sums things up. In addition, the banners on some sites are not advertising and are useful for the site. A large part of the real solution, IMHO, is Bug 78104. Basing blocking on size of images and/or tables seems really obsurded. In addition (I might be mistaken on this as Moz maybe already do this, but I don't think so), maybe extend it such that these filters could be apply to Flash patter-matching blocking. Recommending WONTFIX.
*** Bug 163894 has been marked as a duplicate of this bug. ***
My bug was marked as a dupe, but it isn't exactly the same. For some of the reasons given here (real images of those sizes, etc), I only want to block banners from *specific* sites (For example, anandtech hosts real images and banners from the same server. I would choose to block all banner-shaped images from anandtech, but not others. On a new site, I wouldn't want all banner-shaped images blocked until I decide that they are in fact banners). BannerBlind is wholesale blocking of banner-shaped objects, which I think is overly agressive.
Let me ask this. For the hosts that host banner images and also other images you don't want blocked, are the banner images generally in a separate directory? There is another bug about blocking subdirectories of hosts (Bug 78104) I believe that might be able to resolve most of the reasons people want this enhancement. Worth a look.
bannerblind downloads the image visibly before hiding it (even though I can right-click the partly downloaded image to see the size ahead of time). That doesn't cut bandwidth usage at all... I don't see how it helps much at all.
*** Bug 168278 has been marked as a duplicate of this bug. ***
Shockwave ads are not blocked, even when normal gif/jpg are blocked correctly.
Since Shockwave ads are usually served in an iframe, blocking an ad-sized iframe should get rid of these.
Summary: [RFE] Option to block banner ads based on image/iframe size → Ability to block banner ads based on image/iframe size
Actually, there IS such as thing as "Standard Ad Sizes". This is defined by the Interactive Advertising Bureau and their recommendations are subscribed to by almost all ad companies. Here are the guidelines: http://iab.net/standards/adunits.asp IMHO blocking by ad size should be limited to the dimensions described here.
This would be a more elegant solution than Bug 155315 (image blocking based on regexp). Instead of seeing a popup ad, users would simply see a plain rectangle, so it would not do anything to the page layout. Plus, it would only take one click to activate and configure (based on the idea in Comment 27). Both forms of image blocking are already implemented in OmniWeb, so I ran some tests. For each of the web pages below, I have listed the number of ads that were successfully blocked out of the number of total ads (as a fraction). www.aol.com: Regexp blocking worked with 2/6 ads Size-filter blocking worked with 4/6 ads www.macosrumors.com: Regexp blocking worked with 2/2 ads Size-filter blocking worked with 1/2 ads www.macslash.org: Regexp blocking worked with 0/1 ad Size-filter blocking worked with 1/1 ad www.spymac.com: Regexp blocking worked in 0/2 ads Size-filter blocking worked in 2/2 ads slashdot.org: Regexp blocking worked in 1/1 ad Size-filter blocking in 0/1 ad The totals? Regexp blocking worked with 5/12 ads. Size-filter blocking worked with 8/12 ads. Anyone wishing to run his or her own test can change Omniweb's preferences in the "Privacy" pane. And blocking 2/3 of all ads would be quite nice. If it becomes less effective in the future (which I don't think will happen, but a couple of comments have been concerned about this), we could always take it out. Besides, turning the feature off would be just as easy as turning it on.
Mass reassigning of Image manager bugs to mstoltz@netscape.com, and futuring. Most of these bugs are enhancement requests or are otherwise low priority at this time.
Assignee: morse → mstoltz
QA Contact: tever → nobody
*** Bug 203574 has been marked as a duplicate of this bug. ***
Also recommending wontfix. This is already possible with userContent.css or extensions. So no need to implement it in yet another way.
Wontfix. Since this can be done with stylesheets or with a Mozdev add-on, I don't want to bloat Mozilla with it. Please do not reopen this bug, your request will be ignored.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
*** Bug 213230 has been marked as a duplicate of this bug. ***
*** Bug 226296 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.