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 extensions Options dialog
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 it's 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.
C:\Users\<User>\AppData\Local\Google\Chrome\User Data\Default\Local Storage\chrome-extension_dicaekdjklcpjdlndghehinafcafmanb_0.localstorage
C:\Users\<User>\AppData\Local\Google\Chrome\User Data\Default\Local Storage\chrome-extension_dicaekdjklcpjdlndghehinafcafmanb_0.localstorage-journal
The second journal file may intentionally be 0 bytes in size but must exist. As a test you may also download these two files below, these will restrict IntraLaunch to 'http://restricted.yourcompany.com' when placed as above rendering IntraLaunch useless until changed in the extensions Options again.
Download Example Files
Wildcards and regular expressions are not supported. All URLs should start with http:// or https://. All URL values are case insensitive and must include absolute FQDN's. Possibly refresh the web page after a change. (eg. "http://intranet.yourcompany.com/;https://portal.yourcompany.com/")
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.
Download Policy Templates
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.
For security reasons it is recommended you implement the IntraLaunch Group Policy for Computer Configuration only, not User Configuration.
Also note the IntraLaunch extension only checks for & honors Group Policy changes when the browser loads. So if IntraLaunchLockDownURLs is enabled for a set of workstations that are currently using Chrome already the extension will not be locked down until the browser is completely closed and opened again (presuming a workstation group policy update has happened too).