PROVISIO DevBlog

Securing the SiteKiosk browser with Microsoft EMET

SiteKiosk uses the browser engine of the installed Internet Explorer to render web pages. To minimize security risks you should therefore keep the Internet Explorer updated by using the automatic Windows Update feature that comes with the operating system.

Unfortunately there is the risk of so called zero day attacks. There was one just recently that affected the Internet Explorer and was covered extensively in the media. Because SiteKiosk uses the Internet Explorer engine it is also affected. While the security features of SiteKiosk do limit the attack options to a certain degree a possible risk remains.

It is also notable that one aspect of zero day attacks is, that even antivirus software does not help as a required signature update takes its time to become available.

This is where Microsoft EMET or Enhanced Mitigation Experience Toolkit comes in. The toolkit can be used to harden an application so that flaws cannot be used as easily and zero day attacks have no or a more limited effect. It is free to use and easy to configure.

When you install EMET make sure to select to install it for all users. After the installation is finished you can just add the SiteKiosk.exe and other applications you want to protect using EMET in the EMET configuration. That's it. You can keep on using SiteKiosk as you did berfore, but now with the extra protection that EMET provides.

How to Build a Script Watchdog for External Applications

The secure SiteKiosk browser offers an easy way to run external applications from within the restricted SiteKiosk context. You can just add the desired applications with the help of the SiteKiosk configuration. SiteKiosk will then provide means to start the applications through the SiteKiosk browser interface, it will also close these applications when the screensaver starts or a user logs out. The configuration of SiteKiosk even allows you to automatically start an application when SiteKiosk starts, the screensaver ends or after a user logout happend.

There can be situations where you may want to have even more control of the external application you want to run with SiteKiosk. For example you don't want to use the browser features of SiteKiosk but just want to use SiteKiosk to protect the operating system from being tampered with and your main goal is to permanently run a specific application.
The culprit is that this may be an existing application that for example allows to user to close it. This is where the SiteKiosk Object Model comes in. It is a proprietary Javascript extension that enables you to control nearly all aspects of SiteKiosk but also comes in very handy to create helpful custom scripts.

Let's summarize what we want to achieve with the script we are about to create. SiteKiosk should run in fullscreen mode in the background and on top of that an external application should always be visible.

The first step would be to create a blank page for SiteKiosk running in the background, alternatively you may of course as well use a page with a nice design. Here is the code for the blank page:

<html>
    <head>
    </head>
    <body>
    </body>
</html>

Save it as background.html (or whatever name you prefer) and make sure to put that file into the ..\SiteKiosk\html\ folder.

Next is the Javascript that we use to control the application. The first step is to start the application. For that we are using the Run method of the ExternalApps collection. Because we do need that code later on again, we will put it in a function:

function StartMyApp(){
    SiteKiosk.ExternalApps.Run("c:\\pathtomyapplication\\myapplication.exe", true);
}

The Run method basically expects the path to the application plus a boolean value that specifies if SiteKiosk is to check first if this application is already running. If it is already running, it will be maximized and focused. For the purposes of this script the boolean value should be true to ensure that no additional instances of the application are started.

SiteKiosk or the SiteKiosk Object Model cannot prevent the user from closing an application that provides the user with options to close it. Therefore we now need the code that monitors the application.

We will use the OnRemove event of the WindowList object. The OnRemove event fires whenever an application window (this means every Window that produces a tab in the Windows task bar) is removed. We assign a function to the OnRemove event, in this case also named OnRemove.

That function receives a parameter that is a WindowInfo object and includes information about the window that has just been closed. We use the ItemText property of that object to check if the window title of the window that has just been closed is from the monitored application. If that is the case our application has just been closed and we need to start it again, for that we call the function we already created that start our application. The code for all this looks as follows:

SiteKiosk.WindowList.OnRemove = OnRemove;

function OnRemove(skwin){
    if(skwin.ItemText === "WindowTitleOfApplicationToWatch"){
        StartMyApp();
    }
}

Depending on the speed of the process to start SiteKiosk and the application at the same time or the time the application needs to fully close, the application may not have the focus or start at all. To prevent this from happening we can add a slight delay to starting the application, you may need to test what the best timing is for your individual application. We add the AddDelayedEvent method of the Scheduler object to our controlapp.js script at all the places we want to start the application:

