I NEED YOUR HELP! Please read!

[Richard Bateman]

tl;dr — If you are too busy to read the whole thing, scroll down to “WHAT I NEED FROM YOU"

====

I don’t make a request like this often, but I really need everyone’s help.

Mozilla Firefox 26 as currently planned will contain a “feature” called Click To Play.  This feature will block all NPAPI plugins (except flash) by default and where the plugin would have rendered they will show a “activate <plugin name” icon and text.  when the user clicks on it a menu will pop up asking “allow <hostname> to run plugins?” which will then let the user decide if the plugins should run on that domain or not.

Here is an example of what this looks like: http://cl.ly/image/0i2M1S2i3B2d

I don’t see this as being a major problem; there are a lot of plugins that have issues and having an easy way to disable them seems like a reasonable idea.

Here is the problem: If your plugin is not visible, the only indicator you get that the plugin didn’t load is a little blue icon in the top left.  There is a proposal to try to make it more obvious (http://people.mozilla.com/~shorlander/files/click-to-play-prototype/clickToPlay-Mockup-03.html open in firefox) but my experience is that most of our users won’t see that either.  Here is an example of the currently planned UI for a hidden plugin: http://cl.ly/image/2a2b23462p0V .  Once you click the blue icon you get the same dropdown as with visible CtP.

I know that a great many of you (unfortunately many more than will see or respond to this email) use hidden plugins.  It seems that the firefox team doesn’t believe that this is the case.  A direct quote from a recent email on the firefox-dev mailing list:  

"I'm not sure that in general I *want* hidden plugins to be more discoverable. I think the common case for everything except Flash is that you're being attacked by a compromised ad network and in those cases we don't want to throw this prompt up in the user's face.” - Benjamin Smedberg

Now, I have spoken with Benjamin in the past and I actually have a lot of respect for him, but I do not believe that he is correct in this instance.  If that were the case, then I could agree with their methods (however much they will cost the company I work for in terms of building workarounds), but I don’t believe it is the case.

=====================

WHAT I NEED FROM YOU!

=====================

If you have a plugin (even if you don’t currently use it on firefox) that is normally (or even sometimes) hidden when it is being used, please respond and tell me what you are doing with that plugin that you can’t do without a plugin.  I want to compile a list that I can show the firefox devs.  I hate to spam everyone’s box, but keep it on the list so that we have full transparency; I plan to send a link to this thread along with my findings to the firefox-dev list if I can get a response.

If I don’t get a response I will conclude that I was wrong and I will stop trying to change the course of this feature, because if we are the only company it affects then it doesn’t justify taking action, IMO.

Thank you for your help!

Richard Bateman

FireBreath Primary Author

[Neil Griffiths]

Hi Richard,

My plugin has 3 instances, only one of which is visible (when it's rendering a 3D scene). The other instances are to do with updating content - which doesn't make sense to be visible. Instead I pull data from the plugin via JavaScript and display that to the user using HTML. That makes much more sense than anything else!

It definitely sounds like we could be affected by this. It's not strictly hidden (it's placed inside a 1x1 pixel div) but this sounds like a bad choice by the Firefox team. I can understand the thinking behind it - but this will affect our users badly too.

Neil

--
 
---
You received this message because you are subscribed to the Google Groups "firebreath-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebreath-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Xan Charbonnet]

We're a web-based library automation vendor. We use a hidden plugin in order
to print things like checkout and payment receipts to receipt printers, and
reserve wrappers and other things to normal printers.

We historically have used a Java applet to do this. About a year ago we
switched to a FireBreath plugin (which works great!) for our most common
platforms, and Java still serves the rest. In either case, it's a hidden
plugin.

Many of our libraries have circulation staff which isn't particularly tech-
savvy. Even a highly visible "click-to-play" is likely to cause some
consternation, and if it's hidden, then printing will simply have broken
without explanation.

PLEASE, Firefox, at least make it obvious what's happening!

On Thursday, September 05, 2013 12:20:47 PM Richard Bateman wrote:
> tl;dr — If you are too busy to read the whole thing, scroll down to “WHAT I
> NEED FROM YOU"
>
> ====
>
> I don’t make a request like this often, but I really need everyone’s help.
>
> Mozilla Firefox 26 as currently planned will contain a “feature” called
> Click To Play. This feature will block all NPAPI plugins (except flash)
> by default and where the plugin would have rendered they will show a
> “activate <plugin name” icon and text. when the user clicks on it a menu
> will pop up asking “allow <hostname> to run plugins?” which will then let
> the user decide if the plugins should run on that domain or not.
>
> Here is an example of what this looks like: http://cl.ly/image/0i2M1S2i3B2d
>
> I don’t see this as being a major problem; there are a lot of plugins that
> have issues and having an easy way to disable them seems like a reasonable
> idea.
>
> Here is the problem: If your plugin is not visible, the only indicator you
> get that the plugin didn’t load is a little blue icon in the top left.
> There is a proposal to try to make it more obvious
> (http://people.mozilla.com/~shorlander/files/click-to-play-prototype/click

> ToPlay-Mockup-03.html open in firefox) but my experience is that most of

[Paulo Márcio Figueiredo Alves]

We, GAS Tecnologia a Diebold company, use hidden plugins and I can not see another solution. In the beginning was used C++ XPCOM, but as Firefox adopted short releases and do not care about retro compatibility, it became unmanageable maintain such thing. Another point is that with NPAPI we can achieve Firefox AND Chrome with the same code.

I hope it helps, because it'll cause us a lot of trouble.

Thank you for your effort,

Paulo Márcio

[bryand...@gmail.com]

We provide a web conference service and use hidden plugins for things like using the native file system or grabbing a screen capture.  I prefer that UI is coded in HTML, and use JavaScript to call into the plugin for privileged activities.  Since I do not want plugin based UI, my plugins will be hidden whenever possible.  

Chrome has an Info-bar, as does IE.  This is what users expect.  There is nothing to be gained, and much to be lost, by introducing UI that Users have not been trained to Interface with.  Firefox is certainly going to create additional usability problems that require every website using hidden plugins to code their own pop-up graphic pointing to the little blue plugin icon. 

Here's my proposal: FF can show an info bar the first N times a user visits the site.  If the user does not allow the plugin after a few visits, and then don't show it afterward.  

--

[Richard Bateman]

For the record, my suggestion to the firefox team was very similar to yours; they seem to feel that it would be too annoying for the users in cases where they don’t want/need the hidden plugin and/or when the hidden plugin is malicious.  I happen to think that isn’t really that common of a case, but I’m still waiting for them to come back with why they believe that to be so common.

Thank you to all who have responded; please keep them coming, and everyone respond as quickly as possible!  This thread will be very useful in making my point I believe as well as being useful down the road.

Richard

[Neil Griffiths]

I think the best argument you can make here is that if the plugin is malicious, the user must have installed it. If it was installed then pretty much anything else could have been installed instead (or at the same time) - which could be far more malicious than a browser plugin.

I realize that through the use of extensions and plugins it would be fairly simple to intercept banking details for instance - but to attempt to protect against this by "blocking" hidden plugins seems like a false security. But, like I said, the plugin had to be installed so *anything* malicious could have been installed.

[Kalev Lember]

On 09/05/2013 07:20 PM, Richard Bateman wrote:
> =====================
> WHAT I NEED FROM YOU!
> =====================
>

> If you have a plugin (even if you don�t currently use it on firefox)

> that is normally (or even sometimes) hidden when it is being used,
> please respond and tell me what you are doing with that plugin that you

> can�t do without a plugin. I want to compile a list that I can show the
> firefox devs. I hate to spam everyone�s box, but keep it on the list so

> that we have full transparency; I plan to send a link to this thread
> along with my findings to the firefox-dev list if I can get a response.

Hi Richard,

My plugin provides a javascript interface to use smart cards connected
to the client's computer.

It basically has one method, sign(). When it's invoked, the plugin pops
up a client side window and asks for PIN -- all on the client side to
avoid sending passwords to a potentially hostile server -- and then when
the user agrees, goes and does some crypto on the smart card and returns
signed data to the server. The plugin is usually not embedded hidden,
but 1x1 pixel visible -- that way all browsers properly give us their
window so we can attach a native modal dialog.

--
Hope this helps,
Kalev

[Nikita Bige]

At my current work we've developed 2  plugins that used to communicate with our cryptotoken devices. At my previous work I developed plugin that brings russian cryptography standards to javascript level. 

I know more than 4 Russian leading companies at Information security market which use plugins to support Public Key Infrastructure(PKI) in all browsers and OS.

More over our government creates internet portal http://www.gosuslugi.ru/pgu/  to provide services to citizens over internet, and there is plugin that could be used to authenticate and make digital signatures.

In Russia business use several internet sites for online trading and participate in auctions with government. And again there are plugins for PKI...

All these plugins are HIDDEN and aren't malicious!

 

2013/9/5 Neil Griffiths <ne...@muzzylane.com>

--
Wbr
Nikita

[Anders Bach Madsen]

Hi Richard

We at VMware Inc are using a hidden plugin on Windows, Linux and Mac OS as part of the management platform for the vSphere software stack. This plugin is a vital part of the client management tools. The plugin enables communication between our web based management app and some native tools which need to run on the client machine. We officially support IE (on Windows of course) and Chrome and Firefox on Windows, Linux and Mac OS.
Disabling all plugins except flash is not really desirable from our perspective, we would really like users to get a fat notice up in their face if a plugin is "inactive" and also the possibility to whitelist a plugin so that it is always accepted. If it would be possible to sign a plugin or provide some certainty that the plugin is from a known vendor and then activate the plugin, that would also be great.

Regards,
Anders Bach Madsen
Sr. MTS at VMware Inc
abachm ( at ) vmware (dot) com

[Andrey Starostin]

Hello,

We are using  several hidden plugins for:

- hardware joystick support

- download video from server with by specific protocol

- communication with server by specific protocol

[hasa]

This sounds VERY VERY bad. Nice that you Richard popped this up and help us !

We are having an web authentication/security product which uses intensively a plugin. Plugin uses only JavaScript/HTML to interact with end-user, so plugin visible size is zero. Hiding the plugin behind a rarely used icon would be disaster. There must be another solution which is better compromise between security and ease-of-use.

hasa

[hasa]

Sorry I quoted all of the original and forgot to specify more about our usage of the plugin. This was so confusing. Anyway, we are reading/writing to external devices via USB port, which is essential for the product.

[John Tan]

We are developing video player plugins for various platforms. Although we have yet to create any hidden plugin, one of the thing in the pipeline is to create one that could collect system resource(such as CPU type, RAM, network bandwidth) and then pre-select a proper profile prior to the loading of the player plugin.

[Colin]

We provide a two-factor authentication solution and use a hidden FireBreath plugin to provide persistent storage and device locking capabilities, neither of which could we do from JavaScript alone. We sign the plugin to prove it's from a reputable company. Having it disabled by default is crazy and WILL cause a lot of customer support calls.

Colin.

[Kyle L. Huff]

On Thursday, September 5, 2013 1:20:47 PM UTC-4, Richard Bateman (taxilian) wrote:

If you have a plugin (even if you don’t currently use it on firefox) that is normally (or even sometimes) hidden when it is being used, please respond and tell me what you are doing with that plugin that you can’t do without a plugin.  I want to compile a list that I can show the firefox devs.  I hate to spam everyone’s box, but keep it on the list so that we have full transparency; I plan to send a link to this thread along with my findings to the firefox-dev list if I can get a response.

I have multiple NPAPI plugins that are not visible. I know of quite a few other vendor specific browser based utilities that use hidden plugins to exchange information between the browser and their hardware. Many of these tools are designed to make very complicated tasks more use friendly, implying that the user may already be on the lower spectrum of technical understanding and will undoubtedly miss a UI queue to enable something they don't realize they need.

Moreover, depending on how this "feature" is implemented, I imagine it could become difficult for content providers who use hidden NPAPI plugins handle load failures. If the required plugin was referenced is blocked from loading, is this an installation issue, an initialization issue or due to "click to play"?

Lastly, I don't know about current development version of Firefox, but a few versions back, plugins provided by extensions (which have already been approved by the user) were not white-listed, nor could they be, as the location parameter for the click-to-play white-list database did (maybe still does) not support the "chrome://" protocol, thus breaking any extension which packages an NPAPI plugin.

[bryand...@gmail.com]

The distinction between visible and not visible is an arbitrary one -- no doubt it is based on the Firefox developer's personal preference rather than on actual data about what would improve security and usability.

Is 1 pixel square visible?  Are 2 square pixels considered visible?  And if so, has this improved security?

[Richard Bateman]

I know that 1x1 is considered invisible; I do not know what the exact cutoff is, but keep in mind that if firefox thinks it's visible and it's not the impact is actually worse, because you won't see the icon in the top left go blue.

Please everyone keep them coming; I need as much legitimate material as possible. I'll probably link them to this thread on Monday to give everyone time to respond.

Richard

On Fri, Sep 6, 2013 at 12:03 PM, <bryand...@gmail.com> wrote:

The distinction between visible and not visible is an arbitrary one -- no doubt it is based on the Firefox developer's personal preference rather than on actual data about what would improve security and usability.

Is 1 pixel square visible?  Are 2 square pixels considered visible?  And if so, has this improved security?

[Xan Charbonnet]

If it's anything like what they did with Java recently, then when you load a
page with a click-to-played plugin on it, then you get the icon in the top
left, regardless of visibility.

The plugin's space on the page turns into a "click here to enable this plugin"
button. This is the way that visibility makes it easier for people to enable
your plugin. If the plugin has no space on the page, then all there is is the
top left icon.

The problem, of course, is that the top left icon isn't enough, especially
when the user has installed specific software to make that specific page work,
and then it breaks for seemingly no reason.

It's particularly silly to punish hidden plugins, because obviously the best
UI practice is to for Javascript to interact with a hidden plugin, rather than
for a plugin to handle user interaction itself. How clunky is that??

[heinob]

We provide the first and only German web and browser based physician's practice management system, that is compliant with the very strict German data security und protection laws.

We use a hidden browser plugin for various things (which all are must have for our users):

- printing medical forms without browser dialogue

- starting of and comunicate with medical device software (windows executables)

- reading medical smartcards from medical smartcard readers

- scanning and video grabbing 

- and everything else that is needed by a native browser app out there in the dark and and cold desktop world

We use the hidden plugin because we follow Bateman's law: "If you can do it without a plugin, do it without a plugin." So all user interaction and data display is done by JS/HTML.

Good luck, Richard! And many greetings to the FF team. Our consequence would be relatively clear: Display a huge banner on our site: "Use Chrome!" If this is what you want: carry on!

Best regards,

Jochen

[Adrian C]

I have developed a plugin to allow communications between the Web page and smart cards in the user computer and as others in this thread by design the plugin is invisible since managing the UI in HTML and JavaScript provides a much more flexible and consistent user experience and gives users of the plugin more flexibility. I think the info bar approach would be better that the little blue icon that most users would not notice and would force developers to create a Firefox specific UI to attract user's attention to it.

Adrian

[John Dexter]

So, what's the upshot of all this Richard?

--

[Richard Bateman]

Well, that's still a little bit up in the air.  Several of the developers (well, all that have clearly stated an opinion) still feel that the current plan is ideal.  The UX person (if I'm interpreting everyone's roles correctly) has decided to try to find something more along the lines of what I was suggesting where the notice that the plugin is blocked is persistant and we'll see what happens. I am keeping an eye on things and just hoping; there isn't much more I can do at this point.

I will keep you all posted if I learn anything more.  I am cautiously hopeful.

For those interested enough to follow the full discussion, here is my original post:

https://mail.mozilla.org/pipermail/firefox-dev/2013-August/000886.html

The most promising reply: https://mail.mozilla.org/pipermail/firefox-dev/2013-September/000925.html

Find the other messages by looking under subject in the Aug and September archives:

https://mail.mozilla.org/pipermail/firefox-dev/2013-August/thread.html

https://mail.mozilla.org/pipermail/firefox-dev/2013-September/thread.html

Richard

[Georg Fritzsche]

On Sep 6, 2013, at 7:44 PM, Kyle L. Huff <kyle...@curetheitch.com> wrote:
> Lastly, I don't know about current development version of Firefox, but a few versions back, plugins provided by extensions (which have already been approved by the user) were not white-listed, nor could they be, as the location parameter for the click-to-play white-list database did (maybe still does) not support the "chrome://" protocol, thus breaking any extension which packages an NPAPI plugin.

The bug on enabling them per default is still open, but you can enable them from the extension:
pluginElement.QueryInterface(Components.interfaces.nsIObjectLoadingContent).playPlugin()

Georg