W3C home > Mailing lists > Public > public-new-work@w3.org > June 2020

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

From: Tantek Çelik via WBS Mailer <sysbot+wbs@w3.org>
Date: Fri, 19 Jun 2020 17:03:02 +0000
To: public-new-work@w3.org
Message-Id: <wbs-19c82bb6b4799f3e82e5b8df4375e3fb@w3.org>
The following answers have been successfully submitted to 'Call for Review:
Devices and Sensors Working Group Charter' (Advisory Committee) for Tantek

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:
   Although Mozilla is generally supportive of the work being undertaken by
DAS, we would like to see some changes in the Charter and deliverables
before we would be supportive of rechartering the Working Group (Formal
On the the grounds of privacy, and given a lack of implementer support, we
would like the group to cease work on the following specifications:

* Battery API
* Proximity sensor API
* Ambient light sensor API

We would like to see those published as Working Group Notes instead.

We believe it would be prudent for the System WakeLock API to go through
the WICG process until it gets implementation commitment from at least a
second browser vendor. Similarly, the Fold Angle specification should be
incubated in the WICG before it becomes a working group deliverable. For
Fold Angle, we'd also like to see closer collaboration and input from the
CSS WG on the design. 

Having said that, we would be comfortable with having WICG incubated specs
being explicitly listed as charter as work items the working group could
adopt at a future date. However, we'd like to see them listed in a manner
similar to the Web Apps WG Charter's section on WICG Specs [1] (i.e.,
separated out of the main deliverables list for the working group). 

Where we already have an existing Web APIs, e.g., Geolocation Sensor,
Orientation Sensor, we would prefer the working group also cease work on
those items and instead focus on evolving the existing specifications. As
is evident with the Geolocation API [2], implementers have continued to
make significant privacy and security enhancements to existing APIs, and
those enhancements have made their way back to the W3C. As such, we feel
it's unnecessary to have duplicate specifications.  

Finally, Mozilla has significant concerns about the inclusion of the
Network Information API in the charter (as a specification to potentially
adopt from the WICG) — Mozilla's public position is that this API is
"harmful" to the Web as the information that it provides is unreliable and,
at the same time, open to privacy abuses. As we have stated publicly [3],
we believe it is "better that sites use methods that dynamically adapt to
available bandwidth, as that is more accurate and likely to be applicable
in the moment". Or, alternatively, use newer declarative solutions, such as
"lazy loading" images and alike. 

[1] https://www.w3.org/2019/05/webapps-charter.html#wicgspecs 
[3] https://mozilla.github.io/standards-positions/#netinfo

The reviewer's organization intends to participate in these groups:
   - Devices and Sensors Working Group

The reviewer's organization:
   - intends to review drafts as they are published and send comments.
   - intends to develop experimental implementations and send experience
   - intends to develop products based on this work.

Answers to this questionnaire can be set and changed at
https://www.w3.org/2002/09/wbs/33280/das-2020/ until 2020-06-19.


 The Automatic WBS Mailer
Received on Friday, 19 June 2020 17:03:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 19 June 2020 17:03:05 UTC