This is unofficial document.
The Device Information API enables web applications to get the device-specific information, such as hardware serial number, manufacturer name, model number. This API is supposed to be used mainly for digital signage terminal, such as TV sets or STBs embedding a web-runtime. But the usage of this API does not limit to digital signage terminal. This API could be used for various embedded devices.
Some Web-based Signage terminal devices implement UPnP (Universal Plug and Play). Other devices also implement some kind of method to expose such information. In either case, Web-based Signage terminal devices have their own information similar to the device description specified in UPnP Device Architecture. Therefore, this API exposes device information similar to the device description of UPnP Device Architecture. [[UPNP-DEVICEARCH20]]
Digital signage operators manage a lot of signage terminals remotely. The terminals are located in a big area around, such as a big building, a large event site. For some situations, the terminals are located in a city, nationwide area around. Once the terminals are installed, the operator has to manage them remotely.
Just like network administration (remotely managing routers, hubs, PCs, and so on), the signage operator has to know the device-specific information (hardware serial number, etc.), network information (IP address, etc.) remotely in the purpose of terminal administration.
Such information is used for not only terminal administration but also terminal authentication. Most of signage management system limits the number of terminals allowed to be managed. The signage management systems require some kind of device-specific information in order to prevent to be connected by unlicensed number of devices. For the purpose, the device-specific information is required in signage systems.
In the architecture of Web-based Signage, signage service operators remotely control signage terminals, contents, etc. Though many people pass in front of a Web-based Signage terminal, they can just watch the content basically. In this context, the user of the browser is a signage service operator or an owner of the device, not passing-by persons. Therefore, the term "user" means a signage service operator or an owner of the signage terminal device in this document. But for the avoidance of confusion, the term "signage service operator" is used as "user" in this document.
In most W3C specification, a web browser is called as a "user agent". Commonly, hearing the term "user agent" or "web browser", most of people tend to imagine a general web browser which can access arbitrary web pages. Web-based Signage terminal devices don't use such so-called "web-browser". Web-based Signage basically access to only contents managed by the signage service operator or the owner of the device. Besides, no address bar, no status bar, no menu is shown on the display. Any persons in front of the Web-based Signage terminal device can not access to any web page they want to see at all. Therefore, the web browser used in the Web-based Signage terminal device is called as "web-runtime" in this document in order to separate from general web browser we always use in a PC, a smartphone, and so on.
The JavaScript code below shows the usage of this API:
navigator.device.getDeviceInformation().then((deviceInfo) => {
console.log(deviceInfo.friendlyName); // e.g. "HAPPY TV 803 42 inch"
console.log(deviceInfo.manufacturer); // e.g. "ABC Corporation"
console.log(deviceInfo.modelDescription); // e.g. "ABC 4K LCDTV 2016"
console.log(deviceInfo.modelName); // e.g. "HAPPY Series"
console.log(deviceInfo.modelNumber); // e.g. "HP803S42-2016"
console.log(deviceInfo.serialNumber); // e.g. "0123456789ABCDEF"
}).catch((error) => {
console.log('[ERROR] ' + error.message);
});
The information obtained from this API is generally used for the signage terminal management of the signage system. Especially, the serial number is important for the signage system to identify the terminal. In most cases, the information is sent to the signage system using XMLHttpRequest, Fetch API, or WebSocket. The JavaScript code below shows how to send the information to the signage system using Fetch API. [[XHR]] [[FETCH]] [[websockets]]
navigator.device.getDeviceInformation().then((deviceInfo) => {
var data = new FormData();
data.append('name', deviceInfo.friendlyName);
data.append('serial', deviceInfo.serialNumber);
return fetch('https://signage.example.jp/device', {
mode:'cors',
method: 'POST',
body: data
});
}).then((response) => {
return response.json();
}).then((json) => {
console.log('Done!');
}).catch((error) => {
console.log('[ERROR] ' + error.message);
});
In this section, the architecture of Web-based Signage is described at first for the purpose of considering potential risks for Web-based Signage. Then the potential risks for Web-based Signage are listed, lastly the ways to protect security and privacy are proposed.
A Web-based Signage consists of a web-runtime, a JavaScript player, and contents. Generally, Web-based Signage terminal devices implement a web-runtime. The JavaScript player is just a web application from a viewpoint of the web-runtime. The JavaScript player consists of HTML, CSS, JavaScript. The JavaScript player fetches playlists from the pre-defined URL of the CMS (Content Management System), then it fetches contents to play (images, videos, HTML contents, etc.) based on the playlists.
There are two types of architecture in terms of running a JavaScript player on a web-runtime:
In the hosted app architecture, the JavaScript player is hosted on a server. Generally, the terminal of this architecture has to be set an initial URL which the web-runtime is supposed to access when the terminal is turned on. The initial URL is set by the terminal owner or the signage service operator. This mode is called initially-access-preset-url mode in this document. In the packaged app architecture, the JavaScript player is packaged in an packaged app. The packaged app is installed in the application platform of the Web-based Signage terminal device. That is, the JavaScript player hosted in the device. In this architecture, the initial URL points to a local HTML file packaged in the packaged app, which is run at first when the packaged app is started. Besides, all HTML files packaged in the packaged app have the same origin as the initial URL. Basically, this architecture is always in the initially-access-preset-url mode.Hosted app architecture
Packaged app architecture
iframe elementWeb-based Signage runs or plays contents managed by signage service operators. Particularly, the JavaScript player is trusted. But the JavaScript player runs or plays a lot of contents, such as images, videos, HTML contents. An Image or a video is not harmful in itself because it is not scriptable. What could be harmful is a HTML content.
Basically, since HTML contents as signage contents are managed by a signage service operator, they should not be harmful in most of situation. But signage service operator could set a 3rd party HTML content as a signage content by mistake or intentionally. If the 3rd party HTML content is malicious, it could get the device information through this API and send the information to the 3rd party's server.
Such 3rd party HTML contents are supposed to be run in the iframe element generated by the JavaScript player. In order to prevent this risk, this API must be exposed only to the JavaScript player. [[!HTML]]
If a HTML content managed by the signage service operator navigates to a web page which has a different origin from the initial URL, the Web-based Signage terminal device could be exposed to risk because the page is not uncontrollable by the signage service operator. Especially if the top-level browsing context is taken over by a malicious page, tremendous negative impact could cause.
To prevent this risk, this API should be exposed only to the same origin as the initial URL.
One of the possible use case of this API is to send the result of this API to the signage management system using XMLHttpRequest or WebSocket. If the network connection were not secure, the message in the connection could be eavesdropped. Though this API is not able to prevent the eavesdropping directly, it could be indirectly.
In order to mitigate this risk, this API should be available only in a secure context, so that XMLHttpRequest or WebSocket connection is forced to be a secure connection. [[!powerful-features]]
This API MUST NOT be exposed in general web browsers which can run arbitrary web contents because of security reasons. This API MAY be available only when the all conditions as follows are met:
Besides, if the device runs a packaged app, the API MAY be available only when the packaged app is privileged to use the API by some kind of app authentication mechanisms provided by the underlying application runtime. The app authentication is not defined in this specification.
Most of existing Web-based Signage terminal devices have a mechanism to get the device information. For now, such devices exposes the feature in a proprietary way as an asynchronous mechanism. Therefore this API is designed as an asynchronous method, so that Web-based Signage terminal device manufacturers implement this API in their web-based platform in a way that allows them to take advantage of their existing proprietary mechanisms or allows them to provide this API through their official JavaScript library.
Navigator interface
[Exposed=(Window)]
partial interface Navigator {
readonly attribute DeviceInformation device;
};
[Exposed=(Worker)]
partial interface WorkerNavigator {
readonly attribute DeviceInformation device;
};
The device attribute, when getting, returns an object that implements the Device interface.
I'm not sure this attribute name "device" is appropriate. Other candidates I come up with are "tv", "signage", "embeddedDevice".
Device InterfaceThe Device interface provides a means to access information about the device-specific information which the web runtime is currently using.
[Exposed=(Window,Worker)]
interface Device {
Promise<DeviceInfo> getDeviceInfo();
};
The getDeviceInfo() method, when invoked, MUST return a new Promise and run the following steps: [[!ECMASCRIPT]] [[!PROMISES-GUIDE]]
DeviceInfo object using the fetched device information.DeviceInfo object.DeviceInfo Interface
interface DeviceInfo {
readonly attribute DOMString friendlyName;
readonly attribute DOMString manufacturer;
readonly attribute DOMString modelDescription;
readonly attribute DOMString modelName;
readonly attribute DOMString modelNumber;
readonly attribute DOMString serialNumber;
};
friendlyName attribute MUST return the short description of the device. This value is mainly used to indicate this device for the signage service operator. This value MUST NOT an empty string.manufacturer attribute MUST return the manufacturer's name. This value MUST NOT an empty string.modelDescription attribute MUST return the long description, if the device has one, or the empty string otherwise.modelName attribute MUST return the model name of the device. This value MUST NOT an empty string.modelNumber attribute MUST return the model number of the device, if the device has one, or the empty string otherwise.serialNumber attribute MUST return the serial number of the device. This value MUST NOT an empty string.