W3C

Device and Sensors Working Group Charter

The mission of the Device and Sensors Working Group is to create client-side APIs that enable the development of Web Applications that interact with device hardware, sensors, services and applications such as the camera, microphone, proximity sensors, native address books, calendars and native messaging applications.

Join the Device and Sensors Working Group.

End date 2017-12-31
Confidentiality Proceedings are Public
Chairs Frederick Hirsch
Team Contact
(FTE %: 20)
Dominique Hazaël-Massieux
Usual Meeting Schedule Teleconferences: 1 every other week
Face-to-face: 1 or 2 per year (only as needed)

Goals

The Device and Sensors Working Group aims at producing Web client-side APIs that facilitate deeper integration of Web applications into advanced capabilities of their host devices.

These capabilities include access to a camera, microphone, or system information such as network connection and battery level.

Adding these advanced features to the Web environment empowers Web developers to create richer and more context-aware Web applications.

Given the sensitive nature of the data and sensors to which these APIs grant access, the Working Group also aims at crafting APIs that are both secure and privacy-enabling by design, based on the current Web browser security model. This entails reusing existing browser-based security metaphors where they apply and looking into innovative security and privacy mechanisms where they don’t.

Scope

The scope of this Working Group is the creation of API specifications for a device’s services that can be exposed to Web applications. Services include sensors, media capture, network information and discovery. Devices in this context include desktop computers, laptop computers, mobile Internet devices (MIDs), cellular phones, TVs, cameras and other connected devices.

Devices sometimes provide calendar, contacts and other personal information management services. These services are also in scope for this Working Group, but to work on Specifications in that area the group would need to recharter to add new Deliverables.

Hardware security services are out of scope for this group.

Priority will be given to developing simple and consensual APIs, leaving more complex features to future versions.

Each specification should contain a section detailing any known security implications for implementers, Web authors, and end users. The Working Group will actively seek security, privacy, internationalization and accessibility review on all its specifications.

Additionally, comprehensive test suites will be developed for each specification to ensure interoperability, and the group will create interoperability reports. The group will also maintain errata as required for the continued relevance and usefulness of the specifications it produces.

Success Criteria

To advance to Proposed Recommendation, each specification is expected to have two independent implementations of all features defined in the specification, including implementation on a constrained device (e.g. mobile phone, TV).

APIs that cannot be demonstrated to be implementable securely within the default browser context will not be released.

Deliverables

Recommendation-Track Deliverables

The working group will deliver the following specifications:

Media Capture

HTML Media Capture
an HTML form extension that facilitates user access to a device's media capture mechanism, such as a camera, or microphone, from within a file upload control
Media Capture and Stream API
an API to manage a device’s camera and microphone, e.g. to take a picture or record a sound, in collaboration with the WebRTC Working Group
MediaStream Recording
a JavaScript API to record MediaStreams, in collaboration with the WebRTC Working Group
MediaStream Image Capture
a JavaScript API to capture still images from a video MediaStream, in collaboration with the WebRTC Working Group
Media Capture Depth Stream Extensions
An extension to the Media Capture and Streams API to capture depth streams (e.g. from 3D cameras), in collaboration with the WebRTC Working Group
Media Capture from DOM Elements
An extension to DOM elements to allow to capture a media stream from their content, in collaboration with the WebRTC Working Group
Audio Output Devices API
JavaScript APIs that let a Web application manage how audio is rendered on the user audio output devices, in collaboration with the WebRTC Working Group
Screen Capture
An extension to the Media Capture and Streams API to use a user's display, or parts thereof, as the source of a MediaStream, in collaboration with the WebRTC Working Group
Media Capture Stream with Worker
An extension to the Media Capture and Streams API to process video frame data in Web workers, in collaboration with the WebRTC Working Group

Some of these deliverables might, upon the request of the Working Group, be moved to the proposed Timed Media Working Group.

Sensors

Battery Status API
An API to react to a device power status
Wake Lock API
An API to manage the power-saving state of a device
Generic Sensor API
An API that serves as basis for APIs that retrieve data from sensors
Proximity Sensor API
An API to receive events that correspond to a proximity sensor detecting the presence of a physical object, built on the generic sensor API.
Ambient Light API
An API to receive events that correspond to a light sensor detecting the presence of a light, built on the generic sensor API.
Accelerometer API
An API to obtain data from the accelerometer sensor; in agreement with the Geolocation Working Group, it intends to provide an alternative to the Device Orientation API, built on the generic sensor API
Orientation API
An API to obtain data about the 3D orientation of the device; in agreement with the Geolocation Working Group, it intends to provide an alternative to the Device Orientation API, built on the generic sensor API

