Browsers get used in many different environments. Today, I take a look at scenarios where there’s either no interactive user (digital signage) or a potentially malicious user (internet kiosks).

Digital Signage (fullscreen) Requirements

In the Digital Signage scenario, there’s a full-screen webpage rendering and there are no user-accessible input devices– the canonical example here would be an airport’s signage displaying arriving and departing flights and their associated gates.

Supporting this use-case is relatively easy– the browser must be full-screened, and it must avoid showing any sort of prompt, tip, hint, or feature that requires dismissal because there’s no guarantee that a mouse or keyboard is even plugged into the device.

In this scenario, the browser is typically used to load only a specific website, which itself must be carefully coded not to prompt the user for any input. Additionally, either the webapp must request a wakelock, or the OS must be configured to let the computer sleep or hibernate. Similarly, the OS must be configured not to prompt the user for input or show modal dialogs (OS update prompts, etc).

Kiosk (public-browsing) Requirements

While supporting digital signage is reasonably straightforward, providing a true internet kiosk is considerably harder. The set of potential customer requirements is much broader– some kiosk owners want to allow the user to browse anywhere and download any files, etc, while other kiosk owners want to tightly lock down the experience to a small number of supported web pages. Making matters far more complicated, in some kiosk scenarios we cannot assume that the user is well-intentioned– they might want to abuse their access or even hack the kiosk itself. Computers are relatively less protected against malicious local users.

Generally, an interactive kiosk aims to offer a few capabilities:

• Allow the user to load one or more webpages, filling out forms or performing search queries
• Offer most of the “digital signage” behaviors (e.g. avoid prompting the user with announcements, requesting that they explore new features, log into the browser itself)
• Prevent the user from navigating to arbitrary sites
• Prevent the user from tampering with loaded web app(s) using the Developer Tools
• Prevent the user from exiting the browser or modifying its persistent state
• Prevent the user from gaining access to the underlying OS to run other programs or modify persistent state

Of these, preventing access to underlying OS is the most critical, because if a malicious local user can execute commands in the OS, they can typically defeat all of the other restrictions intended for the kiosk.

Way back in my past life, I was the Security PM for Internet Explorer. At the 2008 Hack-in-the-Box security conference, my session on IE security improvements was preceded by a packed session wherein the presenter walked through two dozen popular “Kiosk browsing” software packages, breaking out of each to get access to the underlying system in under two minutes. Applause ranging from enthusiastic (for clever hacks) to bemused (for silly hacks) followed each attack.

Edge’s Kiosk Mode

Microsoft Edge offers a kiosk mode which can be simply activated by starting msedge.exe with the --kiosk command line argument. By default, this starts Edge with a full-screen InPrivate window with no address bar, no context menus, various hotkeys (like F12) disabled and so on. It’s a fine approach for something as simple as digital signage. But if you want to build a true kiosk, you’ll want to set some more options.

There’s a great documentation page on Configuring Edge Kiosk Mode that explains the various scenarios and configuration options. As explained on that page, one of the key things you’ll want to do is enable the Windows 10 “Assigned Access” feature so that Windows is locked down to limit the user to only the designated scenario.

You’ll likely also want to set a bunch of other Microsoft Edge policies to tighten things down.

Start with the Kiosk Mode Settings policies, then look at more general policies.

For instance, you probably want to use the URLBlocklist policy to block all URLs (e.g. a rule of *) and then use the URLAllowlist policy to exempt only those URLs patterns (e.g. https://example.com/app) that you wish to support. This helps prevent users from using the browser to browse the local file system (file:///c:/), from viewing web page source code (e.g. via CTRL+U), and from launching installed applications via App Protocols. Similarly, you may wish to restrict what a user can download, or configure downloaded files to be deleted on exit.

One very common vector for abusing kiosks is to use the File Picker dialog shown when the user hits Ctrl+O or pushes the Choose file button on a file upload control. The File Picker dialog is provided by Windows and by default exposes the ability to download URLs, navigate the local file system, and even launch files. This dialog can be blocked by disabling the AllowFileSelectionDialogs policy, with the obvious caveat that doing so will block any web app scenario that requires the user upload a file.

In some cases, you might want to prevent the user from using a Microsoft Edge hotkey that is not otherwise restricted. To implement such a restriction, you can use a Windows Keyboard Filter, with the caveat that the restriction will block the hotkey(s) across all of Windows.

Extreme Lockdown

In extreme cases, you might decide that you don’t want a browser at all. In such cases, building a simple Win32, .NET, or UWP app atop the Microsoft Edge WebView2 control might be your best bet, because you’ll have more complete control of the behavior of the application, with the Edge engine rendering your content under the hood.

-Eric