Note: This is a written introduction of the formal objection, previously shared to the AB, then sent by email to the Council participants.

The formal objection was raised by Mozilla, as part of the Advisory Committee review of a proposed charter for the Device and Sensors Working Group. On the grounds of privacy and lack of implementer support, Mozilla would like the group to cease work on a set of specifications. Following the team advise, the objection was discussed on GitHub and was later refined in subsequent conversations. A call on September 1 did not resolve the formal objection.

The concerns are of 3 categories:

  1. Drop the new Generic Sensor API architecture due to privacy/security concerns and come up with a new one after looking at the use cases/requirements again. Several of the work items would be moved to incubation (Fold Angle, System WakeLock) and would need a second implementer commitment.
  2. Drop the refactoring of existing APIs (Geolocation, Accelerometer) and revise/maintain the existing ones instead.
  3. Drop some APIs entirely due to privacy/security concerns (Battery API, Proximity Sensor, Ambient light, Network Information)

Effectively, the work of the Working Group would be left with: - redesigning our approach to sensor APIs - revise/maintain Geolocation, Accelerometer, Vibration - Work on Gyroscope, Accelerometer, DeviceOrientation

The rational to continue the work are:

  1. Some of the specifications are already in Candidate Recommendations, after several years of development. In addition to loosing the technical work, we would be loosing several years of licensing commitments. The APIs address some valid use cases, including the Battery API. Pushing the work into Incubation where it could get lost while we have an existing focused Working Group seems counter effective. All privacy/security concerns have been addressed and no specific issue has been raised. New issues can be addressed as needed within the W3C Recommendation track Process.
  2. The new design takes into account new ECMAScript features, such as Promises. This makes the refactoring of the Geolocation API more inline with latest ECMASCript concept.

    In fact, it is the second attempt at coming up with a design, following comments from Mozilla in 2014: https://lists.w3.org/Archives/Public/public-device-apis/2014Aug/0058.html

The rational to stop the work or push it towards Incubation is:

  1. Mozilla pulled those APIs from their implementation and stopped supporting them, due to security/privacy issues. The current approach needs to be looked at again and redesigned. Mozilla indicated that they are not going to put resources in this area
  2. The Charter indicates the 2 independent implementations are needed to move beyond Candidate Recommendation but there is no commitment to provide those second implementations. Keeping those specifications on the W3C Recommendation track without proper implementation commitment is misleading at best.