SiteKiosk.Scheduler.AddDelayedEvent(5000, StartMyApp);

We are done. When we put the parts together the complete code of our script looks like this:

SiteKiosk.WindowList.OnRemove = OnRemove; //fires if a window has been closed
SiteKiosk.Scheduler.AddDelayedEvent(5000, StartMyApp); //starts the desired application the first time after 5000 ms

function StartMyApp(){
    SiteKiosk.ExternalApps.Run("c:\\windows\\notepad.exe", true);
}

function OnRemove(skwin){
    //checks if the application that should run has been closed
    if(skwin.ItemText === "Untitled - Editor"){
        //the application has been closed, restart it again
        SiteKiosk.Scheduler.AddDelayedEvent(500, StartMyApp); //starts the desired application the next time after 500 ms
    }
}

Save the code as controlapp.js (or whatever name you prefer) and make sure to put that file into the ..\SiteKiosk\html\ folder.

Now open the SiteKiosk configuration tool and create a new configuration. Set a password, set the background.html file as your start page and then go to Browser Designs, click on Fullscreen and set SiteKiosk to use the permanent fullscreen mode. Still under Browser Designs click the Advanced button and add the conrolapp.js file as an external script (optional: on the same configuration page tick the option to 'Keep the SiteKiosk main window in the background').

Save the configuraion and test the script.

 

Another possibility is creating an external script that checks if the application EXE process is running in regular intervals.

For this you basically need the following methods:
- AddPeriodicEvent Method: http://www.provisio.com/helpconsole/SiteKiosk%20Object%20Model%20Help/en-US/default.htm?scheduler_addperiodicevent_mth.htm
- IsProcessRunning Method: http://www.provisio.com/helpconsole/SiteKiosk%20Object%20Model%20Help/en-US/default.htm?externalapps_isprocessrunning_mth.htm
- Run Method: http://www.provisio.com/helpconsole/SiteKiosk%20Object%20Model%20Help/en-US/default.htm?externalapps_run_mth.htm

The following example script will check if the “notepad.exe” process is running every 30 seconds (30000 ms).
If it is not running it starts notepad.exe again.

evtid = SiteKiosk.Scheduler.AddPeriodicEvent(30000, checkExecution);

function checkExecution(eventID){
   if (SiteKiosk.ExternalApps.IsProcessRunning("notepad.exe") == false){
    SiteKiosk.ExternalApps.Run("C:/Windows/notepad.exe", true);
    SiteKiosk.Logfile.Notification('Application started');
    }
}

Smooth animations on Android

SiteKiosk for Android offers secured browsing preventing any misuse that could mess up your tablet configuration. But it's not only browsing that you can secure with SiteKiosk, also self service applications like for example menus, info terminals or customer surveys can be (and should be ;) run with SiteKiosk. An additonal advantage: you can use the powerful SiteKiosk Object Model to have even more control as normally possible with HTML pages. As I mentioned in an earlier post you can have access to local files via the sk:// protocol for example. We are adding more and more useful functionality to the Object Model in the future, so watch out for new versions. You can also post a comment here stating what you'd like to have us added to the SK Object Model.

Speaking of self service applications we realized early in our development process that android tablets are capable of many things, but still not comparable to desktop computers. Especially the browser component is a difficult story, since on one hand it supports many HTML5 features already (which is fantastic), but on the other hand still has some problems concerning completeness and performance of these new features. So you have to be a bit careful if you program web applications targeting android devices.

One example would be animations. Ever since JavaScript was introduced to the browser world, it has been used to program animations for web pages. Still it is widely used for that purpose on many pages and doing it quite well at least on desktop computers. Concerning Android, doing animations (like transitions) in JavaScript is not the best thing to do (even for desktop computer, but goes unnoticed most of the time). Say you want to create a sliding animation of a particular div containg some content that need to be exchanged when the user pressed a "next" button. You could use JavaScript's setInterval() and periodically update the div's left parameter. Unfortunately this results in poor results since the animation can be jerky on many Android tablets. A better way to do it is using CSS transforms and transitions. These will be hardware-accelerated even on Android tablets and therefore a lot smoother than JavaScript animations. 

An example would be:

