W3C home > Mailing lists > Public > public-device-apis-log@w3.org > December 2020

Re: [dap-charter] DASWG: Drop Geolocation Sensor in favor of existing APIs (#103)

From: Philippe Le Hegaret via GitHub <sysbot+gh@w3.org>
Date: Mon, 14 Dec 2020 13:40:14 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-744446928-1607953213-sysbot+gh@w3.org>
This is the relevant excerpt from the AC announcement:

The Director, as part of making a decision, took into consideration the
input from an experiment conducted by the Advisory Board and the TAG
(see below).

The formal objection from Mozilla, ultimately overruled by the Director,
was to remove 8 APIs listed in the proposed charter from the
deliverables, based on privacy and architecture concerns as well as
gathering enough adequate implementation experience. While
there is technical merit to many arguments raised by Mozilla, it was
concluded that they were not appropriate reasons for excluding the
relevant specifications from the charter, and that on the contrary, a
chartered Working Group was best suited to addressing these concerns.
Updated reviews, especially from the TAG and PING, will be requested
before moving to Candidate Recommendation (CR). Adequate
implementation experience would have to be demonstrated before moving
beyond CR. It was recognized that the Group needed to keep working on
the deliverables provided it contains the proper community to move
the documents forward. The charter was modified to add a liaison to the
CSS Working Group as well as marking the Network Information API and the
Fold Angle API as tentative deliverables.

Report of AB/TAG Experiment

# Prologue

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.

# Objection

The formal objection from Mozilla [1] to re-chartering the Devices and
Sensors Working Group requested changes to reduce the scope of work,
citing privacy, architectural, and implementation concerns.

[1] https://lists.w3.org/Archives/Public/public-new-work/2020Jun/0012.html

# Decision

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.

# Rationale

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.

# Additional Recommendations

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.

* Recognizing the long time elapsed since formal publication on TR of
some of these specifications, the amount of changes that have happened
since, and the fact that their horizontal reviews lack freshness and
thoroughness, we recommend the following documents be republished as
Working Drafts (for two of them, this represents a downgrade from CR):
  - Battery Status API
  - Proximity Sensor
  - Ambient Light Sensor
  - System Wake Lock
  - Geolocation Sensor
  - Orientation Sensor

(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 recommend that the group proactively pursue more modern security
and privacy reviews for all these documents, including those that were
reviewed in the past in consideration of the amount of change in both
the specs and in privacy and security since.

* We also recommend that the group request TAG reviews for all these
specifications, and in particular that it consider why some of these
APIs (Geolocation Sensor, Orientation Sensor) duplicate functionality
found in pre-existing specifications and whether this is appropriate or
whether a merge with the earlier technology should be sought. Such
discussion with the TAG needs to consider not just the merits of their
architectures, but also how widely the existing APIs are used and the
willingness of users and implementers to move.

* Although our decision allows for keeping it in the scope of the
charter, given the architectural concerns raised against the Network
Info API, we advise a meaningful conversation with the TAG and
networking experts about at least its fundamental assumptions and
approach, and that any intrinsic concerns be addressed in or before FPWD.

* For better visibility, we suggest the working group add warnings
inline in the specifications outlining any major unresolved privacy or
architectural concerns.

* Lastly, we recommend that the changes to the charter that are agreed
by the team, chairs, and objector be incorporated. They are (a) a
liaison to the CSS working group, and (b) more clarity in the charter
about the maturity of the various specifications (notably that some are
under incubation).

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.

GitHub Notification of comment by plehegar
Please view or discuss this issue at https://github.com/w3c/dap-charter/issues/103#issuecomment-744446928 using your GitHub account

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 14 December 2020 13:40:16 UTC

This archive was generated by hypermail 2.4.0 : Monday, 14 December 2020 13:40:17 UTC