[wbs] response to 'Call for Review: Devices and Sensors Working Group Charter'

The following answers have been successfully submitted to 'Call for Review:
Devices and Sensors Working Group Charter' (Advisory Committee) for Mozilla
Foundation by Tantek Çelik.


The reviewer's organization suggests changes to this Charter, and only
supports the proposal if the changes are adopted [Formal Objection].

Additional comments about the proposal:
   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

Thank you for your thoughtful consideration.



Answers to this questionnaire can be set and changed at
https://www.w3.org/2002/09/wbs/33280/das2021/ until 2021-07-23.

 Regards,

 The Automatic WBS Mailer

Received on Saturday, 24 July 2021 02:09:03 UTC