Transfer a URL from a Kiosk to Another Device with a QR Code

This entry describes how you can generate a QR code from the web page displayed in the browser using a script. The QR code can e.g. be used to transfer the URL of the displayed web page to a smartphone. We start with the template empty and generate a browser with a webpage element. Double click on the webpage element and add the start URL https://www.sitekiosk.com/ .Then you create an image element next to the web page element. The image element must not overlap with the web page element, otherwise it will not be displayed. 

Now the image element must be adapted for the QR code display. To do this, you must start the expert mode by entering &expert in the URL address line and then pressing Enter to reload the project. 

Double-click on the image to open the image's properties dialog and press the Expert Edit button at the bottom left.

Go down in the properties dialog and add under Add property the setting qrCodeData with the value https://www.sitekiosk.com/ and the type auto. Then press the Plus button to add the setting.

Then go to the expert setting src and add the setting ,"fileName":"" after the entry "fillColor": "rgb(0,0,0)" value that it looks in the end like this:

{
  "fillColor": "rgb(0,0,0)",
  "fileName": ""
}

Save the settings. Select the image and assign the tag name qrCodeImage in the menu bar. 

Select the web page element and assign the tag name browser in the menu bar. 

Go to Settings - Content - Scripts and press the Add button. Give the script the name QRCodeUrlScript and add the following script lines:

siteKiosk.content.onContentInserted(() => {
	const qrCodeImage = siteKiosk.content.getElementByTag("qrCodeImage");
	const browserElement = siteKiosk.content.getElementByTag("browser").getDomElement();
	browserElement.addEventListener("page-finished-loading", url => {
		qrCodeImage.setPropertyValue("qrCodeData", url.detail);
	});
});

Save and publish the project. Now after changing the url in the webpage element, the displayed QR code will be automatically adjusted.

Changing the User Agent of the SiteKiosk Browser

The user agent string is used to identify the browser with which a client contacts a server. This information can be utilized to decide what kind of content is delivered to the client in return, to make sure the browser receives data that is optimized for exactly that type of browser. 

SiteKiosk uses the public WebBrowser control of the Microsoft Internet Explorer installed on the system. This means that SiteKiosk identifies itself with the same user agent string as the IE. When a standard configuration is used SiteKiosk will add SiteKiosk Version Number at the end of the user agent string, e.g. SiteKiosk 8.6.1251. A full user agent string under SiteKiosk will look like this:

Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SiteKiosk 8.6 Build 1251)

Adding SiteKiosk to the user agent can be used for example to let a server deliver SiteKiosk Object Model code to a client. You can deactivate this behaviour in the SiteKiosk configuration and you can also add your own identifiers. You can find more information on this topic here: http://www.provisio.com/helpconsole/SiteKiosk%20Help/en-US/default.htm?advanced_settings.htm#three.

Ideally the above means that your client browser receives the content it is supposed to display in the most suitable form. If a kiosk project is created from scratch, the content can be optimized to fit the kiosk. Even in projects where content has already been created, it will usually run without modifications on the kiosk, because the content has already been designed for usage in a standard browser like IE.

In some cases though, it might come in handy if your browser could pose as something completely different, for example in a kiosk project where touchscreens should be used. The web pages that should be displayed are already existing in a version for normal browsers and in a version for mobile phones. The mobile phone version would fit perfectly but the server dynamically delivers its content based on the user agent. This means on a normal Windows system you would get the version for standard desktop browsers and not the version for mobile phones. The solution is to completely change the user agent string to one of a mobile phone.

Microsoft already provides this option by means of editing the Windows registry using the registry editor (regedit.exe). Note that changing the registry is always done at your own risk. Making the browser pose as another may also cause script errors or corrupted page layouts. You should carefully experiment with the values described next before applying it to live systems.

The registry key we will have a look at is for the Internet Explorer, but as SiteKiosk is based on the Internet Explorer it also uses it. That means changing the key will change the behaviour for IE and SiteKiosk. A detailed article on the topic of the user agent string on Windows systems can be found here: http://msdn.microsoft.com/en-us/library/ms537503%28v=vs.85%29.aspx. The registry key can be found at two different locations in the Windows registry.

One location is under

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Note: on a 64-Bit system the location is slightly different

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Editing that key changes the behaviour for all users on the system.

The other location is under

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent

Editing that key only changes the behaviour for the current user. This means to edit this key you must be logged in with the user you want to change the behaviour for.

On most systems the above key only contains the default value HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Default). For the desired effect we need to add two additional string values (unless they are already there). One is called Platform and the other Version. As an example we will add the following data to Platform (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Platform)

Linux; U; Android 4.0.4;

and the following data to Version (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\User Agent\Version)

AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30

These are values an Android smartphone uses. When the changes are done, we can see the effect by opening the SiteKiosk browser (or IE, as both are using that registry key) and going to www.nytimes.com. With the changes we will be directly transferred to the mobile version of the page. The SiteKiosk user string now looks like this:

Mozilla/5.0 (compatible; AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30; Linux; U; Android 4.0.4;; Trident/5.0; SiteKiosk 8.6 Build 1251)

If the above workaround is suitable for your project and you want to spare yourself the hassle of manually editing the registry on all your kiosk systems, you can use the SiteKiosk ProgramPatcher tool to automatically apply the registry changes.

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.