Hi. My two cents.
On Sat, Nov 9, 2013 at 5:13 PM, Benjamin Smedberg <benja...@smedbergs.us>wrote: > On 11/8/2013 4:33 AM, fma spew wrote: > >> We have a npapi-npruntime plug-in that access the Windows certificate >> store >> via CAPI to provide the end-user with its personal certificates to perform >> different operations. >> > What is the use case you're solving? Are you trying to install a > personal/client certificate that the user can use again in the future? Or > is this a server certificate that isn't signed using normal root servers? In our case, our Java Applet is being used to sign a bunch of documents with our smartcard (which contains a user x509 cert). Its using MSCAPI, NSS and PKCS#11 APIs. > > We have found a little pointer to some CAPI related work: >> >> https://groups.google.com/forum/#!searchin/mozilla.dev.platform/windows$20certificate$20store/mozilla.dev.platform/IafIvMyuzYg/vGaH9CE2fBEJ >> > This seems unrelated. Firefox currently manages its own set of root > certificates and does not use the builtin Windows certificate system. This > gives us extra control over some things like EV certificate policy, and has > the property that system administrators who want to add a new root > certificate (in a managed environment) have more difficulty doing so. But > it doesn't seem directly related to the feature you seem to need. IMHO Firefox should use system-store (like Chrome does), but that way Mozilla will loose the control over Certificate registration, that could be a way to earn some money. Maybe using OpenSC minidriver could help you bypass this -unrelated- issue. > > 3- We haven't found any indication of Mozilla about alternatives for these >> kind of plug-ins, meaning plug-ins that need access to, in this case, >> Windows stuff. Google has provided alternatives though. >> > Can you be more specific about the alternatives in Chrome? We are planning > out the implementation of WebCrypto, but it's not clear from your post > whether that would meet your needs or not. So far, webcrypto (key discovery api neither) doesnt seem to be considering user keys, so -to my knowledge- signing documents with a local installed x509 cert wont be possible. I'll love to be wrong. Perhaps Chrome native messaging could be an option, but as firefox plugins its not cross-browser. In our case, we are starting to test custom URL/scheme. ie: installing a local app which manages an specific protocol like "mysign://..." and when invoking from browser, the app will be launched. Dont hesitate to request any more info you may need. > 4- So, as encouraged by Benjamin Smedberg in the mentioned >> "plugin-activation-in-firefox" blog post, we post here our quesiton: Can >> you provide some guidance and/or advice? We feel ourselves stuck. >> Customers >> are asking for the new release and we have difficult to decide how to >> proceed. In the worst case, we will need to drop support for Firefox and >> encourage our customers to use a different browser. >> > Can you be more specific about why this would be necessary? Plugins > continue to work in Firefox as long as the user chooses to activate them, > and unlike chrome we currently do not have any plans to remove NPAPI > support from our desktop products. > I have to agree with Benjamin Smedberg. Firefox is not your problem, but the lack of standarization. Using the custom URL/scheme you will have "the same solution for all browsers"...until browser stop supporting this feature (or start annoying the users with more dialogs). My advice: start to fix your software to be prepared to click-and-play issues, while developing a new one. > Obviously we want to give people a full webAPI solution for valid use > cases, so that websites will work on platforms where plugins are not > supported (mobile/Windows Metro). Let's figure out what the use-case is and > whether there is already a web API that will solve it (already implemented > or in a draft) or whether we would need to write one. > My case: batch signning documents with user x509 cert stored on a smartcard. On Tue, Nov 12, 2013 at 11:10 PM, Matt Brubeck <mbrub...@mozilla.com> wrote: > One alternative is a Firefox extension. Firefox extensions can access > both native platform APIs and web content. In particular, extensions can > use js-ctypes to call C/C++ code. As said before, we will love having a cross-browser solution. > We've also mentioned the possibility of bundling a traditional plugin with > a Firefox extension to change the default click-to-play behavior: > "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." > -- > https://mail.mozilla.org/pipermail/firefox-dev/2013-September/000903.html > Maybe this is a workaround On Wed, Nov 13, 2013 at 10:12 AM, Henri Sivonen <hsivo...@hsivonen.fi>wrote: > On Wed, Nov 13, 2013 at 12:10 AM, Matt Brubeck <mbrub...@mozilla.com> > wrote: > > We've also mentioned the possibility of bundling a traditional plugin > with a > > Firefox extension to change the default click-to-play behavior: > > How does this help us retire the NPAPI in the long run? > Its retiring NPAPI mandatory/the goal? I dont know (security?) why Chrome dropped NPAPI. > > "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." > > Really? What if Oracle started installing an add-on together with the Java > plug-in? > Then, a "click to play extension" feature could be done! :P Regards. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
