Closed Bug 94118 Opened 24 years ago Closed 22 years ago

blocked images are downloaded anyway

Categories

(Core :: Graphics: Image Blocking, defect, P2)

Product:
Core
Component:
Graphics: Image Blocking
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: vicmsanz, Assigned: security-bugs)

References

(
URL
)

Details

(Keywords: perf, privacy)

With option "Accept images that come from originating server only" enabled, images from other servers are not displayed but are downloaded. Verified browsing through a proxy and looking at the proxy logs.
.
Assignee: asa → pavlov
URL: http://www.zdnet.com and many others → http://www.zdnet.com
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston
Reporter what build are you using?
0.9.3 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.3) Gecko/20010801
Status: UNCONFIRMED → NEW
Ever confirmed: true
It seems that images downloaded by javascript aren't checked against block rules.
Keywords: perf
Target Milestone: --- → Future
I have this when I disabled image loading completely. Images do not load when browsing (as expected), but HTML email that contains images still loads them. Actually, I'd really like an option to block image-loading only in email, since there I am more likely to be hit with a spam page I don't want to look at (this is with Linux, 1.0RC2)
*** Bug 169540 has been marked as a duplicate of this bug. ***
Copying info from duped bug: I see this in 1.2a under linux (changing OS to all, probably also Platform all?). Contrary to original description I have set "accept all images". An example site is cnn.com where I have blocked images from ar.atwola.com. The status bar shows the download and "page info->media" can be used to verify that all images are actually there. I also set severety to major since this does not work as expected and defeat important reasons of image blocking: creating no server hits at the image host to avoid IP tracking, reducing download volume, and avoiding the image load time.
Severity: normal → major
OS: Windows 2000 → All
I agree, this would be great for people on modems or other slow connections. Less stuff to download means better performance. -> Image Blocking
Assignee: pavlov → morse
QA Contact: tpreston → tever
Target Milestone: Future → ---
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla1.2beta
Yes, I hate this for a long time. Another problem (please let me know if you want me to file a new bug for this) which is probably related: Often pages are layed out in tables. Ad servers are often very slow or not reachable. So the page will not render until images in earlier table cells are loaded (even if the will not be displayed). Glad to see that you'll fix this bug for the next release, Stephen. Will this also fix the problem I just described? pi
Keywords: nsbeta1
*** Bug 174616 has been marked as a duplicate of this bug. ***
This probably isn't the right bug but hopefully someone knows where I should add this: I have blocked images at partner2profit.com and www.partner2profit.com, but the images load anyways. They also load in html spam emails sent to my Yahoo address. I right-click on the image and the menu choice says "Unblock images from this server", meaning they're currently supposed to be blocked. Mac OS X, using Mozilla 1.2 20021126
I did a quick test of the following page: http://bugzilla.mozilla.org/ I first cleared the disk cache of course both for testing with Blocking on and with it off. I notice that if you block the download of the bug image, it does appear to cause Mozilla to download 9k less. That is the size of this particular image. So that was just a quick test, and I'm wondering now, is this bug still a problem and maybe someone can explain under what condition it is not working.
Jay: I'm sure there's a better test, but view this image: http://www.ifsic.univ-rennes1.fr/presentation/acces/photos/maxi/pano1.png It's a 2MB PNG, and takes a bit to load. Now Block the image. Do a shift-reload. By watching the network activity and monitoring the time it takes to load the page, it's obvious that although the image isn't displayed when it is blocked, it it still is downloaded. A web page containing a large image like the one above would be a better test, but I couldn't find any offhand.
WD, You're right about that page with the enormous image. This is very strange. However, I tested another normal page with 30k of images or so total, and it also checks out. It is NOT downloading the images. Tres bizarre!
http://mbnet.fi/bab5/moztest.htm contains 2.6 Mo image that doesn't get loaded when blocked. Moz doesn't even contact the server hosting that image. So, in that case it is solved. I'm using {Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021115} I think the real reason is that DoubleClick.net actually uses a tag like this: [script LANGUAGE="JavaScript" SRC="http://ad.fi.doubleclick.net/adj/edome.fi.soneraplaza/murop/front;loc=top;sz=468x60;ord=8906532186?" ] (square brackets used here to make it look non-HTML, just in case) So, when I view the page, that JS still gets loaded (while the image itself is blocked successfully). One way to fix this would be an option to allow disabling linking any content (except images, which often are used on messageforums for good purposes) from other servers. One effect (good or bad, can't really tell) of this is that advanced (those that collect resolutions, browsers, browser plugins, etc) web counters don't work (they fetch JS from master server too).
Lasse, Thank you for the clarification. Evidently I had not read the bug description closely. The title of this bug might be better changed.
hm but comment 15 does not explain what is described in comment 13, does it?
Johann, Sorry, my response to comment 15 was kind of lazy. Actually, I am really saying that his response clarifies to me that I was not even understanding what this bug was about in the first place. I at first was just taking the bug summary at face value with some observation of my own a few weeks back that the feature didn't seem to be reliably working. The fact is, it is usually working but there are cases in which it will not, as Lasse describes. But I was suggesting that maybe the title of the bug could describe the problem in a more detailed, accurate way. What I can see is that if the server is indirectly referred to somehow or sort of cluttered up with a javascript statement, then it might load the image specified anyway even if it's invisible. I am clearly not understanding much here. ;-) Certainly, someone else who's better informed than me will have to understand and get into the details from a programmer's point of view.
Reassigninig to new owner.
Assignee: morse → mstoltz
Status: ASSIGNED → NEW
Component: ImageLib → Image Blocking
Target Milestone: mozilla1.2beta → ---
Is this still happening after the image loading changes from the 19th?
Mr. Zbarsky, it is with much regret and a sunken heart that I must report to you images are still transfered with Gecko/20030331 Phoenix/0.5 Linux. God bless.
QA Contact: tever → nobody
Does Phoenix have its own image blocking implementation? If so, please file a separate bug in the Phoenix product, not the Browser product.
They are the same, to my knowledge. Perhaps you could walk down the hall and query an actual Phoenix developer about it, though. I'll be happy to file a seperate bug if it now works in Mozilla-proper.
Using the ethereal packet sniffer I can conclusively confirm that Mozilla trunk build 2003040105 does NOT download blocked images. I tested both explicitly blocked images, and images blocked by the "Accept images that come from the original server only" pref. I believe this bug should be closed, and new separate bugs for the Phoenix issue and the Javascript image loading issue should be filed. (please mention the new bug numbers in a comment in this bug)
I agree, I think the changes recently checked in by Boris fixed this. Going to zdnet, I was able to "block" the intel centrino ad using 1.4a
*** Bug 202503 has been marked as a duplicate of this bug. ***
*** Bug 202503 has been marked as a duplicate of this bug. ***
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
So? Is anyone still seeing this? Make sure to restart after checking your image blocking preferences when testing, btw...
The example of comment 15 works for me. There is another bug with it, though. When not showing the image the alt-text must be used. It is not. pi
Hmm? We purposefully do not show alt text or anything like that for explicitly blocked images. The idea is that if a user blocks it, they want to know nothing about it (it's an ad).
I have not seen the problem for some time either. cnn.com seems to be doing some sick things to track your pageviews to ar.atwola.com even if you have blocked the image, so there are conenctions made to ar.atwola.com, but seemingly not to download images.
Marking worksforme, since it seems to work for everyone... Other bugs go in other bug reports. :)
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.