392929 - Leverage new plugins support in the addons manager

Status: RESOLVED WONTFIX

(Thunderbird :: General, defect)

Description

[Scott MacGregor]

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.

Comment 1

[Joe Sabash [:JoeS1]]

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)

Comment 3

[georgi - hopefully not receiving bugspam]

> *** 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.

Comment 4

[Magnus Melin [:mkmelin]]

We have feeds too.

Comment 5

[georgi - hopefully not receiving bugspam]

so what?

you have html email and html usenet.

Comment 6

[Phil Ringnalda (:philor)]

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.

Comment 7

[georgi - hopefully not receiving bugspam]

>*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.

Comment 8

[Joe Sabash [:JoeS1]]

(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.

Comment 9

[Mark Banner (:standard8)]

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).