Click to play, the next big problem for many smaller companies
benjamin at smedbergs.us
Thu Sep 5 19:19:58 UTC 2013
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
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.
More information about the firefox-dev