You are welcome to install extensions that are hosted outside of the webstore including on-prem, it is quite common for enterprise customers to host apps on-prem. 

On Windows, they must be installed via policy. That would be cloud policy from admin.google.com for customers that use Google Apps or for non-apps customers apps/extensions can be deployed via group policy for any domain-joined machine.  We also allow install via registry but only if the machine is domain-joined.  

Most companies will not want to install their internal tools on the Chrome Web Store. 

> A possible solution to this is to check the IP address for the extension hosting server. If the IP address starts with 9 or 192, then it is from internal network and it is likely to have less risk to install extensions from an internal server. 

Why 9?

The IP ranges reserved for local domains are 10.*.*.*, 172.[16-31].*.*, and 192.168.*.*.

I don't see how that provides any security, though. Remember that any hole we open up will be immediately exploited by malware. Any malware that wants to install a Chrome extension now would simply need to run a local web server, then install the extension from the machine's own local IP address, then shut off the web server a fraction of a second later. It wouldn't offer any serious protection at all.

I'd like to suggest a different alternative: if the concern with publishing the extension on the web store is that it contains private IP you don't want to release or host elsewhere, why not publish a minimal extension to the web store that simply authenticates the user and then downloads the rest of the extension code from your own private server?

Essentially you'd be hosting the real extension code yourself, and only giving it to users you want to - but the "runner" would be a public, probably unlisted, extension, which would contain nothing of value and would be useless to anyone else.

I know that probably isn't the answer you're hoping for.

Aside from that, I think we're all really open to hearing ideas for other ways that members of a group could be authenticated to allow installing extensions from some source other than the Chrome web store. Any solution needs to be something that wouldn't be easy for malware to spoof, which is the main concern with the alternatives suggested so far.

>>> "Why 9?

The IP ranges reserved for local domains are 10.*.*.*, 172.[16-31].*.*, and 192.168.*.*. <<<

It is just an example. I meant all defined local domains. If a malware can modify your machine's registry, install and start a web server on a different machine (let's say you will limit the extension must not from the same machine if registry entry is used), then what else this malware can't do? Is it still meaningful to "block" this malware?

Another alternative might be Chrome web store issue some kind of certificate that we can install on the server that hosts the private extensions. The Chrome installer then checks the certificate before installing the extensions. Would this be secure?

Our extension has background scripts, content scripts and devtool pages. There are a lot of JavaScript files, HTML files, CSS, icons, JSON files etc. It is very challenge for us (Chrome extension developers) to write a minimal extension to load all those files at runtime and ensure everything will still works as it suppose to. Actually, what you proposed is a very good idea. What if Chrome provides a template extension (or a wrapper) that we can specify where our extension is. Then at runtime, this template extension will load our extension and run it. This template extension can be reused by everyone that needs to keep their extensions internally. Does it make sense?

> It is just an example. I meant all defined local domains. If a malware can modify your machine's registry, install and start a web server on a different machine (let's say you will limit the extension must not from the same machine if registry entry is used), then what else this malware can't do? Is it still meaningful to "block" this malware?

I don't know for sure about allowing installs from a local domain but not localhost. I'll run it by our security experts for their opinion.

> Another alternative might be Chrome web store issue some kind of certificate that we can install on the server that hosts the private extensions. The Chrome installer then checks the certificate before installing the extensions. Would this be secure?

Yes, it would. The question here would be how we could distribute certificates at scale and still defend against malware.

I feel like your use case is really not that different from the one that millions of other users are enjoying. The only difference here is that Google Apps cloud policy and joining a domain don't work for you. I think some other solution that authenticates based on all of the machines belonging to some group makes the most sense.

Would every computer in this organization have a hostname that's part of the same domain? Perhaps we could provide a way for you to install an extension to anyone whose public hostname ends in some certain suffix. That's subtly different than the idea of allowing extensions to be installed from a local IP address because we could actually authenticate and enforce it while still allowing you to host your own extensions.

