Click to play, the next big problem for many smaller companies

Richard Bateman richard at batemansr.us
Thu Sep 5 19:56:02 UTC 2013



On Sep 5, 2013, at 13:19 , Benjamin Smedberg <benjamin at smedbergs.us> wrote:

> On 9/5/2013 12:47 PM, Richard Bateman wrote:
>> The plugin object *is* visible at that location, it just isn’t drawing anything. I would certainly call it a bug, and it makes a bad situation already worse. If I refresh the page (it’s a single page app) then the CtP UI does show up, which does at least help.
> ok. This is tracked in bug 790483. I had some questions in there about the testcase; can you work with Georg to get a minimal testcase of the behavior you're seeing?
> 
> 
>> In addition, this is just our case — part of the reason that I am so frustrated with this issue is that I feel like your strategy is based on a perception that I completely disagree with.  The only way that your strategy for handling hidden plugins makes sense is if we take as true the idea that most hidden plugins are not needed, useless, and/or malicious in nature.
> I would clarify this slightly as "most *usage* of hidden plugin is...". But yes, in general I agree.

And in case I wasn’t clear, I absolutely *disagree* and am working on putting together a set of information to illustrate the point.

>>   It requires enough work to get a plugin installed on a user’s machine that I don’t believe that is usually the case.
> 
> One of the most common vectors for viruses on user computers is attacks on insecure plugins, typically via ad networks. These attacks focus on insecure versions of Java and Flash, but also to some extent Silverlight, RealPlayer, etc. In some cases we have a list of known-insecure plugins via our blocklist, but that is not comprehensive.
> 
> Based on our small-sample user research of "typical end users", no plugin other than Flash was used "hidden". We have no way of collecting this kind of data from a wide population because of privacy concerns and because Testpilot is dead.

I will get you at least some of that information; believe me that a very large number of plugins are used “hidden”.  I have put out a request for details from FireBreath users; it’s only been a few hours and I already have several responses, including one major government website in Russia that is using a hidden plugin as one of the methods for authentication, but I expect I’ll have a lot more information in 24-48 hours after more people have seen and responded to the email.  I’ll let the responses come in a bit and then I’ll give you the whole thread to look through.  I can’t tell you how many actual end users are using it, but it should help illustrate how often hidden plugins are used and some of the ways that they are used.  In addition, I’d imagine this will be useful to you in figuring out what new features would need to be added to the browser ecosystem in order to reduce our dependence on plugins.


> If a plugin is installed bundled within a Firefox extension, the extention can enable the plugin by default (for all sites or for particular sites) via preferences/permissions. Because the user chose to install the addon, I see no problem with allowing this sort of default activating.

Is this a new feature? I was unaware that firefox extensions could control what sites a plugin is available on; this may be something we would be interested in pursuing, though I’m not sure it fully solves the problem, it would certainly help.

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

> Based on this, I believe we should continue to use the less discoverable UI for hidden plugins, *unless* those plugins come as a Firefox extension which can set reasonable defaults. I'm aware that this may harm some parts of the plugin ecosystem, but I think that is still the correct tradeoff to make.
> 
> I'd be interested to know whether you have other ideas which would solve your problem without causing negative side effects in the more important case of drive-by attacks; or whether you think that installing plugins via the addon manager is a good way to accomplish the same goal.


This is going to harm a *very very large* part of the plugin ecosystem. You have stated that there are a lot of viruses that have come from insecure plugins — this could be helped by doing something like IE does with low integrity processes, or a “safe mode” like Chrome is doing.  You could also help that by blocking by default unsigned plugins, without hugely impacting most other plugins.  Another feature that would solve a lot of people’s problems is a way to embed a plugin in an extension and disallow access to that plugin except inside that extension — Chrome does this and it’s probably one of the biggest use cases I see for new FireBreath users these days.  There are a lot of options.  However, despite your assertion several times that there are malicious or “attacking” plugins I haven’t yet seen any evidence of any such thing; in the case of security problems, I don’t see how hidden plugins are any different from visible ones.  If the plugin is signed then the user should know what company it is, which gives them some context.

In short, this seems like either the wrong solution or possibly the wrong problem that we’re trying to solve.

> In addition, I'd love to know if many of the current plugins you know of can be replaced with native HTML functionality. I know we already expose the webcam/camera. At some point the WebAPI group discussed exposing a USB interface to more privileged webapps, but I don't think that ever came to fruition because of concerns about the security model. If there are some common patterns or things that we can expose which would make plugins unnecessary, I am very interested in speccing those out and helping find implementers. Scanning support seems like a simple and obvious extension to existing camera functionality, and it might help your users who are using Android phones or tablets.

I have long felt that plugins are the natural proving grounds for new web technologies; Flash is an excellent case in point, and has driven the development of a lot of HTML5 features.  At the same time, with the model that firefox has held to so far I don’t see any solution for many of the things we have to deal with.  We have spent a lot of time discussing possible strategies for how to replace our current functionality if we ever needed to support ChromeBooks, for example, or if we could no longer use a plugin for some other reason.

On iOS we use a customized UIWebView and a phonegap-like-interface to communicate with objective c; our javascript api then provides an interface that “looks” like it has the plugin installed but is really just positioning a seperate preview view for camera access. On the desktop or a chromebook we could probably use the camera APIs to get the image, but even if we use something like Emscripten to compile our C++ to javascript I have serious concerns about how quickly it would run.  Our plugin uses an advanced and proprietary algorithm to analyze an image from a webcam and output a JSON document with what answers are bubbled, etc; it’s pretty CPU-intensive and I don’t see it working well in javascript, though we may have to try eventually if Chrome Books get big enough.  That wouldn’t allow us to export the data to gradebooks, though, which requires us to send keyboard events to other applications and get a global hotkey.

Our main backup plan for desktop is to have a program that runs constantly in the background that we can connect to with websockets or jsonp and lets us do what we need to; the challenge there, though, is that usually we’ll be on SSL sites and so connecting to a non-ssl websocket on localhost may or may not be an issue (maybe you know, we don’t yet). 

Aside from that, though, several of the cameras we support don’t support standard webcam interfaces; that’s really annoying, yes, but nothing we can do about it.

In short, my first response to anyone who is looking at using a plugin is “if you can do it without, do it without”, but there are a very large number of things that you need a plugin for.  One thing that browsers could definitely improve that would help is cryptography support; there are several plugins I know that are being used (hidden) in order to provide PKI for authentication for users.

Hope some of that helps; I’ll get back to you in a day or so with the results of my poll.

Richard


More information about the firefox-dev mailing list