I am aware of accessing NPAPI plugin from Javascript and I was able to implement the communication between the two.
I wanted to know if it is possible to access the APIs exposed by the NPAPI plugin from the Web Worked Thread?
Access to an NPAPI plugin from a web worker thread is exactly the same as accessing any other DOM element from a web sorker thread. From the mozilla documention:
There's no access to non-thread safe components or the DOM and you have to pass specific data in and out of a thread through serialized objects.
NPAPI is not aware of web workers, thus it is non-thread safe. In fact, all calls in an NPAPI plugin that talk to javascript have to be made on the main thread; all NPN_ functions (with a few specific exceptions) must only be called on the main thread. NPAPI is not thread-aware.
Summary: No, you can't.
Related
Using Puppeteer API it is possible to see get the list of worker threads, their URLs and locations. But is it possible to find out if a worker thread runs webassembly or JavaScript using Puppeteer?
Never used Puppeteer, so I am not sure it's appropriate, but I would suspect that if there is a way to polyfill instantiateStreaming and similar JS methods that are needed to compile WebAssembly's modules, to do some logging and then call the proper implementation, you might be able to find whether something is instantiating a WebAssembly module.
We know that there is a small overhead for Firebreath 2.0 plugins in Chrome because the framework creates a thin PPAPI executable to run the plugin within.
However, for Mozilla and Safari does a Firebreath plugin add any overhead compared to a bare NPAPI plugin?
In our case we are porting the stockfish chess engine to a plugin so the C++ code is very CPU intensive and even a small overhead is significant.
FireBreath 2.0 does not use PPAPI -- PPAPI is not a viable solution for third party plugins because unless used with Native Client the plugin will not be usable unless specifically enabled with a command line parameter each time Chrome is launched.
FireBreath 2.0 uses Native Messaging and the plugin is loaded in a native message host executable; thus there is no overhead as far as running the C++, but the interface to communicate with the browser uses JSON and is string-based, so there will absolutely be some overhead there.
Basically it depends on what your concern is -- if you need super high speed communication between the browser and your firebreath plugin you'll need to do some performance testing to see if it's good enough or not. If all you really need is for the C++ code to be just as fast as it was before then no problems -- it's native code, so it's every bit as fast. Your overhead will come whenever you communicate with the browser.
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
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.
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.