<div style="-webkit-transform: translate(-600px, 0px); width=600px">Your content.</div>

This moves the div 600 pixel to the left relative to its normal position. Nice, but still no animation, right? Here you go:

<div style="-webkit-transition-duration: 500ms; -webkit-transform: translate(-600px, 0px); width=600px">Your content.</div>

Adding the "-webkit-transform-duration" will result in transition animations every time you change the "-webkit-transform" value. Obviously the transition will take 500 ms in this case. So Adding these two style properties results in a sliding animation moving the div from right to left by 600 pixels. There are a bunch of other transforms you can use for transitions like rotation, scaling and skewing. You could also use transitions for normal CSS style properties like "margin-left", but these might not be hardware-accelerated, so be aware.

Manipulation these style properties in JavaScript is not a big deal, but can be a bit cumbersome. My adivce is to use the free Move.js which makes adding these transitions dynamically very easy.

 

SiteKiosk Android: access the local file system via the "sk://" protocol

SiteKiosk Android has been out now for a (short) while and we've already gathered important feedback. We've learned that customers want to go beyond what is possible in a normal browser, which makes perfect sense given the fact that SiteKiosk for Windows already provides such possibilities to a great extend.

Accessing arbitrary local files is not allowed in a normal browser with pages coming from a server. This makes sense because security would otherwise be compromised. But sometimes you need to access large image or video files from a page and downloading these files from a server and relying on the browser to cache for example mega or even giga bytes of data doesn't seem very feasible.

So with the release of SiteKiosk Android 1.1 we proudly present: the "sk" protocol. Using "sk://" as a prefix for your URLs allows you to address files in a particular location on your Android device. When connecting the device as a USB drive, this particular location is a folder named "SiteKiosk" directly inside the root folder of the drive. The HTML pages you load in SiteKiosk don't have direct access to this folder but instead to a subfolder named "data".

So suppose you want to show a local image named "test.jpg" in one of your pages in SiteKiosk. Here is the HTML snippet for the image you could use in order to achieve this:

<img src="sk:///data/test.jpg"></img>

Notice the three (!) slashes after the "sk:", the last one stands for the sk root folder and is mandatory (meaning it doesn't work if you forget to write it). The image "test.jpg" must be located in "SiteKiosk/data" (relative to the root of your Android USB drive). Important: you have to create both folders "SiteKiosk" as well as its subfolder "data", so don't be confused if you don't find them after installing SiteKiosk (we may add the creation of these folders to the installation process in a future version).

You can use these "sk" URLs with the 'src' attribute of image, script and link tags at the moment (further support might be available in one of the next versions). Make sure the "Enable SiteKiosk scripting" option is enabled for your page, if you restrict the surf area.

If you have any problems using this feature or have other suggestions, comments, etc., please write a comment or contact us via our web page.

Using SiteCaster offline

One may think that everthing is connected to the internet nowadays: PCs, Tablets, Smartphones and even refrigerators. But there are still terminals that have no internet or other network connection. SiteKiosk can be used on these machines without a problem. You can show your users local HTML pages that don't require an internet connection. With SiteCaster things are a bit different. Creating campaigns, scheduling and publishing them normally requires a SiteRemote account and a license for each machine. This is without a question the preferred way to bring your content to your terminals.

But some scenarios are a bit too simple to justify the use of such a content management and distribution system. Here I will describe how you can use SiteCaster to play your content, without requiring SiteRemote. 

I am assuming here that you use SiteKiosk 8.1 and want to show a video in the SiteCaster area (either in split screen or fullscreen mode) . The first thing you have to do is switch SiteCaster to offlline mode so that it doesn't wait for a broadcast to be distributed but instead play a local broadcast. In order to do that you need to locate the SiteCaster configuration file named "SiteCaster.config". In Windows 7 and Windows Vista you can find it here: C:\ProgramData\PROVISIO\SiteCaster\. In Windows XP you have to look in this location: C:\Documents and Settings\<your account name>\Application Data\PROVISIO\SiteCaster. Notice that from now on I will mention every path as it appears under Windows 7 with default settings. The paths could be different, if for example your system drive is not c: or when using Windows XP. 

Open the file in Notepad (or your preferred text editor) and make sure the following line appears inside the section SiteCasterPlayerConfigurationData:

<UseOfflineBroadcasts>true</UseOfflineBroadcasts>

The important thing is that the value inside the tag is "true", after a fresh install of SiteKiosk it is set to "false" .

Save the file and the next time SiteCaster starts, it will look in a special location for offlline broadcast data. This location is "C:\Users\Public\Documents\SiteCaster\OfflineBroadcastData" (again for Windows 7 and Vista). You have to create the folders in this path if they are not already present. After you've done this, create another folder, inside OfflineBroadcastData, named ".SiteCasterBroadcasts". This is a bit tricky in Windows Explorer, because it normally doesn't let you create a folder with a name beginning with a dot. But naming it ".SiteCasterBroadcasts.", with an additional dot at the end (that will be automatically removed), will do the trick. Ask your local Microsoft consultant for an explanation why this is necessary ;)

