Click to play, the next big problem for many smaller companies
richard at batemansr.us
Mon Sep 9 21:04:19 UTC 2013
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.
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.
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:
Some of the examples referenced of plugins currently being used include:
* Library (as in a physical library) automation
* Web conferencing solutions
* digital signature solutions
* carefully controlled filesystem access
* Cryptotoken device access
* VMWare uses a hidden plugin as part of vSphere to communicate between web
and some native tools
* Amazon MP3 Downloader is a hidden plugin
* Hardware joystick support
* Enable non-standard network protocols
* Communication with proprietary USB (or other) devices
* Streamlining printing, etc
* Reading of medical smartcards
* Video grabbing
* The Russian government uses a hidden plugin to provide pki authentication
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.
My proposal, once again, for a compromise:
* Block all hidden plugins by default, *but*, have a persistent and visible
notification of some sort that indicates what happened and prompts for user
* Allow the user to indicate "never show for this plugin"
* 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
To my mind, this solves most of the concerns and compromises on others:
* In cases where a plugin is required for page functionality, users will
never be left without that functionality and not knowing what is wrong
* Compromised ad networks that use java to spread can be blocked without
hurting the user experience
* 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.
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.
On Fri, Sep 6, 2013 at 2:13 AM, Gijs Kruitbosch <gijskruitbosch at gmail.com>wrote:
> On Thu, Sep 5, 2013 at 9:56 PM, Richard Bateman <richard at batemansr.us>wrote:
>> On Sep 5, 2013, at 13:19 , Benjamin Smedberg <benjamin at smedbergs.us>
>> > 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.
>> 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
> No. Signature certificates/keys can be obtained relatively cheaply or even
> free these days, so this argument doesn't work.
> 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.
> ~ Gijs
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the firefox-dev