Restart Chrome native messaging host - google-chrome

I've written a Chrome extension and companion native messaging host. I don't have any issues with it failing to start or crashing, but I would like to be able to restart it for updates of the extension. I can't find anything in the documentation or elsewhere regarding this. Is it even possible, or does the browser need to be restarted? Due to the nature of the extension, I'd like to avoid restarting the browser if possible.
Documentation can be found here, but it's not exactly robust.
https://developer.chrome.com/extensions/nativeMessaging

Upon further investigation I have found that restarting the native host application manually is not required. Chrome does this itself on update of the extension. However, that breaks the ability to send messages to the native host application from content scripts that have already been loaded, which was causing the issue I was seeing. Pages can be reloaded to fix messaging.

Related

How to completely disable NativeMessaging in chrome and other browsers?

I was debugging a situation, where chrome keeps saying it is managed by third party organization. Whether it was due to the malware or not is yet to be seen. What bothers me that some process in Windows keeps creating the HKEY_LOCAL_MACHINE\Software\Google\Chrome\NativeMessagingHosts\ registry entries even if I uninstall Chrome. Whether the key is created by legit app or malware it seems that native applications can communicate with chrome without user noticing or having mechanisms to disable the communication.
Now I am really concerned by the security issues connected with the existence of the mechanism of communication between browser and native applications through native messaging see here. I would prefer my browser not being able to see other applications in the system and other applications to see that browser is running or at least have an option to sandbox the browser and isolate it from native applications.
Is there a way to disable this kind of communication in Chrome and in the host system, in my case Windows but I would be interested in Linux as well.

Is the console in Chrome Dev Tools secure?

I was investigating why my DirectTV Now service wasn't working in the Chrome Dev Tools to nerd around when I couldn't log in.
I saw that when I try to log in, it logs my password and username.
So I began wondering - is there any way an unsavory Chrome extension or other loaded Javascript files could access things that have been logged to the console?
I've often dumped sensitive items into the log in development, but never in production.
Hoped someone better informed than I am could help me understand if this is secure or not.
If its in the console, its originating from a console.log() call. Since console.log() is dumping out to the console log window the contents of some variable or state somewhere in the page, then a plugin can also read the same variables in the running page.

How to distribute a Native Messaging Host with Chrome Extension

I developed an extension that communicates with a host (also developed by me), as provided by the https://developer.chrome.com/extensions/nativeMessaging example, and it works just fine.
Now I need to distribute my host with my extension and I couldn't find in Distributions how can I package my host along my extension. Are there any examples of how can I do it? Or must I distribute my host elsewhere?
I couldn't find in Distributions how can I package my host along my extension.
Support for this has been requested and turned down by Chrome developers.
I would recommend reading that thread for some insights in how native hosts are supposed to work according to them.
Or must I distribute my host elsewhere?
That's the idea. You need an installer hosted somewhere else.
wOxxOm's proposal is not going to work seamlessly, since a Native host cannot function without registering it with the system (e.g. adding a registry key on Windows) - something an extension cannot trigger.
It's possible you can still follow the bundle-download-open route for an installer, but I imagine it may get frowned upon by Chrome Web Store.

Chrome error "Server has a weak ephemeral Diffie-Hellman public key" for internal sites

Chrome seems to have released an update over the past week. This has caused at least 50 of our internal applications to throw the exception shown below. The solutions I have researched over the Internet, talk about updating the application server with a stronger cipher. However, our applications are spread out over IIS, tomcat, jboss, weblogic and websphere. Its not practical to expect all of these application servers to be updated. Is there no way to get Chrome to allow an "exception" for these sites ? Since these sites are all internal, the security is not really a concern.
Apparently, Firefox throws the same exception but there is a documented fix for that (by changing some settings in Firefox). Is anyone aware of a similar fix in Chrome.
Error
Server has a weak ephemeral Diffie-Hellman public key
ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY
I found a temporary workaround that should disable the security check in Chrome that is causing that error. It goes without saying that you do NOT want to use this while browsing the open web.
Try adding the following command argument to Chrome when you start it up:
--cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
I found this solution at this google forum post. Hopefully it will help!
While Maximillian's workaround might work for you at the moment, there is no supported way to add an exception.
The only safe solution is to upgrade the servers, and a less fragile workaround might be to put better proxies right in front of some of the servers.
This problem I found because of the JDK version running on App Server.
If your weblogic/apache server running on java JRockit version "1.6.0_33" & "1.6.0_45" or below you will face this issue.
A solution is to upgrade java to higher version like "1.6.0_101" and higher and restart app server.
I've solved this problem without upgrading jrockit but configuring the ssl section like this
<ssl>
<enabled>true</enabled>
<hostname-verifier xsi:nil="true"></hostname-verifier>
<hostname-verification-ignored>false</hostname-verification-ignored>
<export-key-lifespan>500</export-key-lifespan>
<client-certificate-enforced>false</client-certificate-enforced>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<ssl-rejection-logging-enabled>true</ssl-rejection-logging-enabled>
<inbound-certificate-validation>BuiltinSSLValidationOnly</inbound-certificate-validation>
<outbound-certificate-validation>BuiltinSSLValidationOnly</outbound-certificate-validation>
<allow-unencrypted-null-cipher>false</allow-unencrypted-null-cipher>
<use-server-certs>false</use-server-certs>
<jsse-enabled>true</jsse-enabled>
</ssl>
Can't tell you exactly whats makes the difference but it solved many different problems on SSL with chrome

What is the easiest way to find Chrome extension's id in a setup application?

I need to setup a native application which talks to a Chrome extension.
For that I am creating a setup, but I need the extension's id to be added in the native application's manifest file. That id says which extensions are allowed to talk with that native application.
How to get the extension id, assuming the user manually installs the extension by dragging and dropping.
Btw, To my knowledge installing an external chrome extension (no chrome web store) silently is close to impossible. I highly appreciate if someone has any solution for that, too.
The recommended flow would be to keep the extension in the Web Store (possibly unlisted if it does not work without the module), silently queue it for installation using the registry or other platform-specific method, and then warn the user to accept the install in the dialog on next browser restart. This is as close to "silent" as it gets.
If you absolutely have to distribute the extension externally (and drag&drop install will probably not work), you can pin the ID by setting the "key" field in the manifest. See this question for ways of doing so.