Open Bug 64066 Opened 24 years ago Updated 5 months ago

could image blocker also block IFRAMEs?

Categories

(SeaMonkey :: UI Design, enhancement)

Product:
SeaMonkey
Component:
UI Design
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: anthony, Assigned: jag+mozilla)

References

Details

Since Mozilla started removing much of the visual pollution from
my life, I've noticed more and more sites switching over to loading
images using IFRAME rather than IMG. For an example, see
http://www.theage.com.au/

Would it be feasible to have an option on the 'block images' dialog
that has a checkbox for "also block iframes from these sites".

I can't recall the last time I saw an IFRAME used for something besides
advertisements...
Yep, get those IFRAME's of my back, I hate them too! Banner banners and banners
inside IFRAME's. To hell with them!
cc:ing
Marking NEW & Adding RFE
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: could the image blocker also take out IFRAMEs? → [RFE] mage blocker also block IFRAMEs?
Summary: [RFE] mage blocker also block IFRAMEs? → [RFE] could image blocker also block IFRAMEs?
Ok, I'm prepared to have a look into this (it's beginning to seriously
nark me) - could someone give me some general pointers to where to start
looking?

The code for blocking images is in if.cpp and nsCookies.cpp.  The former detects 
that an image is about to load and the latter has the logic for determining 
whether or not the image should load.

While you're at it, how about blocking popup windows as well.
Anthony that's just great, thanks! But what exactly do you want to do? Image
blocking is done in those files, right? And we can block images right now. Do
you want to make a pref for blocking images inside IFRAMES? 

Hey and what about hiding the content of IFRAME's? Wait a second that can be
done right now with CSS! I will take a look into that right now. Yabadabadoo. If
that's going to work, I know just a start, but that will keep them of my screen!
Keep you posted.
Please see bug 37983, which describes a general, XPCOM-based content-policy
mechanism that should be extended to cover iframe and other processed or loaded
content that may originate from a different site than the main page.  See
http://lxr.mozilla.org/mozilla/source/layout/base/public/nsIContentPolicy.idl.
See http://lxr.mozilla.org/mozilla/search?string=nsIContentPolicy%3A%3ACONTENT_
for existing checks.

The compile-time coupling of modules/libimg to extensions/cookie is bug 18352,
long awaiting fix help.  No further such coupling should go into the mozilla
tree, whether to get iframe loading dependent on cookie manager policy, or to
make style-sheet loading depend on some other policy implementation, or whatever
the policy-mechanism nexus.

Cc'ing buster and shaver for advice.

/be
That CSS stuff seems to work pretty well. Not a single iframes for this guy, but
this is just a last resort to get them of my back.

I ask myself "how long will it take before web authors are going to check it
there images are loaded?".  if ( add not loaded ) no page content!
Then what? 

v3space.com is doing this for Netscape/Mozilla browsers already. There you need
at least one new cookie per visit, in order to load your images and stylesheets!
Hm. It really does seem like this is just leading to an endless arms 
race of filtering vs. tracking and annoying. Is it possible to have the
browser lie about the loaded state of the content? 

Who gets the final say here, the website author, or the end user. As 
someone who does both, I'd prefer that the user can select how to view
pages, but not in a way that would break them completely. I'm not sure
where the line is, nor how far mozilla's planning to go in terms of 
allowing filtering of content.
we are a User Agent, so we should serve the user.

I wonder if a special console should be created so users can approve or alter 
requests [both html dom and networking], however such a feature would need its 
own bug.
I think there is a confusion between cookie loading and image loading here.

A site can test to see if you stored its cookies because the cookie gets sent 
back to the site when you revisit it.  So it can decide not to send you content 
if you don't store its cookies and there's not much the user agent can do about 
that.

A site has no way of knowing what you are looking at on your screen.  So it 
doesn't know if you are not displaying images or not.  It can determine if you 
failed to download the images but I doubt that any site is doing such.
javascript might be able to ask if an image is loaded, and the server can 
definitely _know_ if the user requested it. in the end, the user will lose.
vishy owns this and is on sabbatical, this bug needs a new owner.
Over to morse, adding pavlov.
Assignee: vishy → pavlov
Anthony Baxter, do you have the tools and the skills to get started? I offer my
help, not that I'm an expert, but I can develop the UI for this and can assist
you while writing C++ code. If you like to jump-in right no, please consider to
read this first: http://www.mozilla.org/hacking/portable-cpp.html
Target Milestone: --- → Future
We should probably dupe this to 37983. We already have cookies and images
seperate... if we do this seperate too, next someone will want blocking third
party scripts... and then third part style sheets. Then third party normal frames.

