Status: Sent to the Council
The review of the Advisory Committee received 21 reviews:
This Council should only be considering Mozilla’s Formal Objection.
The Devices and Sensors Working Group (DAS) has been operating since 2009. Its precise scope contours have evolved, supporting an ongoing mission “to create secure and privacy-preserving client-side APIs that enable the development of web applications that interact with device capabilities.” The WG has 36 participants from 7 organizations, including 6 invited experts.
The re-charter proposed to the AC added some new deliverables from incubation. As Team informed the AC at the time: “The updated charter adds Contact Picker API, Idle Detection API, and Compute Pressure to the list of specifications to tentative deliverables of the Working Group.”
Mozilla sent its formal objection to public-new-work@w3.org.
As in the previous DAS WG charter review, Mozilla is opposed to continuing standards track work on a number of the specifications in the DAS WG for a number of reasons. Despite our past formal objection to the DAS WG charter being overridden, we do want to acknowledge that the WG republished several of the specifications in question as working drafts (instead of candidate recommendations), which we see as progress towards reflecting the actual level of maturity of those documents.
However, as noted in our recent WebAppSec charter review formal objection, in general we believe that specs should only be put on the standards track (included as a Working Group deliverable towards a Recommendation) when there is at least some explicit *interest* from two or more practical (web impactful) implementations.
We request that specs be dropped that have shown interest from only one implementer, otherwise we are at risk of a single-implementation spec, which will only ever serve as documentation (i.e. not an actual open standard), as we know that monoculture based standards end-up becoming de facto, based on the one specific implementation’s details, bugs, interpretations, and not what is written in a specification.
This is not the same as “implementation experience” which was noted as only being tested in CR to PR, and was given as a reason to reject our formal objection to the previous DAS WG charter review. Lack of even *interest* (nevermind implementation testing), and in some cases actual antipathy, is much worse.
We also request that some specs be dropped for privacy concerns, (republished as NOTEs), in some cases because we have known privacy concerns from our own implementation (and unimplementation) experience.
We acknowledge that many of the proposed deliverables contain an explicit “Security and Privacy Considerations” section with some mitigations, and this is good progress. There is also acknowledgment in many of their Status sections that “The Devices and Sensors Working Group is pursuing modern security and privacy reviews for this specification in consideration of the amount of change in both this specification and in privacy and security review practices since the horizontal reviews took place.” In such cases, we would like to see explicit statement of the date of the most recent such security and privacy reviews, and non-normative link to the reviews as well, or an acknowledgment that no such reviews have yet been completed.
On specific deliverables:
On the the grounds of privacy and insufficient implementer interest and intent to support, we would like the group to cease work on the following specifications:
- Battery API
- Proximity sensor API
- Ambient light sensor API
- Geolocation Sensor (see also: https://mozilla.github.io/standards-positions/#geolocation-sensor)
- Orientation Sensor
For Geolocation Sensor and Orientation Sensor in particular, we still believe that it would be better to work on improving existing implemented specifications, and pursue additional declarative approaches rather than new APIs.
On the grounds of insufficient implementer interest and intent to support, we would like the group to cease work on the following specifications:
- System Wake Lock API
- Compute Pressure (see also https://lists.webkit.org/pipermail/webkit-dev/2021-May/031853.html)
Finally, due to our continued evaluation that this API and approach is harmful, we rerequest that the Network Information API draft be dropped, even from being a Tentative Deliverable. https://mozilla.github.io/standards-positions/#netinfo
We agree with Apple’s objection about including the Contact Picker API.
We have user-surveillance and user-control concerns about the Idle Detection API. Even with the required 60 second mitigation, it can be used for monitoring a user’s usage patterns, and manipulating them accordingly. It should be returned for further incubation.
For reference, our response to the previous DAS WG charter review: https://lists.w3.org/Archives/Public/public-new-work/2020Jun/0012.html
There are 2 remaining disagreements:
Consensus was reached on the Contact Picker API (not published) by making it a joint deliverable with the WebApps Working Group. This also satisfied [Member1].
The Team had a conversation with Mozilla.
The first part of the objections did not seem to bring new information from the formal objection in 2020. Mozilla believes nevertheless that they are bringing new information. The Working Group disagrees and continues to believe that the Council made the right decision last year.
For the second part, Mozilla did not find enough implementation commitments for the new deliverables and the Working Group disagrees. Additional inquiries made by the W3C team indicates that we have implementation commitments from Intel and from an undisclosed organization.
Reconsidering the previous Council recommendation from December 14, 2020:
- we recommend the following documents be republished as Working Drafts
- Battery Status API
- Proximity Sensor
- Ambient Light Sensor
- System Wake Lock
- Geolocation Sensor
- Orientation Sensor
All but one of the documents listed above are Working Drafts, as of September 1, 2022 (switched back to WD during the year 2021). The only exception is System Wake Lock. On 9 Mar 2020, the Devices and Sensors Working Group decided to split the Wake Lock API spec into two separate specs: Screen Wake Lock API and System Wake Lock API. The system wake lock API has not yet been published as a W3C technical Report and has no status.
These republications should include a “Changes” section to facilitate the work of reviewers and to fulfill the requirements of the W3C Process. This is particularly important for System Wake Lock, given the large delta since the previous publication as part of a broader CR.) We recommend the Privacy and Security sections include a link to the common concerns described in the Generic Sensor API document, and where appropriate be expanded not only to list mitigations, but also the specific concerns that call for those mitigations.
No changes section were added but the specifications link to publication history and/or human-readable commit log from the specification header. The Working Group believes this satisfies the "public documentation of substantive changes" and "public documentation of significant editorial changes" requirements defined in the W3C Process.
All of the specifications that extend the Generic Sensor API link to the Generic Sensor API:
We also recommend that the group request TAG reviews for all these specifications, and in particular that it consider why some of these APIs (Geolocation Sensor, Orientation Sensor) duplicate functionality found in pre-existing specifications and whether this is appropriate or whether a merge with the earlier technology should be sought. Such discussion with the TAG needs to consider not just the merits of their architectures, but also how widely the existing APIs are used and the willingness of users and implementers to move.
No TAG review has been requested from the Devices and Sensors Working Group since December 14, 2020. However, the TAG review of the Geolocation API was requested before December 2020 and was completed in June 2021.
Previous were done: Sensor APIs #207
No substantial progress has been made since. The Working Group believes doing another round of TAG reviews was too premature.
Although our decision allows for keeping it in the scope of the charter, given the architectural concerns raised against the Network Info API, we advise a meaningful conversation with the TAG and networking experts about at least its fundamental assumptions and approach, and that any intrinsic concerns be addressed in or before FPWD.
No progress was done on the Network Info API (last published as a Working Draft in May 2014).
For better visibility, we suggest the working group add warnings inline in the specifications outlining any major unresolved privacy or architectural concerns.
There are no known security privacy issues and TAG Reviews still need to be done.
Lastly, we recommend that the changes to the charter that are agreed by the team, chairs, and objector be incorporated. They are (a) a liaison to the CSS working group, and (b) more clarity in the charter about the maturity of the various specifications (notably that some are under incubation).
This was done when the charter was approved by the Director.
Arguments against Rec-track inclusion of the various documents:
Arguments for Rec-track inclusion: