In recognition of Tim Berners-Lee's eventual retirement, the W3C Advisory Board and W3M have been exploring the possibilities of a Director-free future for the W3C. As part of these explorations, W3M invited the Advisory Board and the TAG to a joint session as a test run for handling formal objections as a joint Council. Although we did not follow a particularly formal process, we did suppose that the Council would have the powers to sustain or overturn a formal objection, but not to mandate any specific remedies. This writeup is the conclusion of this ad-hoc Council on the matter of Mozilla's formal objection to the rechartering of the Devices and Sensors Working Group.
This conclusion has been forwarded to W3M as input into the Director's resolution of this issue. Following this experiment, the AB, TAG, and W3M, together with the Process CG, will be using this experience and its evaluation to help us chart the future of a Director-free Consortium.
The formal objection from Mozilla to re-chartering the Devices and Sensors Working Group requested changes to reduce the scope of work, citing privacy, architectural, and implementation concerns.
We do not sustain the objection: the charter may proceed, with the specifications identified in the Formal Objection included in its scope. However, see additional recommendations further down.
On privacy: There are legitimate privacy concerns, and the earlier privacy reviews are rather old (the group and field have moved along substantially in 4 years). However, it has has neither been shown nor does it seem likely that these specifications are fundamentally conceptually wrong or intrinsically flawed from a privacy point of view, such that could not be adequately mitigated through further work in the chartered Working Group.
On implementation: As to the question of the number of committed independent implementers, nothing suggests that there is something about these specifications that makes them intrinsically un-implementable, and implementation commitments are not a deciding factor at this stage. Certainly, work should not be chartered without a substantial amount of community support, but it seems clear that the Working Group has assembled a meaningful community of interested parties, including some who intend to implement and ship these technologies. How many such parties there are, whether they are independent of each other, and what precisely is meant by independent is a question for the transition from CR to PR; identifying such implementors is not required at this stage.
On architecture (Geolocation Sensor and Orientation Sensor): For these pre-existing specifications, where the group is proposing a new approach to existing APIs, we understand Mozilla's concerns about whether this is the right approach, and it may well be that iterative improvement of the existing API is a better approach. Sometimes it’s true that a new approach, consistent with a set of other APIs built around a common compelling architectural and stylistic set of principles, can justify a departure, but even that is rare. However, this is not a subject for the blunt instrument of removing charter deliverables but rather an issue for the group to work on under its charter and the guidance of the TAG.
On architecture (Network Info): Mozilla has expressed legitimate concerns about assuming that the first-hop (from the client’s viewpoint) connection is diagnostic. It would be prudent for the Working Group to pay attention to Mozilla's concerns that this could be misleading to too many sites and architecturally harmful for the web. This may be an intrinsic aspect of this API, and we are unsure whether it can be addressed; however, in order to enable the Working Group to attempt to address this problem, we do not support removing it from the charter at this time.
Altogether, no argument has been made that would suggest the Working Group cannot be trusted to follow the spirit and letter of the Process, and work with all appropriate parties to identify and address any relevant issues. Furthermore, given mandatory Horizontal Reviews, the ability to formally appeal to authority in case of disagreement, neglect, or abuse, the various other criteria imposed by the W3C process on documents attempting to make progress on the Recommendation track, and the ability to involve W3C staff in support of these efforts, we believe chartering these work items into the Device and Sensors API WG under the formal W3C Process actually provides a better framework for ensuring that all concerns are taken seriously.
Moreover, although the Process cannot itself prevent an overly enthusiastic implementer from shipping into production APIs in a problematic state, its greater engagement of the community can hold implementers to a higher standard. Pushing these specifications out of this well-established Working Group risks dispersing the interested community, which could result in reduced scrutiny over these documents precisely when we want more.
Moving these specifications out of the Working Group would also have undesirable effects on existing IPR commitments made under the W3C Patent Policy.
Therefore, the present members of this Council unanimously recommend that the objection be overruled.
The following recommendations are non-binding, however we offer this advice in acknowledgement of the legitimate concerns raised by Mozilla, to improve the communication and process around these work items, and to reduce risk of further objections later on.
(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.
We encourage the Director to make sure that the appropriate reviews have happened, with sufficient depth and on a sufficiently recent draft, before allowing (re)transitioning to CR, with particular attention to the provisions listed in section 3 of the proposed charter.
Finally, even though this specific Formal Objection against the charter itself is overturned, nothing stated here should be construed as discouraging any party from arguing against any particular aspect of any particular spec within the Working Group, nor from filing new Formal Objections in response to other events, such as transitions requests and AC reviews, should their concerns remain unaddressed.