Idealy I'd like to turn everything third party off, but be able to right-click
the broken objects and select 'show' or 'load' from the context menu. And of
course, there needs to be an exemption list of sites to trust entirely (and
referanced third party content is loaded), and a list of sites that are trusted
third parties (other sites can load stuff off them). Akamai comes to mind.
Although they host ads too so I'd probably leave them out, myself. Anyway, the
point is, that's alot of stuff to do seperatly for all the differant ways a page
can load external content.

I trust, however, when 107579 is fixed, images in third party iframes would be
blocked already, by image blocking.
The infrastructure brendan mentions in
http://bugzilla.mozilla.org/show_bug.cgi?id=64066#c7 is in place, and it's Just
A Matter Of UI to let the "image blocker" block external iframes and plugins and
scripts and style sheets, I think.

*** Bug 115585 has been marked as a duplicate of this bug. ***
Just got bit by this bug while visiting:

http://www.infoworld.com/articles/hn/xml/02/09/05/020905hnmssecure.xml

It's got a bunch of IFRAMEs that load content from ad.doubleclick.net.

It's been some time since this bug saw activity.  Are the last comments
regarding it only needing UI still accurate?  Also, should bug 138308 depend on
this one?

Voting, and assigning to image blocker component for further evaluation.
Component: XP Apps → Image Blocking
It would be very nice to be able to block non image content also.  More and more
ads these days seem to be Flash.  So I would like to block Flash from certain
sites too.
QA Contact: sairuh → tever
John, that would be bug 94035 (with 118 votes).

I don't see how THIS bug could work though, or why it's needed. If you've
blocked images from foo.com, and those images are either loaded directly, or via
an IFRAME, what's the difference? Both cases should already be blocked with
image manager.
the "Image Blocking" in this bug means the "Show only images that come from the
originating server" option. In this case, IFRAMEs come from the same server as
the image, so the ads appear. (Even though the IFRAME is not from the
originating server.)
Then that's a bug. I thought that was fixed long ago.

It doesn't matter who (iframe, js) requests the image load, if it's not from the
same domain as is in the URL bar, it shouldn't be loaded if that pref is set.

I gave up on that pref though, since it throws out too many babies with the
bathwater.
Summary: [RFE] could image blocker also block IFRAMEs? → could image blocker also block IFRAMEs?
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: pavlov → mstoltz
*** Bug 138308 has been marked as a duplicate of this bug. ***
QA Contact: tever → nobody
Status: NEW → ASSIGNED
Summary: could image blocker also block IFRAMEs? → [RFE]could image blocker also block IFRAMEs?
mvl, Boris, is this a dup? Didn't we once block iframes, and then regressed?
As originally filed, this is not a dup.  We have a regression about things like

<iframe src="foo.gif">

but this bug is about things like

<iframe src="foo.html">

as far as I can tell.

This is an urgent security bug.

I'm getting about 30 spam messages a day which use IFRAME as a web bug to
confirm that my email address is valid, thereby getting around the 'block
images' option which was intended to prevent web bugs.

Ideally, there should be an option to block all access to machines other than
localhost in the email display window.  (If the user explicitly clicks on a URL,
that appears in a regular browser window, so it shouldn't be affected). 
However, since current spam and/or worms are using IFRAME specifically, fixing
that specific problem is a reasonable first step.




Anybody working on this? There is no activity for this bug/feature for a while...
I can see more and more advertisers using iframe for displaying their content.
Good approach would be to add default handling for third party frame/iframe
content, at least something like "Load images" settings.
> Anybody working on this?

No.

But the back end is there (in gecko).  It just needs someone to write some
UI-type code, really.  Over to XPFE.
Assignee: security-bugs → guifeatures
Status: ASSIGNED → NEW
Component: Image Blocking → XP Apps: GUI Features
Depends on: 191839
Target Milestone: Future → ---
Might be stupid, but I've just discovered AdBlock extension for Firefox which
more-or-less does what has been requested here!
Now I think that it is much better to keep things like this outside the browser,
to avoid making it too complicated, and extensions are exactly way to go.
I've just got another email with call-home feauture.  This one was using regular
img tag (that is blocked) for calling back home, and iframe for loading content,
however it could have been the other way around.

I hope this bug will be fixed soon.  Is fix going to be only for iframe?  Or
will it be universal and include blocking of all remote content (otherwise,
spammer might just start attaching .au or .wav files to emails for this purpose)?

I've found two new bug reports that are duplicate of this one (iframe content
loaded regardless of "Do not load remote images in Mail & News messages"
setting).  These are bug 230274 and bug 236494.  They should probably be marked
as duplicates of this bug.

