- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Tue, 7 Jul 2020 00:12:57 -0700
- To: David Singer <singer@mac.com>, Pete Snyder <psnyder@brave.com>
- Cc: Tantek Çelik <tantek@cs.stanford.edu>, w3c-ac-forum <w3c-ac-forum@w3.org>, Samuel Weiler <weiler@w3.org>, Fuqiao Xue <xfq@w3.org>, Philippe Le Hegaret <plh@w3.org>, W3C Strategy Team <team-strat@w3.org>, public-new-work@w3.org
Hi David and Pete, Thank you for your replies. Appreciated. Per request from Samuel Weiler, I have filed individual issues for each specification mentioned in Mozilla's DAS charter feedback formal objection, so that we can have parallel discussions on each to try to reach consensus. https://github.com/w3c/dap-charter/issues/98 https://github.com/w3c/dap-charter/issues/99 https://github.com/w3c/dap-charter/issues/100 https://github.com/w3c/dap-charter/issues/101 https://github.com/w3c/dap-charter/issues/102 https://github.com/w3c/dap-charter/issues/103 https://github.com/w3c/dap-charter/issues/104 https://github.com/w3c/dap-charter/issues/105 Thanks for your consideration, and let's follow-up in each issue accordingly. Tantek On Mon, Jun 29, 2020 at 11:25 AM Pete Snyder <psnyder@brave.com> wrote: > > Thank you for these Tantek, [...] On Mon, Jun 29, 2020 at 10:52 AM David Singer <singer@mac.com> wrote: > > Thanks Tantek [...] > > > On Jun 19, 2020, at 10:03 , Tantek Çelik via WBS Mailer <sysbot+wbs@w3.org> wrote: > > > > 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 > > > > > > David Singer > > singer@mac.com >
Received on Tuesday, 7 July 2020 07:13:53 UTC