Others

Network Information API
An API to discover the current network characteristics — the group will determine whether the existing implementations of this API on mobile warrants restarting its standardization process.

Maintenance

The Working Group will maintain errata and new editions, as necessary, for the Vibration API W3C Recommendation.

Where practical, the API specifications should use the Web IDL formalism.

Jointly Developed Specifications

The Working Group may also enter into joint Task Forces with other groups to collaborate on any of the above Deliverables that cross group boundaries.

Adding new Recommendation-track deliverables

If additional in-scope Recommendation-track deliverables need to be added to the Charter before the Charter expires, the Working Group will prepare an updated Charter that differs only in deliverables. In the interest of agile spec development, the group requests that the Advisory Committee and Director restrict approval reviews for those Charter deliverables adjustments to just the changes in the Charter, rather than considering the entire Charter again for review.

The Working Group will not adopt new proposals until they have matured through the Web Platform Incubator Community Group or another similar incubation phase.

Other Deliverables

A comprehensive test suite for all features of a specification is necessary to ensure the specification’s robustness, consistency, and implementability, and to promote interoperability between User Agents.

The Working Group may also document in a Working Group Note useful design patterns shared by the APIs it is developing.

Other non-normative documents may be created such as:

  • Primers
  • Requirements and use case documents for specifications
  • Non-normative group notes

Given sufficient resources, this Working Group should review other working groups’ deliverables that are identified as being relevant to the Working Group’s mission.

Milestones

Milestones
SpecificationFPWDLCCRPRRec
HTML Media Capture13 Dec 201219 Jun 20149 Sep 2014Q1 2016Q1 2016
Media Capture and Streams27 Oct 20114 Apr 2015Q4 2015Q2 2016Q3 2016
MediaStream Recording25 Feb 2013N/AQ4 2015Q4 2016Q1 2017
MediaStream Image Capture9 Jul 2013N/AQ2 2016Q2 2017Q3 2017
Media Capture Depth Stream Extensions10 Oct 2014N/AQ2 2016Q2 2017Q3 2017
Media Capture from DOM Elements19 Feb 2015N/AQA 2015Q3 2016Q4 2016
Audio Output Devices API10 Feb 2015N/AQ3 2015Q2 2016Q3 2016
Screen Capture10 Feb 2015N/AQ4 2015Q3 2016Q4 2016
Media Capture Stream with WorkerQ2 2016N/AQ2 2017Q3 2017Q4 2017
Battery Status API26 Apr 201128 Aug 20149 Dec 2014Q1 2016Q2 2016
Wake Lock API12 Feb 2015N/AQ2 2016Q2 2017Q3 2017
Generic Sensor API15 Oct 2015N/AQ4 2016Q3 2017Q4 2017
Proximity Sensor API12 Jul 2012N/AQ4 2016Q3 2017Q4 2017
Ambient Light API2 Aug 2012N/AQ4 2016Q3 2017Q4 2017
Accelerometer APIQ1 2016N/AQ4 2016Q3 2017Q4 2017
Orientation APIQ1 2016N/AQ4 2016Q3 2017Q4 2017
Network Information API7 Jun 2011N/AQ2 2016Q1 2017Q2 2017

Note: The actual production of some of the deliverables may follow a different timeline. The group documents any schedule changes on the group home page.

Dependencies

W3C Groups

This Working Group expects to maintain contacts with at least the following groups within W3C (in alphabetical order):