The email looked as follows:

<IMG SRC="http://ad.iso.com.tw/ad.png?eid=mailer-daemon@pbl.ca" WIDTH="0"
HEIGHT="0">
<br>
<iframe src="http://www.enews.com.tw/counter.asp" width=0 height=0></iframe>
Hardware: PC → All
Summary: [RFE]could image blocker also block IFRAMEs? → could image blocker also block IFRAMEs?
Those bugs are not duplicates of this one.  Mailnews and browser image content
policies should be separate from each other.
People are talking about loading of remote images, cookies etc. I would like a
checkbox option in my options panel (which will be permanently checked for me)
called something along the lines of "Block all non-mail traffic" - It must be
possible to only allow traffic to from the servers in ones accounts with those
ports - Then block anything else?
We know the address and ports of our mailservers - That's the only traffic I
want :) How's that?

PS. I vote that this be upgraded to severity critical/blocker as it's
compromising our privacy...
Blocks: 230274
The scenario in comment 31 already has happened!
> spammer might just start attaching .au or .wav files to emails for this purpose?
Please see:
bug 191460 comment 24 and bug 191460 comment 84 - Virusmail executes embedded
virus. (netsky.p@MM, W32/KLEZ.H@mm) (This is partly solved for Windows by bug
239160)
bug 213280 - denial-of-service-attack using iframe & telnet-urls
I support comment 33 and recommend to set this bug to a higher severity.
This is a browser bug, not a mailnews bug. You are looking for bug 28327
I disagree with comment 35.  I understand that mailnews component is using
browser component to display emails.  However, browser component can't do
anything if it isn't instructed by mailnews component what to do.  Throwing this
entirely to the browser would never get this fixed.  BTW, I see that resolution
in the mean time changed to fixed.  I eagerly wait new version to try it out,
and see if it works as advertised.
IT still are different bugs. You don't want the image blocker. you want
something in mailnews to block everything. And not only iframes, but everything.
Just as bug  28327 ask for.
(Also keep in mind that all this bugspam reduces the odds of this bug getting fixed)
I generally agree with that.  This bug is described in this or that form in
several bug reports.  For some reason, those bug reports are kept separate,
althoug they all boil down to the same thing: block all network connections
initiated by simply parsing and displaying HTML formatted email (be it IMG tag,
IFRAME tag, or anything else).
Product: Core → Mozilla Application Suite
*** Bug 260786 has been marked as a duplicate of this bug. ***
This bug has been sleeping for a while... 
I came across a security thread in the Wilders Security Forum : some exploit with IFrame, the thread is at:
http://www.wilderssecurity.com/showthread.php?s=b0c6481f85b34a3224ae41bac107dec9&t=203615

As a user, I would very much like having the possibility to block IFrames through my browser UI (most of them are ads and nuisance anyway), and also to have a white-list of sites allowed to use them.
Would that be possible? (other browsers like Opera and IE apparently allow that level of control).

Thanks!


Filter "spam" on "guifeatures-nobody-20080610".
Assignee: guifeatures → nobody
QA Contact: nobody → guifeatures
I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=436489 (Allow to block IFrames...) as a separate bug, for the following reasons:
- this bug (64066) links image blocking and IFrames blocking, but 
- both Firefox and SeaMonkey already have a GUI to block images, so I guess nobody is going to work on bug 64066 anytime soon,
- blocking IFrames is a major security concern, it deserves a GUI for itself in any browser that claims to make surfing more secure.

Thanks
Component: XP Apps: GUI Features → UI Design
Assignee: nobody → jag
QA Contact: guifeatures
You need to log in before you can comment on or make changes to this bug.