My intention is to create a chrome plugin for the windows users. Is that possible to call windows api from Native Client /PPAPI. If possible how?
I am answering my question, as after some study, I found the answer from West a bit not right. I tried calling windows APIs in Pepper(PPAPI) Plugin and it works fine with a command line switch "--register-pepper-plugins" (not the --no-sandbox as specified by West). It seems safer to use this command line attribute as it is only registering a plugin in to the Chrome browser and not removing any sandbox. I thought of adding an answer after finding an actual pepper plugin existing in use, which uses the switch (the NetFlix pepper plugin for chromeos ).
Got more information to add. Chrome API is available which provides the multi-monitor information : chrome.systemInfo.display object provides all the necessary information. The chrome documentation is not updated. Important thing to note is that, the permission "systemInfo.display" is to be added in the manifest to use this object. Two bugs are reported in the functionality of this object.
1. The monitor name is same for all monitors "Generic PnP Monitor", the documentation claims to provide the user friendly name of monitors.
2. There is an event which should get invoked on resolution change of monitors, but the event is never getting invoked.
Currently the implementation is only for Windows OS. Support for other OS are on the way. Documentation says that the API is only available for Chrome App, but I haves tested that and the API is available on Chrome Extensions as well.
Unfortunately, the short answer is 'no'. Native Client is designed to be OS-independent and as safe as JavaScript. Think of Native Client as native code that has the same capabilities and restrictions as JavaScript. A Native Client module that made Windows API calls would break both of those design principles: it wouldn't run on, e.g., a Mac, and it would be a major security risk (imagine browsing to a web page that decides to erase files from your harddrive).
Since you mention Chrome, it may be interesting to you to know that web apps - whether they use JavaScript or Native Client - can request additional permissions as packaged apps in Chrome Web Store. However, native OS calls are still not possible for the reasons listed above.
NPAPI plugins do not have these restrictions, but the future of NPAPI, at least in Chrome, is uncertain (see the last paragraph of http://blog.chromium.org/2012/07/npapi-plug-ins-in-windows-8-metro-mode.html).
For development purposes, it is possible to turn Chrome's outer sandbox off with the command-line flag --no-sandbox and then run PPAPI plugins that make direct OS calls. This is meant for developers and is not a suitable option to be used by end-users.
If you could say a bit more about what you're trying to achieve, there may be ways to do this with Native Client/Pepper.
Related
(I have a problem with Google Chrome improvements that will drop support for my current solutions.)
I work on project where I move desktop system to an Intranet web application.
The crucial requirements are:
to move desktop system to a web application
to reproduce every single functionality from the desktop system in the webapp
While 95% of work requires creating casual web application, there is one thing which is non-standard to handle: my application must perform some actions on the client computer. These includes:
connecting with libraries
launching desktop apps
file manipulation in background
The example scenario is to integrate my system with some machine in the lab. I have to integrate my web application with drivers on client computer via DLL (desktop app did this, so my app have to do this as well).
Theoretically scenarios of the desktop actions may vary and I just want to implement some interface that will handle all the "client-machine" job the desktop app has done, so there is no need to work on every single scenario (but of course every scenario should be tested).
My solution was Java Applet. It worked. But then Google Chrome decided to drop support for NPAPI plugins, so in September'15 Java plugin (and my applet) won't be supported (http://blog.chromium.org/2014/11/the-final-countdown-for-npapi.html).
So my another solution is Java Web Start. It works. But now Google Chrome decided to drop support for background operations of external protocols (https://code.google.com/p/chromium/issues/detail?id=348640), so from Google Chrome 45 my Java Web Start solution won't be supported.
(Both above solutions work on Firefox and IE.)
The question:
What other technology can I use to interact with a client machine from my web app?
Other remarks:
I am reluctunt to write my own PPAPI plugin or Chrome Extension - I prefer one solution working on all major browsers.
I know that StackOverflow community does not like discussions about technologies, so please focus on describing possible solution to my problem.
We struggled with a similar problem as we need to connect/access electronic devices over JNI->DLL. The only technology where this is currently possible are applets. Period. (And even that is tricky since certain combinations of browsers/java versions/operating systems do not work or have problems, but this is another story...)
There are web technologies like HTLM5, JScript which can replace some functionalities of applets however in certain scenarios (like yours) there is no current alternative available - and you named some of those:
connecting with libraries like *.dll, *.so etc.
file manipulations
launching applications
And doing that across browsers and operating systems!
Solutions?
Tell your users that certain browsers can't be used (like Chrome and
Opera Next)
Write individual plugins for each browser (which probably is beyond your budget ;-)
Did you consider writing standalone application(s) in form of an executable file? The user must download and run it however e.g. java or plugins also need to be installed. But then there is the security aspect of that (downloading an and executing an executable file) - certainly not an easy decision
Have a look at FireBreath 2 - (just read about it in some posts, however didn't try it)
There are lots of discussions on SO to this topic so take a read:
alternative technologies to replace applets
applet alternative launch from browser
alternatives to java applet to launch microsoft office applications
alternative-java-applet-network-drive-access
what are the alternatives for java applet to launch client programs using chrome
alternative of npapi plugins for flash java applet
python alternative to java applet
npapi alternative for live file editing
... and many, many more!
First of all, I haven't started the implementation of the system I'm about to describe, as I didn't want to commit on implementing something I did not know if was possible.
So, what I'm trying to achieve is to build a chrome-app to download the audio from certain websites (e.g. youtube and soundcloud) using youtube-dl, post process it using ffmpeg and then upload it to a cloud service via some api. The reason I want to do it via a chrome-app is because I could do all the work on the client side (no need for servers) and I'd have the ability to insert javascript into the pages using content scripts, which would make the app pretty simple to use (I could create buttons such as 'download song' and stuff like that).
Although I have already read the documentation explaining the NaCl Technical Overview and some of the Application Structure, I still am not sure as to whether I would be able to make these calls via some C/C++ module or if I would get denied due to security reasons.
To summarize: considering that the user has the needed dependencies in his system (youtube-dl, python, ffmpeg and etc.), is it possible to make calls to third party APIs such as the ones described before via a chrome-app using NaCl ?
Thank you all in advance,
Chrome apps are normally sandboxed.
Less so than extensions - they can reach much more system resources via app APIs.
But still, what you mention is executing libraries / utilities out of browser, and it's not normally allowed.
(P)NaCl is tightly sandboxed in this regard. See this old question, it still applies: you can only use 3rd-party code that compiles into NaCl along with your app, not just link to a library. There are some library ports to NaCl, but it's not automatic.
Normally, a few years back you would use a mechanism like NPAPI to reach out and use a library out of browser. It's deprecated, and won't work anymore. In its place, Chrome offers a pipe-like (through stdio) connection to an external program called Native Messaging. You could use it to perform operations with system-level libraries and tools, but the downside is that you can't bundle the native host with your app, you'll need a separate installer.
We are looking for an easy way for our users to download and install a small client widget (it is a windows app) used with our (much larger) web app.
Our web app is currently only supported in Chrome.
Our concern is that the clickonce support piece may be missing from most Chrome installs.
The questions:
-- Is clickonce really going to be useful in this situation?
-- What is the best option for "one click" download-and-install for Chrome on windows?
ClickOnce uses NPAPI which is being removed from Chrome. You will need to look at NaCl, Native Messaging or PPAPI instead of ClickOnce. There used to be browser extensions that you could use, however they have been removed from the store (or no longer work).
Using Chrome should not matter, so yes Click once will be useful in this situation.
The only thing you need to worry about is your clients using Windows and the appropriate version of the .net framework. I hope this helps.
I'm writing a small chrome extension for personal use and I would like to run an executable via the context menu and pass certain information as arguments to said executable.
What the simplest and/or cleanest way to achieve this? To me it seems that it is impossible due to chrome's sandboxing.
This can be accomplished via NPAPI Plugins.
Code running in an NPAPI plugin has the full permissions of the
current user and is not sandboxed or shielded from malicious input by
Google Chrome in any way. You should be especially cautious when
processing input from untrusted sources, such as when working with
content scripts or XMLHttpRequest.
However, I should also include their warning.
Warning
NPAPI is being phased out. Consider using alternatives.
NPAPI is a really big hammer that should only be used when no other
approach will work.
via Start an external application from a Google Chrome Extension?
Alternatives to NPAPI
There are several alternatives to NPAPI. In cases where standard web
technologies are not yet sufficient, developers and administrators can
use NaCl, Apps, Native Messaging API, and Legacy Browser Support to
transition from NPAPI. Moving forward, our goal is to evolve the
standards-based web platform to cover the use cases once served by
NPAPI.
via http://blog.chromium.org/2013/09/saying-goodbye-to-our-old-friend-npapi.html
Another way, suggested here, is with Java.
Java applets: http://docs.oracle.com/javase/tutorial/deployment/applet/
Implementing Policy: http://docs.oracle.com/javase/tutorial/security/userperm/policy.html
Use sendNativeMessage:
There is chrome.runtime.sendNativeMessage which can be used to send a
message to a native application and chrome.runtime.connectNative which
allows for a more persistent connection.
So, you can't directly execute a command, but you can have a native
app do it for you.
You can find more info on Native Messaging in the docs.
via https://stackoverflow.com/a/19917672/1085891
I want to write a chrome extension that would automatically (without user interaction) read and upload a file from the local storage based on some event. I understand this is not directly possible because of the security model of the web and browsers.
After researching online I found that this can be achieved through an NPAPI plugin. From what I understand, I can write a chrome extension that will interact (via NPRuntime API) to the NPAPI plugin and request for a file to be uploaded. The plugin would retrieve the file and respond with the file data.
Question 1: Is the architecture conceived above a reasonable/efficient way of achieving my task?
If so, then my concern is on the security of this method.
Question 2: Since my plugin would be reading (and maybe writing) stuff from (and to) local storage, how would I code it in a secure manner so that it's not misused by other malicious sites/extensions? My plugin should work only with my extension and not with any other site/extensions. How would I achieve this? In other words, what kind of measures should I take to secure the interactions between my chrome extension and NAAPI plugin so that there is no room for malicious attacks?
Several FireBreath users have created plugins with FireBreath for use with Chrome and packaged them inside a Chrome Extensions (CRX). If you make the plugin "private" inside the extension then only that chrome extension can use the plugin. Note that no other browsers support this method.
You could of course do the same thing with any other NPAPI plugin, but FireBreath saves you a ton of time when you don't have to implement everything yourself.