Security in the Java TVTM API

This document describes the security model used in the Java TVTM API, including an overview of security in the JavaTM language, who assigns permissions in the Java TV API, and the permissions architecture.


The Java language's security model addresses permitting or denying access to resources, based on the source of the code requesting access. It is a tried and proven architecture that has benefited from years of experience. In computer workstations and personal computers, the "source" from which code comes is primarily determined by the site from which the code is downloaded (often a URL), or by a trusted signer who has signed the code.

The Java language's security model is readily applicable to interactive television and provides clear benefits. It allows a responsible party to reliably prevent classes of code from accessing resources that the code shouldn't need access to. For example, an advertising application can be prevented from changing the channel to a network owned by the advertiser, an application can be granted access to select only certain services (such as those within a bouquet), an application can be prevented from accessing the return channel, or it can be denied access to a users' in-home network. Providing a simple, reliable mechanism to deny such access provides important benefits, including cost reductions, particularly in a horizontal market.

It can be argued that applications could be exhaustively tested to ensure that they don't misbehave. However, such testing is expensive and difficult. The Java language's security model frees the broadcaster from some of this testing, by allowing it to establish a "sandbox," which constrains the actions of applications; the Java 2 Platform, Standard Edition (J2SE), security model allows that sandbox to be easily configurable so it can be expanded to fit the needs of a given application.

In the J2SE security model, permissions are expressed as subclasses of A method that detects the violation of a security constraint does so by throwing a java.lang.SecurityException. This is a subclass of java.lang.RuntimeException, but despite this, any method of the Java TV API that can exit due to a SecurityException must document this fact by:

The J2SE security model is described in depth in the book Inside Java 2 Platform Security by Li Gong, ISBN 0-201-31000-7.

For a horizontal market, the underlying platform security should be based on the J2SE security model. The Java TV API might, however, be applied in certain vertical markets that have modest security requirements. For platforms such as this, the permission classes described below will be considered optional if the underlying platform does not support the J2SE security architecture. For all platforms that support the J2SE security model, the permission classes are a required part of the Java TV API.

Who Assigns Permissions

Who is allowed to assign permissions is a critical issue. The Java TV API does not dictate the policy underlying permission setting. The model for who is trusted and who assigns permissions is an important part of the business model underlying a complete platform for interactive television. The Java technologies provide support for a variety of signing models, but it is ultimately up to the entity that specifies the complete platform to determine the model for granting permissions.

In a closed network where the set-top box is owned by the network operator, the responsible party would likely be the network operator. In a horizontal market, the answer is less clear, given the following considerations:

Java TV API Permissions Architecture

This section describes the permissions that exist for the Java TV APIs. In addition to these permissions, there are the permissions that exist in the underlying Java platform, and permissions for any other APIs that are defined as part of a complete platform.

In the Java TV API, many resources are accessed with a Locator. Locators are used to:

In many ways, a Locator is analogous to a file name in a computer file system. In computers, a file name is often associated with a hardware device, such as a printer and the screen ("prn:" and "con:" in DOS-based systems, and /dev/lp* and /dev/tty in UNIX systems). Associating permissions with files is a well established mechanism for restricting access to data files, hardware devices, and other resources in computer systems.

The Java language model for access to a file system is twofold: There is a file object (, which represents the path to an object in the file system, and there is a security check based on that name. In the J2SE security model, that security check is reified in the class A FilePermission contains a path (or a regular expression denoting a set of paths), and an action string. The action string can be read, write, execute or delete. In the JDK 1.1 security model, the same facility is exposed through a small number of check methods on java.lang.SecrityManager (checkRead(String), etc.).

The FilePermission object allows access to a set of files based on a wildcarding mechanism. A set of FilePermission objects may be combined to give any desired degree of access. For example, it is straightforward to construct a set of two permissions that gives code read-write access to one directory, and read-only access to a different directory. FilePermission is described in detail in Inside Java 2 Platform Security, section 3.6.4.

A mechanism similar to FilePermission is ideally suited to the needs of resources that are accessed via Locators. For example, consider the following set of permissions for an application:

This is analogous to the kinds of access that FilePermission grants. For this reason, important permissions in the Java TV API have a Locator in their constructor. Using a Locator in this way does not place any requirements on the internal representation an implementation maintains for a Locator. It does, however, imply a requirement on the signaling of permissions. Namely, a permission that relates to a given Locator needs to be signaled in such a way that the permission object can determine if it grants access for a given Locator. A signaling specification would probably define some kind of wildcarding scheme based on paths for Locators, to facilitate the natural expression of a set of permissions. For example, the Locator for a service might have a representation equivalent to "/service/physical/channel007" or "/service/logical/ESPN/TheDeuce". Doing so would allow logical wildcarding in the signaling of permissions.

The Java TV API does not mandate a particular format for Locators. This format must be specified as part of a complete platform. Despite this, an application running on a platform that implements the J2SE security model can test whether or not it has access to the resource corresponding to a given Locator using code similar to the following:

     boolean hasAccessTo(Locator l) {
         boolean allowed = true;
         SecurityManager m = System.getSecurityManager();
         if (m != null) {
             Permission p = new;
             try {
             } catch (SecurityException ex) {
                 allowed = false;
         return allowed;

Copyright © 2000 Sun Microsystems, Inc.