Is there ANY way to make an executable that installs a Chrome Extension without putting that extension in the store? Or at least from private collection (so it wouldn't be available for others)?
** Changing Chrome to DEV version or Canarian is not a solution **
Short answer, no, at least not on Windows.
The blog post is pretty unambiguous:
[...] starting in January on the Windows stable and beta channels, we’ll require all extensions to be hosted in the Chrome Web Store.
You can publish an item to Chrome Web Store as "unlisted" and then use the standard procedure to install it programmatically. This will limit exposure of your extension, but won't really prevent people from getting a link to install it (anyone with an installed version can find the web store listing by extension ID and can share it).
If you want to make a truly private extension, you can add server-side license checks. But be aware that no matter the distribution channel, they can be bypassed, since the source code is exposed in a convenient debugger anyway. On the plus side, the same hoops you have to jump through will limit damage from any "cracked" versions.
Related
I am using chrome for web development and as my main browser. I have installed some extensions that I am using only for development like JSONView.
In most cases such kind of extensions requiring some extra permissions, like
Read and change all your data on the websites you visit
Is there any way to separate use of this extensions only for development and not use when I am logged in in something personal. So even if some extension will want still some personal data, that will not be possible.
Use multiple Chrome profiles.
Each profile has its own data and its own set of extensions.
As long as you don't install any extensions that can access the filesystem, they're completely separate.
(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!
I'd like to automatically switch out some settings for development and production, so how do I tell if I'm running an unpacked version?
Either build that information into your product at build time (much as you would to distinguish a debug build from a release build for compiled code), or use a heuristic. Here are some ideas:
If the extension ID is not the store version ID, you're probably unpacked.
If chrome.runtime.getManifest doesn't have a key value, then you know the store didn't package it.
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.
So i am working in a chrome extension which won't be hosted on the google webstore, thus i will need to add the auto-update functionality to it, however i need it to be a little more dynamic, i will try to illustrate what i am trying to accomplish by a little scenario so it won't seem pointless.
Scenario
I need to have an extension that's kinda have different editions for each version, i.e. each version have a free edition and a paid (feature rich) edition, and whenever a new version is released the extension will be updated according to it's edition.
In other words, the server should be able detect the user's edition and provide the crx file according to it "i.e. dynamic".
What i tried / think of
1.I tried to set a cookie with the extension edition, so when the auto-update occurs the server can check it and generate the xml file, unfortunately i found that cookies don't get sent in the auto-update headers sent by chrome.
2.I can make the extension talk to the serve when chrome start-up, so it will send it's edition, so the server will store it along with the ip and when the auto-update occurs the server will check the request ip and match it with the edition to provide the xml, i think this could work but it's kinda lame method.
3.I can use native apps to modify the manifest file to point to a different xml file according to the edition, i guess this will work too but i am not in favor of using native apps.
4.I tried to find a way to modify the get-request parameters (i.e. to add custom parameters like the edition), but it seems that there is no way to do so.
5.I can separate different editions to be different extensions (i.e. free edition will be a in different package than the paid one), however i am interested to make it all in one, so the user can upgrade/downgrade their subscription without installing/removing the extension they already have.
I guess that's it and i hope some one would have a better idea on how i can accomplish what i am trying to do.
P.S. I know the title is kinda vague but i couldn't find a better one, so if you came up with better title please let me know.
Why not make the free edition version 1.* and the paid edition version 2.*? Then make your update page generated dynamically by a simple PHP page, that gets the app id and version (see the autoupdate docs).
Put "update":"http://www.mysite.com/update_app.php in your manifest. In your PHP script, read $_GET['version'], and serve an XML update document to match the major version number (1.* free version, 2.* paid version). Basically, keep two XML update files on your server (and two CRX files) and have the script decide which one to serve.
It doesn't have to be PHP, of course; any server-side language will do.