ANT Document ID: 0154/19382 Copyright (C) ANT Software Limited 2008 - All rights reserved. ANT Software Limited: Position paper on security for access to device APIs Traditional Internet standards are increasingly being deployed in new markets. Of particular interest to ANT Software is their use within embedded platforms, especially those related to video, such as digital TV and other home entertainment services. At present, a range of factors are converging to drive increased deployment volume, platform capability, reliance upon open standards and provision of richer applications and services within the TV and home entertainment domains. Groups such as DVB and Open IPTV Forum are increasingly leaning on core W3C standards, especially as deployments transition from closed ("managed") networks to supporting and encouraging open Internet access. Through ANT's participation in DVB, Open IPTV Forum and CEA in standardisation activities, along with our own product development, we are seeing an increased focus on security and precision of permission granting. ANT Software develops and licenses products based upon standards from W3C, DVB, the Open IPTV Forum, CEA ("CE-HTML" or "CEA-2014-A"), etc. These products provide an execution platform for a rich range of applications and services. These applications and services are a set of independent, but co-operating, web applications. Applications implement the user interface using open W3C standards, specifically HTML, CSS and DOM, in conjunction with ECMAScript to manipulate the user interface and control the media middleware. Access to the DOM APIs which provide access to the underlying hardware and system capabilities must be restricted so that only suitably authorised code may access them. Currently, access to the media control APIs is restricted based solely on the browsing context of the code that is running. Only code executing in privileged contexts is permitted to access all of the media APIs and only code executing in privileged contexts is permitted to create other privileged contexts. This has some key benefits: * Easy to see what code can call which APIs * Easy to audit the set of permissions * Easy to enforce the permissions However, this approach has some drawbacks: * Permissions are all-or-nothing: no partial access * No protection against rogue applications granting access to unprivileged contexts * Applications must co-operate to control the devices Whilst application co-operation can be arranged when a single service provider is designing, implementing, testing and auditing a group of applications that are running on a device, the model breaks down when independently developed applications are provided by a third party. The service provider has to determine whether or not to trust the third party application with access to the entire media management API. ANT would like to participate in the definition of mechanisms to define a framework where contexts may grant sets of permissions to other contexts to permit that context to call an API or set of APIs. We would like to explore the requirements for the framework and discuss possible answers to key questions that will help define both the managerial and technical framework, for example: * What is a suitable scope for a set of permissions? Is it the individual browsing contexts, or a group of browsing contexts that share a common domain, or more fine-grained? How should this scope interact with the concept of widgets and their associated boundary definitions? * How does this interact, if at all, with existing inter-context scripting security and other access control that is enforced using Access-Control for Cross-Site Requests? * The method for defining permissions must be easy to write, easy to verify and easy to audit. Is it appropriate to build on the existing solutions defined in MHP/OCAP? * How will configuration that defines permissions be protected against tampering? Digital signatures? Will multiple signatures be required before permissions are granted? Will a service operator be able to update permissions without recourse to an external certificate authority or incurring other charges? * Will applications need to declare the set of permissions that it requires, or does it just attempt to use it and trap errors? Can applications test whether or not it has specific permissions in advance of attempting to use an API? * How should a user agent respond to an application that violates the permissions? Should the application receive a DOM security exception, or does the user agent terminate the application, or some other approach?