Robert Morley schrieb am Tue, 6 Mar 2007 11:04:21 -0500:
Hi Robert,
thanks for that interesting extra information.
FYI, I've noticed this same behaviour (ads being added to the back button)
ever since I changed my hosts file to an ad-blocking hosts file from
http://mvps.org/winhelp2002/hosts.htm. It redirects most common ad sites to
127.0.0.1, effectively preventing them from ever loading. It seems to be a
bit of a trade-off...if they're in my Restricted Sites AND in my hosts file,
they're not added to the history, but in XP SP2, I get a message popping up
for every single time one of them is on a web page...
This is also mentioned on the winhelp2002 site. That probably happens because
the page cannot be fetched. In this case IE would generate it's own "cannot
display" page (which resides in shdocvw.dll in IE6) and thus prompts you
because it navigates to a different security zone. Which means if you can
avoid the "cannot display" page this should stop to happen. (see below)
That this stops from happening when you add the site to Restricted Sites might
indicate that it is actually a script in there that produces this undesired
history addition effect. iframes are not shut off in Restricted Sites. But
"programs and files" in iframes are disabled by default in this zone.
which gets damned
annoying when it's two or three ads on every page load, every refresh, every
everything. If they're only in my hosts file, on the other hand, there's no
error, but the site gets added to my history, even though the IFrame didn't
actually load anything.
But I think you can click this undesired entry and IE goes to this "page" and
displays the "cannot display" page. Does it do this?
And finally, if they're only in my Restricted
Sites, because they're in an IFrame, the Restricted Sites rules seem to be
ignored, and the ad comes through just fine, which is obviously undesirable.
They don't get ignored. Restricted Sites restricts only script execution and
such, not iframes. An iframe is just an inline frame and more or less the same
as a "normal" frame, it's a viewing area where a ressource, typically a website
can be loaded. If you look at the source code you will also see that they
usually take care that the ad gets shown, anyway. Which means they load the ad
by iframe, an alternative script, a noscript portion and maybe yet another
means. Just so, if one option is blocked still the other is carried out. In
case the options are mutually exclusive they use a cookie that prevents the
second method from firing. Of course, this can also backfire. For instance
because of the extra ad blocking the cookie may not get set and only this
somehow produces the undesired extra entry. (This is speculation.)
This behaviour is also documented in the FAQ file for the Hosts file I
downloaded...see:
http://mvps.org/winhelp2002/hostsfaq.htm#Button
Yes, they describe it there, thanks. But this means, it's *not* specific to
IE7, but happens with IE6 SP2 as well when an iframe cannot be fetched or at
least it's connected to that somehow.
So it seems to be a matter of picking your poison. Which problem do you
find least annoying? Personally, I've opted for hosts file only and I'll
cope with the back button listing the additional sites.
Well, as I mentioned above, there may be a cure for this, but not for everyone.
You need to do a little bit for this.
I do extensive ad blocking myself, but I don't use a local hosts file. And I do
not see this problem at all. I use a proxy in my network and on *that* machine
I use a hosts file for blocking. And I have a web server running on it that
answers with a red one-pixel gif image to every request to 127.0.0.1.
So, each time an ad is blocked I either get a tiny red pixel inserted (if the
image or ressource doesn't tell the size) or the complete banner area is
painted in red (in case the HTML code tells an image size). I originally did
this because scripts fetching such a non-existent resource can keep a web page
from rendering until it finally times out after quite a while. If I serve an
image for those requests this doesn't happen.
This same method seems to avoid those extra iframe entries in the history.
So, if you have a network you could do the same as I did. Or if you want or
have to keep the solution on the same machine as IE you can install a web
server and serve a red-pixel.gif from there. I suggest using Apache for this.
It has small footprint, runs as a service (so once it's configured you just
forget about it) and is easily installed and configured (at least for a simple
serving from 127.0.0.1).
If you have a webserver somewhere else that has its own IP number you could
also reuse that. Serve a red-pixel.gif from the raw IP number and point the
hosts file to that IP number instead of 127.0.0.1.
Hope this helps. If you or someone else tries this, tell me if you history
pollution went away.
Kai
