Technical Document

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 .

 Tip!   If you are deploying IntraLaunch across many workstations you can save your options on one machine and then copy the local storage's 'leveldb' folder to the same location (below) on the other machines. 'leveldb' is where newer versions (since ~2017) of Chrome store extension options & data and is typically found at:
C:\Users\<User>\AppData\Local\Google\Chrome\User Data\Default\Local Storage\leveldb
Unfortunately the data held within these files under 'leveldb' hold all data & options for all extensions. It is not currently possible to separate out and copy only IntraLaunch options (anymore as was possible with .localstorage before 2017).

   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. ";")

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.

 Download Policy Template Files   Currently this group policy control is only supported on Windows Server 2008/2012 (ADMX style templates). If you are using Windows Server 2003 please contact support for legacy templates.
    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 and

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.

 Warning   Your workstations should be running Chrome for Work (or the enterprise version) which can be downloaded here. Otherwise group policies may not be recognized by the regular Chrome. And you should already have deployed the IntraLaunch extension to all the workstations and have installed it's additional Connector.
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).