DASWG: Drop Geolocation Sensor in favor of existing APIs

[tantek]

Per DAS charter feedback: Where we already have an existing Web APIs, e.g., Geolocation Sensor, we would prefer the working group cease work on those items and instead focus on evolving the existing specifications.

As is evident with the Geolocation API, 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.

cc: @dwsinger @pes10k @marcoscaceres

(Originally published at: https://tantek.com/2020/188/b6/das-drop-geolocation-sensor)

[anssiko]

The Geolocation Sensor specification differs from the "existing specifications" in the following ways:

• defines new features [1] that address new use cases [2] as opposed to the Geolocation API that is in maintenance and accepts no new features
• addresses significant interoperability issues e.g. around accuracy and resolution [3],
• improves API ergonomics, makes the API consistent with other similar APIs and extensible [4], and
• defines modern privacy and security protections to address known privacy and security threats, and a model that is extensible with additional mitigations [5]

The DAS WG is commitment to security and privacy focused and use case-driven specification development and believes ceasing this work would be considered harmful.

[1] https://w3c.github.io/geolocation-sensor/#intro
[2] https://w3c.github.io/geolocation-sensor/#use-cases
[3] w3c/geolocation#49
[4] https://w3c.github.io/sensors/#concepts
[5] https://w3c.github.io/sensors/#security-and-privacy

[annevk]

Why can we not maintain the Geolocation API instead? What makes this API substantially better that it's worth doubling the maintenance cost for web platform geolocation functionality? (I don't think the introduction really addresses that at all and it seems to largely defer to another document that only talks about things in a generic manner.)

[marcoscaceres]

Agree, it seems like duplicated effort for little benefit. We can address the use cases by continuing to build on the existing Geo spec. If there are interop issues (w3c/geolocation#49) we should sort those out. We seem to be doing a reasonable job at addressing the privacy and security issues in the existing spec and implementations.

[hober]

I agree with @annevk; it doesn't seem like the functionality duplication is warranted.

[xfq]

I wonder if this strategy is doable: focus on working on Geolocation Sensor, and polyfill on top of the Geolocation Sensor for Geolocation API, or produce a report if that's not possible.

Currently there's a polyfill for Geolocation Sensor on top of the existing Geolocation API, but this suggestion is the reverse of that. The advantages of this approach is that we can work on the modern API with improved security and privacy, addresses new use cases, and the Geolocation API may not need to be maintained in the future (so there's no need to duplicate the effort).

[annevk]

What is improved in terms of security and privacy?

Is there implementer support for the new use cases? (I'm not sure I understand how continuous background tracking is different from continuous foreground tracking. Geofencing seems clear, but also seems to warrant a different API shape.)

Also, in part what I object to is having different APIs. It's not clear to me that the current API is sufficiently bad that it needs a modern counterpart. It seems like it would be easily wrapped by a library.

[xfq]

The Director has approved the Devices and Sensors Working Group charter, taking into consideration the input from an experiment conducted by the Advisory Board and the TAG and decided that a chartered Working Group was best suited to address the architecture concerns (new approach to existing APIs). These concerns will not be ignored but the discussion should be moved into the individual specification issue tracker where the concerns can be addressed.

See https://lists.w3.org/Archives/Member/w3c-ac-members/2020OctDec/0034.html (member-only link) for the Director's decision.

[annevk]

My questions are not going to be addressed?

[xfq]

I think we can discuss whether a new API is the right approach in https://github.com/w3c/geolocation-sensor/issues

The group will also request TAG review and I'm sure this topic will be discussed there.

[annevk]

It's rather disappointing that concerns are not addressed in public.

[anssiko]

@xfq can you investigate if the Report of the AB/TAG Experiment that addressed these issues could be made public? I believe it would be a helpful resource for the wider community.

[plehegar]

@anssiko noted. Looking into it. Should be able to answer by Friday.

[plehegar]

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.

[anssiko]

@plehegar, thank you for this public copy. As a feedback, it would be good if these reports would be public by default in the Director-free future. Maybe stored in a central place where they can be found easily.