Security is one of the most important aspects to consider. Any model must be designed to ensure the given workstation cannot be compromised and/or the general public internet cannot somehow use IntraLaunch without the user knowing. This is accomplished via a whitelist of domain's or URL's that can be specified in the Extension options dialog at the URL "chrome://extensions/ ", or via Group Policy in Active Directory. This restricts IntraLaunch from operating in any way shape or form if the web browsers current location is not specified in the whitelist.

This is very effective and works because the decision process whether to execute a program or not is handled behind the extension, within its sandbox. Chrome modeled extensions run in a separate sandbox, independent of the current web page's DOM. Therefore any malicious public code or web page cannot somehow trick IntraLaunch into running because it is impossible for the malicious code tell the extension, and thereby IntraLaunch, its ok or otherwise modify this whitelist. The entire extension model prohibits this and is the entire point of it, making this whitelist concept the best possible solution.

To implement this whitelist, manage your extensions at chrome://extensions/ and click the Options link for IntaLaunch. Then enter a semi-colon list of URL's or domains you wish to allow, everything else will be restricted. Once the whitelist is in effect IntraLaunch will do nothing when the web browser's current URL (or domain) is not found in the options dialog. No errors or exceptions will be raised. If the whitelist is in effect the IntraLaunch demonstration check should say so with a yellow warning at the bottom such as this screenshot .

Group Policy
Windows Server 2012/Active Directory

If you are an IT administator deploying IntraLaunch across a large number of workstations you have the option of using Group Policies to lock down all the workstations at once with a single setting on the server. This typically requires Active Directory in which Windows workstations are authenticating against a domain controller and you should already have the chrome policies setup and working with the Group Policy Management Editor.

To implement the group polices for IntraLaunch first download the Particle Software ADMX template files below. Then on your Windows Server copy them into the C:\Windows\PolicyDefinitions folder. ParticleSoftware.admx goes in C:\Windows\PolicyDefinitions and en-US\ParticleSoftware.adml goes into your language folder at C:\Windows\PolicyDefinitions\en-US. Currently only en-US is supported.

Then in Server Manager open Group Policy Management under Tools. Then in Group Policy Management right click on your Default Policies, which should already exist, and edit it. Then drill down to IntraLaunch within Particle Software which should now exist. Also notice the Google entry which should be there from the chrome policies. Edit 'IntraLaunch lock down URLs' and Enable it, providing a whitelist of URLs that you wish IntraLaunch to operate in. IntraLaunch will fail to operate under any browser location not defined here. In this case we have whitelisted http://intranet.yourcompany.com/ and https://intranet.yourcompany.com/.

You can see the workstations should now have the registry key shown here updated on the next login or otherwise after a group policy update happens. Security lies in the fact this this key is a read only value and cannot be changed. Chrome will also show the new mandatory policy name IntraLaunchLockDownURLs for IntraLaunch at chrome://policy. You can see how IntraLaunchLockDownURLs matches the registry value.

Next time the user runs Chrome the IntraLaunch extension will check for this lock down value and if it exists will update the Options dialog and make any changes there disabled and readonly, because group policies will supersede any local Options. Also notice "[ Group policy currently in effect ]" as a confirmation.