404 Tech Support

Using Google Chrome to create a kiosk

A recent task that came across my desk included the sysadmin side of setting up a public-use kiosk. The web developers would handle everything regarding the kiosk experience but it was my responsibility to ensure the environment was secure and controlled.

The web developers preferred to use Google Chrome to allow them to use more HTML 5 functionality and better transitions with their navigation. While Internet Explorer tends to be the browser of choice when it comes to locking down a web environment, I was fine with giving Chrome a shot to see what we could do. Along with a .msi installer, Chrome provides administrative templates for controlling the Google Chrome experience in an enterprise environment.

I combed through the policies to set anything for the user that would allow them to make a permanent change. I changed the homepage to the kiosk site and the startup behavior. Chrome allows you to set an easy blacklist of domains not allowed to visit and whitelist domains that are allowed. I used a wildcard to block all sites and then whitelisted the exceptions for the kiosk site and related external resources like typekit and the JWPlayer.

After the policies, the biggest thing was launching Chrome properly. For full-screen, I used the parameter –kiosk. Depending on how the system was shutdown before, it might try to launch previously opened windows to recover the session. There were also startup messages that would show up every once in a while. To avoid that, I used incognito mode and launched the browser with the –incognito switch and followed it with the website so the browser would start at that address.

“C:Program Files (x86)GoogleChromeApplicationchrome.exe” –kiosk –incognito http://www.404techsupport.com/

As I would find out through a Chromium bug report, –kiosk is not actually for a “kiosk” setup. The developers refer to it as “ChromeOS retail store demo mode” so a ChromeOS device could be showed off in stores. It seemed to work well for the Kiosk role on Windows 7 but was a little lacking in true kiosk restrictions. With only the touch-capable monitor (no keyboard or mouse), you could hold to right-click or tap with two fingers to get the context menu. With that available, you could make the kiosk look ugly by viewing the source in a new tab which you can’t close, you could choose inspect element which reduces the look of the kiosk, and worst of all, you could try to save the page to the local hard drive which would then allow you to browse around the system and possibly launch other programs.

The user is a standard user and I used other group policies to tighten down the environment and permissions. Even if you can browse the system, you can’t escape the user profile and you can’t even save the files there. The web developers added Javascript to the pages to disable right-click. I was disappointed that the touch screen’s drivers nor Chrome offered the ability to disable right-click. I was able to remove it in Windows through the Touch and Pen Input Control Panel item but it seemed to come back in Chrome with its feature to allow tablet-like input.

All in all, Chrome worked out pretty well and the kiosk is a decent final product. My only hope is that Chromium developers don’t just discontinue the “kiosk” mode and could actually increase its functionality by allowing more switches to enable/disable right-click functionality and even keyboard shortcuts.