FP7-611327—HTML5Apps HTML5 for Apps: Closing the Gaps HTML5APPS DELIVERABLE D1.1 STANDARDIZATION REPORT D1.1 - Standardization Report (M12) Page 1 of 298 FP7-611327—HTML5Apps HTML5 for Apps: Closing the Gaps Project Grant Agreement number 317862 Project acronym: HTML5Apps Project title: HTML5Apps: Closing the Gaps Funding Scheme: Coordination & Support Action Date of latest version of Annex I against which the assessment will May 24, 2013 be made: Document Deliverable number: D1.1 Deliverable title Standardization report Contractual Date of Delivery M12 Actual Data of Delivery: M12 Editor(s): Dr. Dave Raggett Author(s): Reviewer(s): Partipant(s): Work package no.: 1 Work package title: WebOS APIs Work package leader: Dr. Dave Raggett Distribution: PU Version/Revision: Draft/Final: Final Total number of pages (including 298 cover): Keywords: D1.1 - Standardization Report (M12) Page 2 of 298 FP7-611327—HTML5Apps HTML5 for Apps: Closing the Gaps DISCLAIMER This document contains description of the HTML5Apps project work and findings. The authors of this document have taken any available measure in order for its content to be accurate, consistent and lawful. However, neither the project consortium as a whole nor the individual partners that implicitly or explicitly participated in the creation and publication of this document hold any responsibility for actions that might occur as a result of using its content. This publication has been produced with the assistance of the European Union. The content of this publication is the sole responsibility of the HTML5Apps consortium and can in no way be taken to reflect the views of the European Union. The European Union is established in accordance with the Treaty on European Union (Maastricht). There are currently 27 Member States of the Union. It is based on the European Communities and the member states cooperation in the fields of Common Foreign and Security Policy and Justice and Home Affairs. The five main institutions of the European Union are the European Parliament, the Council of Ministers, the European Commission, the Court of Justice and the Court of Auditors. (http://europa.eu/index_en.html) HTML5Apps is a project funded in part by the European Union. D1.1 - Standardization Report (M12) Page 3 of 298 FP7-611327—HTML5Apps HTML5 for Apps: Closing the Gaps TABLE OF CONTENTS 1. Introduction . 5 2. Execution and Security Models . 7 2.1. Status of Work. 7 2.2. Trust and Permissions. 8 2.2.1. White Paper . 8 2.2.2. Paris Meeting. 9 3. Application Programming Interfaces (APIs). 13 3.1. Alarm API/Task Scheduler API . 13 3.2. Contacts API . 13 3.3. Messaging API . 13 3.4. Telephony API . 13 3.5. Raw Socket API/TCP UDP Sockets API. 14 3.6. Bluetooth API . 14 3.7. Secure elements API . 14 4. Planning Future Work . 15 5. Conclusions . 17 APPENDICES A. Whitepaper: Handling Trust and Permissions in Web Applications. 19 B. Minutes from meeting on trust and permissions for Web applications65 C. Manifest for web apps and bookmarks . 89 D. The app: URL Scheme . 107 E. Application Lifecycle and Events . 112 F. Task Scheduler API . 122 G. Contacts Manager API . 130 H. Messaging API . 142 I. Telephony API . 177 J. TCP and UDP Socket API . 210 K. Web Bluetooth . 237 L. Secure Element API . 280 D1.1 - Standardization Report (M12) Page 4 of 298 FP7-611327—HTML5Apps HTML5 for Apps: Closing the Gaps 1. INTRODUCTION This report describes the HTML5Apps project's achievements in in terms of standardizing WebOS APIs (including standardization documents). At the outset of the HTML5Apps project, HTML5 standards were designed to cope with the user visiting untrusted web sites, necessitating a cautious approach to security that narrowly limited what a particular website can do (limited access to OS, network, and browser data through browser sandbox, avoid fingerprinting of users etc.). This limited the type of apps that could be written using HTML5. It was assumed that closing the gap between HTML5 apps and native apps would require defining a runtime environment, security model, and associated APIs for building Web applications with comparable capabilities to native applications. This means stronger integration with the host platform than is the case for traditional web pages. Today’s Web operating systems such as Tizen and FirefoxOS typically include the following components for which no standardized solution exists today: • Execution Model: A description of the execution model and associated APIs for HTML5 applications, that differs from the traditional browser- based execution model. • Security Model: A description of the security model and associated APIs for HTML5 applications that differs from the traditional browser-based security model. Moreover, Web operating systems include a number of APIs which are also not standardized: • Alarm API: An API to manage the system's alarm daemon. • Contacts API: An API that enables complete management of the device's address books. • Messaging API: An API to send and receive messages (e.g. SMS, MMS, Email, and IM) as well as manage messages stored on the device. • Telephony API: An API to interact with the phone system, for instance to dial a number, pick up a call, route to voicemail, access the call log, etc. • Raw Sockets API: An API to manipulate low-level connections (e.g. TCP, UDP), including the ability to listen for incoming connections. • Bluetooth API: A low-level API to interact with the Bluetooth hardware available on some devices. • Browser API: An API that provides all the necessary items to build a Web browser that aren't otherwise available. Most notably, this provides all that is needed in order to safely instantiate a viewport onto the open Web, pretend that such a viewport is the top level window even if the browser's chrome is itself written using Web technology, etc.. D1.1 - Standardization Report (M12) Page 5 of 298 FP7-611327—HTML5Apps HTML5 for Apps: Closing the Gaps • Calendar API: An API that enables complete management of the device's calendars. • Device Capabilities API: An API that exposes the capabilities available to the device. • Idle API: An API to be notified when the user is idle. • Media Storage API: An API to manage the device's storage of specific content types (e.g. pictures). • Network Interface API: An API to manipulate network interfaces (mobile, WiFi, etc.), such as listing available networks, current strength, etc., as well as configuring and enabling them. Potential uses include offloading connections from mobile networks to WiFi, enabling high priority mobile data connections and control of other network features. • Secure Elements API: An API enabling the discovery, introspection, and interaction with hardware tokens (Secure Elements) that offer secure services such as tamperproof storage, cryptographic operations, etc. • System Settings API: An API to manage the system's settings (e.g. time/ clock settings, and personal preferences including privacy preferences). For HTML5 apps to realize their full potential as non-proprietary, open alternative to today’s native app environments, further functionality needs to be added to the relevant standards. In order to develop these standards, members of the HTML5Apps project team are filling in the role of so-called “W3C team contacts” in relevant W3C standardization Working Groups. A W3C team contact acts as the interface between the Group Chair (“Chair”), Group Members, and the W3C Team. Many of the team contact’s tasks involve helping the Chair complete his or her roles, while others involve direct action from the Contact. The team contact role is largely one of communication. This involves becoming as aware as possible of the technical requirements and issues in the group, and simultaneously being aware of the general architecture of the Web as evolving in the other work of W3C. In particular, the work of team contacts include the following tasks: • Assist Group organizers in maintaining charter and convening Group • Monitor group participation and operations • Monitor levels of active participation and address as needed. • Serve as Contact between WG and rest of the W3C Team (team contacts of other groups, marketing, management etc.) This report is structured as follows: In Section 2, we report on the status of work on the execution and security model, with particular focus on the work on permissioning. In Section 3, we report on the status of work on individual APIs. In Section 4, we give an overview of future work planning. Section 5 concludes this report. Appendices provide background materials and standardization documents. Please note that this document includes hypertext links to background materials including draft specifications. This can be followed when viewing the electronic version of this document. D1.1 - Standardization Report (M12) Page 6 of 298 FP7-611327—HTML5Apps HTML5 for Apps: Closing the Gaps 2. EXECUTION AND SECURITY MODELS 2.1. STATUS OF WORK Work started with submissions from working group participants in the W3C Systems Applications (SysApps) WG: Execution Model A description of the execution model and associated APIs for system applications, particularly how the execution model differs from the traditional browser-based execution model. Example: Strawman proposal from Google. Security Model A description of the security model and associated APIs for system applications, particularly how the security model differs from the traditional browser-based security model. Examples and further background: • Strawman proposal from Google, • B2G Security Model, • W3C Workshop in 2008 on Security for Access to Device APIs from the Web, • The WAC core security specifications • The BONDI App Security Framework • Chrome extensions security model and permissions • The webinos security model • The Widgets security model landscape analysis from 2008 • The security controls introduced by 'Gibraltar' These contributions were reworked by editors from Mozilla and Samsung into a draft specification. • Runtime and Security Model for Web Applications The draft described: • How an application is defined through an application manifest and how it can be installed, updated and packaged.