security.xpconnect.plugin.unrestricted  default boolean true

Isn't this a bit of a security risk?
Advantages to keep it true?
Disadvantages to set it to false?

Quote
Yogi

security.xpconnect.plugin.unrestricted  default boolean true

Isn't this a bit of a security risk?
Advantages to keep it true?
Disadvantages to set it to false?

You are right it does something like active X. I did not know. But checked on Wikipedia. & It can be dangerous when You indiscriminately install plugins which is 3rd party code. The only advantage is that the install must bee don explicitly - and You do not have hundreds with possible ill side effects like like You have with MS activeX.

Adavantage to keep it true all plugins You install will work.

You can use plugins choser from http://www.asahi-net.or.jp/~rb2t-kmc/index-e.htm by T.Kamachi to manage them.

Disadavantages: I could not tell You the code to allow individual plugins

p.s. Likely You can adapt examples from active.x.js. But I do not know for certain and have not tried it.

Thanks for the reply.
Plugins choser is nice. However I'm quite reluctant toward plugins generally, definitively adverse toward those involved in establishing connections, and hactiveX is in any case banned

IF I understand this correctly, you have to manually install plugins regardless, so this setting set to true will only be dangerous if you mistakenly install a bad plugin?

N

Or in case (which IMO is even more probably) the plugin qualifies (by design or because of poor coding) for an attack vector.

Quote
ndebord
IF I understand this correctly, you have to manually install plugins regardless, so this setting set to true will only be dangerous if you mistakenly install a bad plugin?

Yes IMHO - since You will take care where You install a design flaw is the the main risk.

Third party code comes at a risk. We had some risky ones from Adobe.

Some plugins have powerful scripting capabilties &/or can keep track by cookies.

The "free" hand outs are financed somehow



Edited 1 time(s). Last edit at 05/27/2009 06:59PM by guenter.

Well, if there is an attack vector for one of KM's plugins, I suspect our community will get on it right away and warn us. I think (for now), unless convinced otherwise here, I'll leave the setting at TRUE.

N

Guenter,

As always, I'll rely upon KM's early warning system to warn me about plugins I should avoid!

<VBG>

N

I found Netscape Plugin Chooser interesting; having tried it, I decided to update its interface a little, and here is the result:

http://rapidshare.com/files/238089690/Netscape__Mozilla__Plugin_Chooser_1.1a__modded__free.zip.html

Other:
http://massmirror.com/d811e3f77fefe46f09bbe975bb4fb3d1.html
http://www.fileducky.com/vjEoBQLA/
http://sharebee.com/0d50f70f

--- sig ---

Edited 2 time(s). Last edit at 05/28/2009 09:20AM by foobarly.

Guenter,

<<Third party code comes at a risk. We had some risky ones from Adobe.>>

Yes, I remember and I now am a fond user of Foxit Editor and Reader as a result!

N

Adobe is a very good example but I hardly could name a single third party plugin that didn't had several flaws in the past.
BTW, the newest one and it's not even the plugin itself:
New vulnerability in quartz.dll Quicktime parsing