<div dir="ltr">I wasn't intending to indicate that this was a way to provide security, just that it does give you some way to classify plugins a little bit. If you really know where a codesign certificate can be obtained for free or even close to that I'd love to know about it, btw; I haven't been able to find one all that cheaply, though it's entirely possible I just don't know where to look.<div>
<br></div><div>Verifying authorship does give you some ability to assign accountability for a plugin. I guess I'm still trying to understand exactly what the problem you are trying to solve is; it started out feeling like you were trying to protect against intentionally malicious plugins, but the more we discuss it sounds like you're actually worried about poorly written plugins / plugins with security vulnerabilities. I am very much on board with this, but it sounds like there are only a couple of specific plugins that you have seen any meaningful problems with, and yet you've decided to punish a large number of other plugins with those.</div>
<div><br></div><div>There seems to be a misperception that hidden plugins are uncommon and/or there aren't good reasons to use them. I sent out a poll to the firebreath-dev group asking about people who are currently using hidden plugins. Here is the thread: <a href="https://groups.google.com/forum/#!topic/firebreath-dev/wCaKu5clXBg">https://groups.google.com/forum/#!topic/firebreath-dev/wCaKu5clXBg</a></div>
<div><br></div><div>Some of the examples referenced of plugins currently being used include:</div><div>* Library (as in a physical library) automation</div><div>* Web conferencing solutions</div><div>* digital signature solutions</div>
<div>* carefully controlled filesystem access</div><div>* Cryptotoken device access</div><div>* VMWare uses a hidden plugin as part of vSphere to communicate between web and some native tools</div><div>* Amazon MP3 Downloader is a hidden plugin</div>
<div>* Hardware joystick support</div><div>* Enable non-standard network protocols</div><div>* Communication with proprietary USB (or other) devices</div><div>* Streamlining printing, etc</div><div>* Reading of medical smartcards</div>
<div>* Scanning</div><div>* Video grabbing</div><div>* The Russian government uses a hidden plugin to provide pki authentication of users</div><div><br></div><div>All of these cases the plugin is used to perform a specific task that the browser can't do; yes, we hope that eventually we will have support from the browser to make that possible. Unfortunately, until that happens and the support is in all versions of the browsers, we are stuck using plugins. Actually, though, using hidden plugins makes it much easier to adopt browser support once it is added, since the rest of the interface doesn't have to change.</div>
<div><br></div><div><br></div><div><br></div><div>My proposal, once again, for a compromise:</div><div><br></div><div>* Block all hidden plugins by default, *but*, have a persistent and visible notification of some sort that indicates what happened and prompts for user action.</div>
<div>* Allow the user to indicate "never show for this plugin"</div><div>* Blacklist specific plugins that are known to have a lot of security issues, such as Java, so that they revert to the current less obnoxious behavior.</div>
<div><br></div><div>To my mind, this solves most of the concerns and compromises on others:</div><div><br></div><div>* In cases where a plugin is required for page functionality, users will never be left without that functionality and not knowing what is wrong</div>
<div>* Compromised ad networks that use java to spread can be blocked without hurting the user experience</div><div>* All hidden plugins are at least blocked by default, making it much more likely that plugins that aren't blacklisted but are being used maliciously will be stopped.</div>
<div><br></div><div>No, it isn't perfect, and it doesn't solve all of the problems, but it's the closest I can figure out how to come to solving the problems you wish to solve without causing a situation where all of us using plugins have to start recommending that their users don't use firefox anymore.</div>
<div><br></div><div>- </div><div>Richard Bateman</div><div>FireBreath Development </div><div>GradeCam Development</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Sep 6, 2013 at 2:13 AM, Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">On Thu, Sep 5, 2013 at 9:56 PM, Richard Bateman <span dir="ltr"><<a href="mailto:richard@batemansr.us" target="_blank">richard@batemansr.us</a>></span> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="im">On Sep 5, 2013, at 13:19 , Benjamin Smedberg <<a href="mailto:benjamin@smedbergs.us" target="_blank">benjamin@smedbergs.us</a>> wrote:<br>
<br></div><div class="im">
> Testing has shown that for hidden plugins, almost all users don't have enough context to make an informed choice. If a plugin is visible, they have a much better chance of making an informed choice based on whether the plugin is located in a familiar location and has a recognizable name.<br>
<br>
</div></div><div class="im">What if you made the decision based on something like whether or not the plugin had a valid digital signature, at least on windows and mac? Most companies with a valid business case can afford to sign the plugin and probably will anyway, particularly for firebreath plugins that are also COM objects.<br>
<br></div></blockquote><div><br></div><div>No. Signature certificates/keys can be obtained relatively cheaply or even free these days, so this argument doesn't work.<br><br>More importantly, from a security perspective, this is the wrong idea. A digital signature does exactly what it says on the tin: it confirms that the file in question was created by the person who holds the keys to that signature, id est, it verifies authorship. That in and of itself implies nothing as regards that plugin's security of implementation, necessity for the page the user is on, exploitability, and so on. Using it (by proxy of an implication about financial means) as a crippled way of ensuring security is wrong. Let's not go there.<span class="HOEnZb"><font color="#888888"><br>
<br></font></span></div><span class="HOEnZb"><font color="#888888"><div>~ Gijs<br></div></font></span></div><br></div></div>
</blockquote></div><br></div>