In this folder you have to save the XML file that is attached to this post. It describes the structure of the broadcast that should be played when in offline mode. After you've saved it in this folder, open the XML file in a text editor. You need to find and change the file path for the video that should play:

<MediaFile>
...
<Path>/nature.wmv</Path>
...
</MediaFile>

Replace "nature.wmv" with the file name of your video. This file should then be placed (or copied) into the folder "C:\Users\Public\Documents\SiteCaster\OfflineBroadcastData". There is more to do, you have to set the duration of the video. Find the first occurence of this section:

<EndCondition>
...
<OffsetInSeconds>0</OffsetInSeconds>
...
</EndCondition>

 

 Change the "0" to the duration of your video in seconds, for example "120", if the duration is 2 minutes.

Two more changes and you should be ready to go. Find these two sections and change in each one the width and height to the dimensions of your video:

 

<Section>
	...
	<Width>800</Width>
	<Height>600</Height>
</Section>

  
<Layout>
	...
	<Width>800</Width>
	<Height>600</Height>
</Layout>

 

Save the XML file and you should be done. In the configuration tool you have to enable SiteCaster, either as a split screen setting or fullscreen. The next time you start SiteKiosk, the video should appear in the SiteCaster area.

You can do more than just play a video over and over again. If you want to show a picture, there is just one thing you have to change in comparison to the video and that is <ItemKind>Video</ItemKind> to <ItemKind>Picture</ItemKind> (just search for it, it should only appear once). You can even play files sequentially and on differents channels, but this requires a deeper understanding of the XML format used here.

In case you want to do something more complex, it might be a better idea to use the  SiteCaster online editor in SiteRemote, publish the broadcast created there to a client machine of your choice and grab all the files from there. All necessary files are normally located in the folder right beneath C:\Users\Public\Documents\SiteRemote\Sync\. The name of this folder is either "{1D3F97EE-F5E6-4E81-ABF8-F7754638833E}", if SiteCaster has already been playing the broadcast, or it is the name of the broadcast plus a short postfix starting with "_", for example "SiteCasterOfflineBroadcast_123". Anyway there should be only one folder there normally, so the decision should be easy ;) You should copy the content of this folder (not the folder itself!) to "C:\Users\Public\Documents\SiteCaster\OfflineBroadcastData". Remember to edit the file SiteCaster.config to set the SiteCaster offline mode as described above.

SiteCasterSingleVideoOfflineBroadcast.xml (5.72 kb)

Customizing the Portal Startpage

Of all designs/start pages that come equipped with SiteKiosk, the start page called "Portal Startpage" is one of the most popular ones. The major reason for that certainly is, that it covers a very common use case: the user can choose from a list of topics to proceed to a detail page that shows the relevant information. SiteKiosk users can already configure which links are to be shown, in which order and the corresponding icons as well as a suitable color scheme, background image  and several other options in the configuration program. For many cases this is already all that is needed, but sometimes you might need more control over the layout or visual appearance of the page.

All you need to know to get more control is how to open a file in an editor (for example Notepad), edit some text in it and save it.

