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

[Benjamin Smedberg]

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.

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

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.

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.

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.

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.

--BDS