- 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
The following answers have been successfully submitted to 'Call for Review: Devices and Sensors Working Group Charter' (Advisory Committee) for 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: 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 Objection). 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 [2] https://lists.w3.org/Archives/Public/public-device-apis/2020Jun/0006.html [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 reports. - 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. Regards, The Automatic WBS Mailer
Received on Friday, 19 June 2020 17:03:04 UTC