The Thunderbird content policy manager honors a global mail pref: mailnews.message_display.allow.plugins for allowing plugins in the message pane. the new addons manager now allows control over individual plugins. We should: 1) remove support for mailnews.message_display.allow.plugins from nsMsgContentPolicy. 2) By default, disable each individual plugin. 3) Users can then choose to enable individual installed plugins via the new plugins UI on the addons manager.
FYI the enable/disable toggle works fine in TB Personally, I think they made a mistake in bug 391687 Consolidating plugins with multiple dll's gives you less flexibility. and alphabetizing may make it easier to find, but no longer shows the "order" in which the content-type is matched against the plugin. You may have multiple plugins for the same content-type. (but about:plugins still shows you that)
Target Milestone: Thunderbird 3 → Thunderbird 3.0rc1
> *** Bug 454982 has been marked as a duplicate of this bug. *** i am not sure i understand this bug correctly. if someone suggest allowing java/flash and similar in mail content and/or editor, i oppose this and find it completely insane from security POV. Bug 454982 is about unconditionally killing all plugins in mail.
We have feeds too.
so what? you have html email and html usenet.
So that's three places where someone might want to use a plugin, one of the three being a web page completely divorced from mail other than by being in an iframe in an HTML email. Please stop trying to argue from authority, and start saying *why* you think that nobody should ever be allowed to use a plugin in any content in an email program.
>*why* you think that nobody should ever be allowed to use a plugin in >any content in an email program. because getting owned by just previewing a mail message is not nice - no need to open in browser - think about the 1st script kiddiot that trades a flash 0day and thunderbird's luser base. there have been exploits in flash and java and i doubt they killed all exploits. editor doesn't handle active content well imo - look at the *mail only* bugs.
(In reply to comment #7) > >*why* you think that nobody should ever be allowed to use a plugin in > >any content in an email program. > > because getting owned by just previewing a mail message is not nice - no need > to open in browser - think about the 1st script kiddiot that trades a flash > 0day and thunderbird's luser base. Of course you do use the View->Message body as "simple html" option, No ? I would think that anyone concerned with malicious content would protect themselves in this way. The tags used to instantiate plugins (embed, and even the new video tag are ignored in rendering. > there have been exploits in flash and java and i doubt they killed all > exploits. The OJI interface has been removed for years. > editor doesn't handle active content well imo - look at the *mail only* bugs. The editor needs a lot of help, active content is just one area. Should these capabilities be improved ? I think so. Please note that the original reason for this bug was to disable all plugins by default, while allowing enabling them at the discretion of the user. Sorry for the bugspam.
Marking as won't fix, in favour of bug 615675 which will allow users to have plugins enabled for non-emails (by default), and a pref to enable in emails (similar to what currently exists).
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.