Chrome no longer supports NPAPI, so I need to rewrite my java-applet, e.g. as chrome extension.
Chrome community advices JavaScript API as alternative for access to OS features (see here)
Could you please point me, which exactly API allows to mount webdav disk?
OS access in Chrome apps/extensions is severely limited for security reasons so I think you'd be better off transforming your existing java code into a standalone application which will run in background and communicate with your Chrome extension via native messaging.
You most certainly need to do more research.
There is no feature parity between NPAPI and JS APIs. What's listed in the docs is the extent of JS API capabilities, and it's mostly sandboxed from real OS environment.
To replicate NPAPI capabilities, the closest alternative is (as wOxxOm's answer suggests) Native Messaging. Note that it is mentioned in the deprecation notice you quote. If you need to mount something on the host OS, that's your only option.
Chrome Apps have a different set of APIs available for them, which usually are less restricted in terms of sandboxing. For instance, r/w access to user-specified portions of host OS filesystem is possible.
Lastly, for the sake of completeness, there is a very specific fileSystemProvider API targeting ChromeOS only that allows you to do exactly that, provide a mountable filesystem from a Chrome App.
All that said, if you don'y need to present the WebDAV disk to the host OS but just manipulate some files within the extension, there are pure-JS implementations of WebDAV (not using any platform-specific APIs). It all depends on what you intend to do with the filesystem.
Related
I need to create digital signature of some XML data with a client certificate(smart card) using web browser. Usually I used to do it with a java applet executing on the client side. The benefit being multiplatform in terms of OS and browsers.
However this option is getting increasingly harder and harder to implement and support in the long term. Virtually all browsers require some sort of action in order to execute such applet, code signing with a trusted certificate is almost mandatory nowadays, new manifest attributes and so on. Well there is nothing wrong with some extra layer of security and I am ok with that.
However Google Chrome as of April 2015 has stopped support for Java applets (and other plugins as well) - there is a configuration switch but it won't be available for much longer as stated here.
Mozilla Firefox does not have end of support date for NPAPI but they call it "legacy technology".
As for IE - it does not support plugins in Modern UI.
So with Java applets no longer really a universal option what are my choices?
What I have investigated so far:
ActiveX - IE only
Silverlight - no access to certificates at all and as a plugin faces the same limitations as Java
Browser specific extensions; For example Firefox up until version 33 used to have window.crypto.signText but not anymore
local applications installed on the client - not easy to install, support, develop and update for several OS and their different versions.
Web Cryptography - "only basic cryptographic functions", no certificates support
I ran out of ideas. All suggestions are welcome and appreciated.
I did same research few weeks ago, and the first option for me is migrate to firefox (at least for now).
An alternative, could be migrate applets to JNLP java client application (maybe with some websocket/restful synchronization between java client/server/web page).
I think the options that you mentioned have less support among browsers than java applet.
Proprietary API available
I want to revive an answer previously deleted for lack of information. My answer does not provide complete info but since I had the same problem and stumbled upon this question, I'd like to share my findings.
I also have an additional requirement so that the browser signature works on "older" (IE9) browsers.
There is a web API at https://www.4identity.eu/ distributed by Italian smart card manufacturer Bit4id.
The 4identity API, however, is not really a full "web API" that relies on plain Javascript, as it still requires to download a Windows-only client (sic!). The client, as far as I could understand, responds on a custom keychain URL protocol (I had a past Oauth-2 related question on how to handle desktop applications....) which is not standard according to my findings. The client has access to the key store so it can upload the signed file to the remote web service who is being polled by the Ajax page.
I need to do some paperwork to get full API access, and I have no information about pricing. Still, I deem worth to give a detailed look.
Part 2 of the question
Supporting a real digital signature from browser requires browser vendors and W3C, who oversees web standards, to do a lot of effort, maybe just the same effort they did for standardizing DRM solutions in HTML5 for sake of multimedia companies (criticism mode on). Currently there is WebCrypto standard but according to research it is not available in "mainstream browsers"
Digital signing a remote file with a smart card requires access to the key store and the implementation of cryptography libraries. An open source implementation of PaDES/CaDES is expectable by the community, but without a final implementation of a standard way to access the key store the smart card cannot be accessed.
See also this answer.
This additional part of the answer does not apply to my case as I require this to work on older browsers.
Disclaimer: I am not affiliated with Bit4id but I know them since I had the opportunity to integrate their work in my apps. One of our customers is a Bit4id partner
I have a NPAPI plugin for sign-in data on website.
I want to replace it by Native Messaging technology. I have read the documentation, but I have a question : Is this technology safe?
Can hackers catch data in transfer from JavaScript to native host app and back?
Edit: merging in a better-worded question:
How secure is stdio data transfer ?
Is there a way for man-in-middle attack for such data transfer ?
It is, in principle, possible to inspect stdio calls made by an executable.
For instance, on Linux systems, you can use strace for that purpose. I don't know a similar Windows tool, but it's conceivable that it exists.
That would be akin to attaching a debugger to the browser/native host itself, and can only be done by someone who has access to the local machine with the same user credentials or administrative access. In particular, the user running Chrome can do it - just like he/she can use Dev Tools to inspect and intercept the data at the JavaScript side.
So, yes, in principle that can be intercepted, but only by someone will full rights to execute/debug code on the system it's running on, and OS takes care not to allow normal users to inspect processes of other users in this way.
You realize, of course, that Native Messaging will ONLY work within the bounds of the machine: With native messaging the browser will communicate with your host application over stdin/stdout.
So what exactly is the problem here? If the Hackers are capable of listening to your stdin/stdout they are already on your machine - you've already lost.
Not really, sometimes hackers can find XSS in vulnerable site, then it may be possible to use Native Messaging to execute command on Victim system
So after developing an extension for a few hours, assuming that the chrome.socket API would be available to extensions, I load in my extension and I'm told that the Socket API is only available for 'Packaged Apps'.
Does anyone know what's happening, and whether extensions will get the feature (back, since I think they had access when it was in .experimental)?
From the Chrome docs:
Packaged apps can act as a network client for TCP and UDP connections.
No, extensions do not have access to the socket API, and they aren't likely to ever get it.
Your confusion is understandable, since what Google called "packaged apps" used to be nothing but glorified extensions with an icon on the home screen. However, Google is now driving a much wider divide between extensions and apps.
Extensions used to have a subset of the functionality the apps did, but now there is mutually exclusive functionality in each. Extensions are meant for enhancing normal Web browsing, whereas apps are meant to be used as stand-alone tools that do not interfere with normal browsing. If you look at the API lists for apps and for extensions, you'll see that the list is vastly different: apps have the powerful hardware- and OS-centric APIs like socket, usb, and bluetooth, while extensions have a monopoly on browser-centric APIs like tabs, cookies, and bookmarks.
I know that lastpass extension have a binary component to communicate passwords between browsers (to firefox and IE). What mechanisms can be utilized by chrome extension to communicate with other system processes?
Apparently there's a Native Messaging API coming soon.
Source
Chromium Commit
Youtube Video example
If you need to communicate with the system, then you have basically two options:
You can embed an NPAPI plugin, which, generally, is discouraged when not absolutely necessary (and even then :) ).
Your system process can run a web server with a well-defined API that your extension talks to. This ends up being message-passing writ large, but has the potential of being much more secure, since the processes can be independently sandboxed. WebSockets are pretty useful for this sort of thing, but a lot can be accomplished with simple HTTP requests to 127.0.0.1 via XHR.
I'm looking for an open source headless browser to run on a FreeBSD shared Web server, which can do reasonably accurate rendering of current HTML/CSS/JS.
As I'm not very skillfull with Unix/servers and don't have root access, this should have no dependencies that would not be installed on a typical Apache shared Web hosting server (ruling out Java and HtmlUnit I believe), and should ideally even be pre-compiled for FreeBSD.
I guess I need a command-line and/or PHP-accessible interface (I'm not too clear on how any of that will work).
Please respond to this question if:
you're already familiar with this new trend in Web dev of rendering things server-side with headless browsers (e.g. page previews, Google-friendly AJAX indexing, etc.)
and you have some software to recommend for my needs
Thanks
I like lynx, it's a bit limited but unbelievably fast.
Maybe http://phantomjs.org/ is worth to have a look at.
Another way is to remote control the real browser using for example
http://www.seleniumhq.org/