I can't promise anything but I do think it's worth trying to find constructive suggestions that could benefit a lot of organizations who want to host Chrome extensions.

In the meantime...

> Our extension has background scripts, content scripts and devtool pages. There are a lot of JavaScript files, HTML files, CSS, icons, JSON files etc. It is very challenge for us (Chrome extension developers) to write a minimal extension to load all those files at runtime and ensure everything will still works as it suppose to. Actually, what you proposed is a very good idea. What if Chrome provides a template extension (or a wrapper) that we can specify where our extension is. Then at runtime, this template extension will load our extension and run it. This template extension can be reused by everyone that needs to keep their extensions internally. Does it make sense?

We can definitely look into that, but in the meantime if you'd like to try this approach and you hit any technical hurdles we'd be happy to help. I've done similar things before in other extensions so I know it's a technically sound approach.

>… Perhaps we could provide a way for you to install an extension to anyone whose public hostname ends in some certain suffix. That's subtly different than the idea of allowing extensions to be installed from a local IP address because we could actually authenticate and enforce it while still allowing you to host your own extensions…

So far, developing the extension is very straight forward. We are happy with the extension framework. The only problem is the installation due to the domain restriction. I think it will work if checking hostname suffix is used. I am not sure what you meant by “authenticate and enforce it” Asking users to enter user name and password in the case of installing the extension from the same machine? This should be fine.
I don’t know how your code works. I just want to bounce some thoughts that I have. They may worth something or they can be completely off. But I hope I can help in some ways…

>I've done similar things before in other extensions so I know it's a technically sound approach.
Do you have any sample code that you can share?

> So far, developing the extension is very straight forward. We are happy with the extension framework. The only problem is the installation due to the domain restriction. I think it will work if checking hostname suffix is used.

We're discussing this idea internally.

> I am not sure what you meant by “authenticate and enforce it” Asking users to enter user name and password in the case of installing the extension from the same machine? This should be fine.

What I mean here is that this isn't easily spoofed by malware. Malware couldn't just lie about the computer's hostname in order to circumvent this because DNS wouldn't resolve

I'll let you know when we have an answer.

>I've done similar things before in other extensions so I know it's a technically sound approach. Do you have any sample code that you can share?

Sure, here's some code used in a content script that fetches a bunch of scripts from the background page and executes it. It has examples of doing so via extension messaging and via XHR.

https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/chromevox/closure/closure_preinit.js

It's even simpler if you just have a single script. Suppose you have a background script now called background.js. Just do this:

* Host background.js on your own domain
* Replace background.js in the extension with background_loader.js - all it does is fetch background.js (using XHR over HTTPS) and execute it.

It's really not any more complicated than that. There are some extra tricks you might want to use if you want to preserve more debugging information or if you want to make sure you load multiple scripts serially.

That should work for content scripts too. Worst case you may need an extra step for a content script or devtools script, i.e. fetch it from the background page and the background page fetches it from the web.

I wanted to highlight one other alternative: users could reinstall Chrome with a master preferences file that installs the extension:

https://support.google.com/chrome/a/answer/188453?hl=en

After internal discussion, we don't have any immediate plans to offer alternative ways to install Chrome extensions.

To recap, here are the options available right now (other than having Chrome Dev users manually install it each time they open the browser):

1. Publish the extension on the Chrome Web Store. While this does publish some code externally, you can use a variety of mechanisms to avoid sharing the code with anyone other than Google and your own users.

1a. Obfuscate the code

1b. Have the extension download and execute code from your own secure server rather than including it with the extension

1c. Publish to test accounts so that the extension is only available to members of a Google Group. https://developer.chrome.com/webstore/publish#publishing-to-test-accounts - then all you need to do is ask users to join that group before installing it

2. Install the extension via the registry, for users who join a domain

3. Install the extension via a Google Apps policy

4. Install the extension when Chrome is installed, using master preferences

I'm sorry we're not able to offer additional options at this time. Please feel free to reopen or file a new bug if you have additional ideas we haven't considered, but we think there are a variety of reasonable solutions and workarounds for you to use.