Closed Bug 94118 Opened 23 years ago Closed 21 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: 21 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.