The example I want to show here is how to set a solid background color instead of the default gradient background image. The file you need to change in order to accomplish this is located here C:\Program Files\SiteKiosk\Skins\Public\Startpages\Portal (depending on your system or the installation path you've chosen, it can be in a slightly different location) and it's called Start.html.

Before you proceed, as always, I recommend to first make a backup of the files you edit. To do that, select the file in the  Windows Explorer, choose "copy" from the context menu, right click on an empty area and choose "paste" (shortcut for that is CTRL + c for copy and CTRL + v paste).

Now open "Start.html" in a text editor, you can for example use Notepad ++ which is more comfortable or Notepad that comes with Windows. Search the line that starts with the following text and delete the complete line:

<img id="id_Background" ...

You can save the file now and run SiteKiosk to check the result. Notice that if you try to save the file directly under Windows Vista or Windows 7, it won't let you, because the file is located in a sub folder of your program files directory where you need more rights to write a file than the you have in the text editor. To work around this, you can copy the file to a different folder, make the changes and copy back to the original folder. Or you can start the text editor with administrator rights by right-clicking the program and choosing Run as Administrator from the context menu. 

In SiteKiosk you should see the portal startpage with a white background. This is the standard color if nothing else it specified, so if you like white, you are already done. If your page is about nature you might prefer green, then a little bit more has to be done.

Search for the line which starts with: <body, this is the tag that contains all content of this page . Inside this line, find style="..." (the style attribute) which defines the appearance of the page-body. Here you can add the color that should be used for the page-background. An example that sets the background color to green would be:

<body onselectstart="return false;" onload="Init();" style="margin: 0px;background-color: green">

Try not to change anything else from this line, just add background-color: green to the style attribute. This is because the code of this page could change in the next version of SiteKiosk.  Which values can you set for the background color? You can specify color names like above, check for example this page for a list of them: http://www.w3schools.com/html/html_colornames.asp. You can also specify color codes in RGB format, starting with a # (explained for example here http://www.w3schools.com/html/html_colors.asp). 

So now you can change the background color of the Portal Startpage. What else can be done? Everything that can be done in HTML/CSS/JavaScript and with the help of the SiteKiosk object model even more (for example accessing payment devices, browser windows, etc.). Check this blog for more examples in the future. 

Customize the SiteCaster Player in SiteKiosk

SiteKiosk (version 8.0 and higher) offers the possibilty to embed a SiteCaster player into an HTML page. You can then use this page as, for instance, a start page in SiteKiosk. If you only want to play your Digital Signage campaigns as scheduled in full screen, you can simply choose SiteCaster to play full screen in the SiteKiosk configuration tool under Start Page & Browser -> Digital Signage and you are ready to go.

If you want more control over the player, for example play certain campaigns in reaction to an event (like a button click), this is also possible, but requires a small portion of JavaScript in your page. I will describe here as an example how you can build a SiteCaster start page to play a certain campaign whenever the user clicks a button on the page.

First let's have a look at the basic HTML structure of a SiteCaster full screen start page. Please create a file named "SiteCasterCustom.html" and save it to the folder {Program Files}/SiteKiosk/Skins/public/Startpages/SiteCaster/ (the path to {Program File} depends on your installation of Windows). In the SiteKiosk configuration tool, set this file as the start page for SiteKiosk then.

<!DOCTYPE html>
<html>
<head>
</head>
<body scroll=no style="overflow:hidden; margin: 0; border: 0;">
	<object id="player" classid="clsid:719D9061-22DA-4D25-9BB9-116404372496" style="width: 100%;
		height: 100%; background: transparent;">
	</object>
</body>
</html>

This is just a standard HTML page with one object tag in the body (which has some styling to get rid of margins and border). This object tag embeds the SiteCasterPlayer into the page, so this is essential. In order to make some room for our button, we set the height of the object tag to "700px", so on a 720p screen (1280x720) we have 20 pixels left for the button. When we've added the button, the page looks like this:

<!DOCTYPE html>
<html>
<head>
</head>
<body scroll=no style="overflow:hidden; margin: 0; border: 0;">
	<object id="player" classid="clsid:719D9061-22DA-4D25-9BB9-116404372496" style="width: 100%;
		height: 700px; background: transparent;">
	</object>
	<button id=playButton>Play it!</button>
</body>
</html>

This is our markup for this example, now we add a script to achieve the event handling. First we need to load a script that exposes the SiteCaster player functionality in a convenient way. This script in turn requires one other script that should be included before with a script tag.

<!DOCTYPE html>
<html>
...
	<button id="playButton">Play it!</button>
	<script src="../../External/require.js"></script>
	<script>
		require.config({
			baseUrl: "../.."
		});
		require(['Scripts/SiteCaster'],
				function (context, siteCaster) {

					var player = siteCaster.Player();

					player.broadcastLoaded(function () {
						
					});
				});
	</script>
</body>
</html>

At first glance this might seem a bit overly complex, but it is actually quite simple. The SiteCaster script (which has the file name SiteCaster.js) is using an API called RequireJS (http://requirejs.org) to load dependent scripts, so require.js has to be loaded first (this is the first script tag). After that the RequireJS functionality can be used.

RequireJS first needs a base URL to properly resolve the script paths, so we set it by using the require.config function. This base URL must point to the directory where the two folders "Scripts" and "External" reside. Going from the folder where the standard SiteCaster start page is located, this is two levels up (../..). 

Next we can call the require function itself to load our dependent scripts (in this case it is only SiteCaster.js). It excepts as a first argument an array of script paths that should be loaded. Going from the set base URL, the path to SiteCaster.js is "Scripts/SiteCaster". The file extension ".js" must be omitted, otherwise RequireJS will interpret the name differently.

The second argument is a function that will be called when all dependent script have been loaded. The first parameter to this function is a context object which we don't need here. The second is the siteCaster object that we will use.

Now that we have the SiteCaster object, we can ask it to give us a Player object. Since there can be more than one player on the same page, the ID of a specific object tag can be provided as an argument, but in this case we have only one and we let the SiteCaster script find it automatically. One last thing is missing before we can begin to use the player functionality: we have to make sure the player has loaded the active broadcast. So we set a function that is called when this happens with broadcastLoaded.

Inside this last function we now have full control over the SiteCaster player. In this example we want to play a different campaign, whenever the user clicks a button, so we set the onClick function of the button to a new function. Inside this onClick handler function, we need to find a certain campaign of the current broadcast and call play with it. So we call getCampaignItems() to get all campaign items of the currently playing broadcast. We assume here that the broadcast contains a campaign item with the name "ClickCampaign", which we want to play now. 

 

require.config({
			baseUrl: "../.."
		});
		require(['Scripts/SiteCaster'],
				function (context, siteCaster) {

					var player = siteCaster.Player();

					player.broadcastLoaded(function () {
						playButton.onclick = function () {
							var campaignItems = player.getCampaignItems();
							var i = 0;
							for (; i < campaignItems.length; ++i) {
								if (campaignItems[i].Name == "ClickCampaign") {
									player.play(campaignItems[i]);
								}
							}
						}
					});
				});

As you can see, we just loop through all campaign items until we find the one with the correct name and play it. The item will play once and after that the normal schedule will take over again. If you want to play the Campaign multiple times in a row, you have to play it again, when it ends. The code for that would like like this (only the onclick handler):

playButton.onclick = function () {
	var campaignItems = player.getCampaignItems(),
		i = 0,
		playCount = 0,
		clickCampaignItem;

	for (; i < campaignItems.length; ++i) {
		if (campaignItems[i].Name == "ClickCampaign") {
			clickCampaignItem = campaignItems[i];

			player.campaignEnd(function (id) {
				if (id === clickCampaignItem.Id && playCount < 4) {
					player.play(clickCampaignItem);
					playCount += 1;
				}
				else
					player.setAutoSchedule(true);
			});

			player.setAutoSchedule(false);
			player.play(clickCampaignItem);
		}
	}
};

Note that we call player.setAutoSchedule(false) to switch off the scheduled playing of the broadcast. This way we get complete control and scheduled (not disabled) campaigns won't kick in in between. After our click campaign has played four times we call player.setAutoSchedule(true) and campaigns are played according to the set schedule again (the ones that are not disabled). 

The complete HTML file containing the example script is attached to this entry, so if you have SiteKiosk 8 installed and want to try it out, just save it into the folder  {Program Files}\SiteKiosk\Skins\Public\Startpages\SiteCaster and set this as a start page in the SiteKiosk configuration tool. Make sure you create at least two campaigns in your broadcast and disable one of them (the one you want to play when the button is clicked) under "Schedule" in the SiteCaster tab in SiteRemote.

 

SiteCasterCustom.html (1.36 kb)