Accessible Platform Architecture Working Group
To ensure this Working Group’s deliverables support accessibility requirements, particularly with regard to interoperability with assistive technologies, and inclusion in deliverables of guidance for implementing the group’s deliverables in ways that support accessibility requirements.
Audio Working Group
The API developed by the Audio Working Group builds upon the MediaStream object built by this group; further collaboration on the management of audio output device is expected.
Geolocation Working Group
The Geolocation Working Group is chartered to develop the Geolocation API Specifications, of a similar kind to the ones developed by this group. It is also responsible for the Device Orientation API, which the Device and Sensors Working Group intends to supplement with a generic-sensor-API-based API to access accelerometer and orientation data.
Privacy Interest Group
Several of the specifications developed by this group have potential impact on the privacy of users; reviews from the privacy interest group will be sought on these specifications.
Second Screen Presentation Working Group
The Second Screen Presentation Working Group is developing APIs to allow rendering of media on secondary devices; potential overlap with features enabled by the Audio Output Devices API will need to be looked at.
Web and TV Interest Group
This group provides use cases and requirements for using Web technologies on TV and thus important input on some of the APIs developed by the Device and Sensors Working Group.
Web Application Security Working Group
The Web Application Security Working Group is developing guidance on APIs that expose sensitive information, and an API to manage permissions, both of which matter to several of this group specifications.
Web Platform Working Group
This group defines relevant specifications including Web IDL, and File API.
Web Real Time Communications Working Group
The Device and Sensors Working Group collaborates with the WebRTC Working Group on many media-related APIs.

External Groups

The following is a tentative list of external bodies the Working Group should collaborate with:

Ecma International Technical Committee 39 (TC39)
This is the group responsible for EcmaScript standardization, and related EcmaScript features like E4X. As this Working Group is developing EcmaScript APIs, it should collaborate with TC39.
IETF
The IETF has created specifications that are related to some of the APIs in this WG’s scope.

Participation

To be successful, this Working Group is expected to have 10 or more active participants for its duration, and to have the participation of the industry leaders in fields relevant to the specifications it produces.

The Chair(s) and specification Editors are expected to contribute one to two days per week towards the Working Group. There is no minimum requirement for other participants.

Based on the input from the group participants, the Chairs may also decide to create task forces that allow more focused discussions for topics that require specific expertise.

This Working Group will also allocate the necessary resources for building Test Suites for each specification.

This Working Group welcomes participation from non-Members. The group encourages questions and comments on its public mailing list, public-device-apis@w3.org, which is publicly archived and for which there is no formal requirement for participation. The group also welcomes non-Members to contribute technical submissions for consideration, with the agreement from each participant to Royalty-Free licensing of those submissions under the W3C Patent Policy.

Communication

The Working Group’s Teleconferences focus on discussion of particular specifications, and are conducted on an as-needed basis.

Most of the technical work of the group is done through discussions on the public-device-apis@w3.org, the group’s public mailing list. Editors’ drafts and their editing history is available from a public W3C web site. The group’s action and issue tracking data is also public, as are the participants-approved minutes from all teleconferences and meetings.

The group uses a Member-confidential mailing list for administrative purposes and, at the discretion of the Chairs and participants of the group, for Member-only discussions in special cases when a particular participant requests such a discussion.

Information about the group (for example, details about deliverables, issues, actions, status, participants) is available from the Device and Sensors Working Group home page.

Decision Policy

Any resolution taken in a face-to-face meeting or teleconference is to be considered provisional until 10 working days after the publication of the resolution in draft minutes sent to the working groups mailing list. If no objections are raised on the mailing list within that time, the resolution will be considered to have consensus as a resolution of the Working Group.

As explained in the Process Document (section 3.3), this group seeks to make decisions when there is consensus. When the Chair puts a question and observes dissent, after due consideration of different opinions, the Chair should record a decision (possibly after a formal vote) and any objections, and move on.

This charter is written in accordance with Section 3.4, Votes of the W3C Process Document and includes no voting procedures beyond what the Process Document requires.

Patent Policy

This Working Group operates under the W3C Patent Policy (5 February 2004 Version). To promote the widest adoption of Web standards, W3C seeks to issue Recommendations that can be implemented, according to this policy, on a Royalty-Free basis.

For more information about disclosure obligations for this group, please see the W3C Patent Policy Implementation.

Licensing

This Working Group will use the W3C Software and Document license for all its deliverables.

About this Charter

This charter for this Working Group has been created according to section 5.2 of the Process Document. In the event of a conflict between this document or the provisions of any charter and the W3C Process, the W3C Process shall take precedence.

See also the first charter for this group, and the second.


Editor: Dominique Hazael-Massieux, Team Contact, based on the previous Device and Sensors (then called Device APIs) Working Group’s charter