In my opinion, "Help/About plugins" menu item should be removed from Help menu and transferred to Preferences menu (probably it might be placed beside Images item). And user should be enabled to switch each plugin (or even each MIME type) on or off separately. Maybe, for plugins, should be enabled more flexible policy like images (allow/deny loading from non-originating servers, alerts, permissions etc.). This may be very useful not only for images and plugins, but for iframes. In the future, policy for images, iframes, plugins and Java applets might be grouped in special submenu in Preferences This issue isn't very critical, I only would see it in future :)

I see, bug 70805 is close to this bug, but policy for iframes is a significant addition. And, i hope, my description of problem is more generalized.

What is the difference between this and bug 94035 ?

To security. This is a dup of the various requests for flash blockers, plugin managers, etc.

bug 94035 is closest to this, but it's silent about iframes. Maybe, this bug could be a meta or tracking bug? I have added corresponding dependencies.

if bug 94035 can block servers by MIME type then it could block text/html and so block all iframes from that server.

If we'll block text/html from any server, we'll not see any pages from this server, not only iframes. This is good idea for some annoying servers, really :) But I'm speaking about denying external iframes (by the way, also in HTML email), similar to current images policy.

If this can block individual plugins via permissions it could be a good substitute to having user-specific plugins since plugins are loaded before the profile manager is displayed (at least in MS Windows).

It is worth mentioning that some of what is being asked here is already answered. The service responsible right now for blocking images has a number of other capabilities that simply are not tied to implementation yet. The following things can currently be (potentially) blocked: - Documents (i.e., pages that get loaded in a window or tab) - Sub-documents (IFrames, Frames) - Objects (Object tags, at least) - Images (we are familiar with this, since it is exposed) - Scripts (Script tags) There are openings for other types in the relevant interface (nsIContentPolicy for those who care), but these are what I've found that the browser asks about before loading/running (from doing a little hacking with the image blocker). The issues then become: - Hook up more stuff to request before loading (stylesheets, arbitrary MIME types, etc.) - Write handlers/filters for non-image types (back-end) - Write user interfaces to control those filters (front-end)

*** Bug 165226 has been marked as a duplicate of this bug. ***

Just a heads-up: nsIContentPolicy is being prepared for a freeze. Suggestions for improvement prior to this freeze are appreciated and go on bug 191839. Note this is not about altering code that checks content policy--just with the interface itself.