System Applications Working Group

On this page:
Mission | Roadmap | Phase 2 | Participate | Communications
SysApps Wiki | Device APIs WG | WebApps WG | HTML WG
"My Actions" | "My Questionnaires" | Participants | Patent Policy Status | Public email list | Member email list

Santa Clara Face to Face at TPAC 2014

We held a face to face meeting in Santa Clara on Thursday/Friday October 30-31 to progress current work items, and to continue discussions on the new charter.

Dave Raggett organized a break-out session on trust and permissions during the TPAC plenary day on Wednesday October 29. This follows on from the Paris meeting on trust and permissions held on 3-4 September 2014, and discuss plans for launching a Community Group on trust and permissions for the Open Web Platform. See draft CG charter.


As defined in its charter, the mission of the System Applications Working Group is to define a runtime environment, security model, and associated APIs for building Web applications with comparable capabilities to native applications.

The System Applications Working Group is aiming for full interoperability of website hosted applications across platforms, but regretably, developers may have to deal with variations between platforms when it comes to the details of how to create packaged applications for local installation. Web App scripts developed for the SysApps APIs should work across platforms without the need for changes.

Interested in helping to fulfill this mission? See below on how to participate.


The Working Group's deliverables are divided into two phases. In phase 1, the Working Group will focus on the execution and security models, and validating them through work on a small set of specific APIs. This will be used to establish the patterns and conventions that will be used for the remaining deliverables. The Working Group does not need to complete work on all the phase 1 deliverables before starting work on deliverables in phase 2. However, the Working Group should make substantial progress on some of the phase 1 deliverables before working on phase 2 deliverables, at which point it should be possible to do more work in parallel.

Below is the schedule for phase 1 as detailed in the initial Working Group charter. Note: App URI and App Manifest were split off from the Runtime and Security Model. App Manifest was subsequently transferred to the WebApps WG for use in both the regular apps and system apps security contexts. The extensions to App Manifest specific to the needs for system apps will now be covered in individual API specifications.

Specification GitHub repository Issues Internal draft Public Working draft Stable draft (Last Call) Implementors feedback (CR) Standard (Rec) Test Suite Notes
Active work
App Lifecycle repository issues 16 May 2014 Q3 2013 Q1 2014
App URI repository issues 11 June 2014 16 May 2013 29 May 2014 Q2 2014
Task Scheduler repository issues 13 October 2014 02 Dec 2014 Q4 2013 Q2 2014 Previously named Web Alarms
Contacts repository issues 04 Apr 2014 07 Mar 2013 Q4 2013 Q2 2014
Messaging repository issues 29 Nov 2013 16 May 2013 Q4 2013 Q2 2014
Telephony repository issues 14 Oct 2014 20 Jun 2013 Q4 2013 Q2 2014
TCP UDP Sockets repository issues 27 Oct 2014 02 Dec 2014 Q4 2013 Q2 2014 Previously named Raw Sockets
Inactive work
Runtime & Security Model repository issues 09 May 2013 21 Mar 2013 Q3 2013 Q1 2014 Discontinued in favor of App Lifecycle
App Manifest repository issues 16 May 2013 Transferred to WebApps WG on 21 May 2013, please see: repository, editor's draft

See also the list of the System Applications published Technical Reports.

Phase 2

The following are the Working Group's phase 2 deliverables. The Working Group intends to make significant progress on some of the phase 1 deliverables before working on phase 2.

Bluetooth API
A low-level API to interact with the Bluetooth hardware available on some devices. Examples: Tizen Bluetooth, B2G Web Bluetooth.
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. Example: B2G BrowserAPI.
Calendar API
An API that enables complete management of the device's calendars. Examples: B2G Calendar, Tizen Calendar.
Device Capabilities API
An API that exposes the capabilities available to the device. Example: Tizen System Info.
Idle API
An API to be notified when the user is idle. Example: B2G Idle.
Media Storage API
An API to manage the device's storage of specific content types (e.g. pictures). Examples: Tizen Media Content, B2G Device Storage.
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. It may build atop the simpler network information API that Device APIs is working on. Potential uses include offloading connections from mobile networks to WiFi, enabling high priority mobile data connections and control of other network features. Examples: B2G Mobile Connection, B2G WiFi Information.
Secure Elements API
An API enabling the discovery, introspection, and interaction with hardware tokens (Secure Elements) that offer secure services such as tamper-proof storage, cryptographic operations, etc. Example: Gemalto Secure Elements.
System Settings API
An API to manage the system's settings (e.g. time/clock settings, and personal preferences including privacy preferences). Example: B2G Settings.
Specification GitHub repository Issues Internal draft Public Working draft Stable draft (Last Call) Implementors feedback (CR) Standard (Rec) Test Suite Notes
Active work
Device Capabilities repository issues 18 Dec 2013 Q4 2013 Q2 2014 Q4 2014
Secure Elements repository issues 10 Apr 2014 Q4 2013 Q2 2014 Q4 2014


Our work is subject to the general policies for W3C Groups. We welcome contributions from people outside of the Working Group, and note that we operate under the W3C Patent Policy. See licensing commitments for non-W3C Members.

If you are employed by a W3C Member and want to join this group, please ask your Advisory Committee Representative to nominate you to the group as explained in the relevant instructions.

If you are not employed by a W3C Member and have specific expertise to bring to this group, you are welcome to apply for Invited Expert status.

See the list of current participants.

We host our editor's drafts and issues on GitHub. Snapshots are released as W3C Technical Reports. Our discussions take place via email, and regular face to face meetings (about three a year). We use our wiki to collect use cases, Member contributions, and general information relating to the operation of the Working Group, e.g. our editorial process.

Note: the issues for each deliverable are linked from the corresponding GitHub repository (as linked from Roadmap). See also the list of general issues.

Face to face meetings

The 1st F2F meeting was held 9-11 April 2013 in Madrid and hosted by Telefonica, see agenda and minutes

The 2nd face to face was held 27-29 August 2013 in Toronto and hosted by Mozilla, see logistics.

The 3rd face to face took place 11-15 November during TPAC 2013 in Shenzhen, China, see agenda.

The 4th face to face took place 8-9 April in San Jose, California, and hosted by eBay, see agenda.

We are planning a 5th face to face in Santa Clara during TPAC 2014 to progress existing work items and to discuss what we want to see in a new charter.


The main communication channel for this group is the publicly archived mailing list <>.

Member-confidential messages and logistical discussions can be addressed to the member-only archived mailing list <>

Patent Policy

This group operates under the W3C Patent Policy - see its Patent Policy status for more details.