comments on Devices and Sensors Working Group charter

I've been unable to submit the below comments as part of the review
form, because it gives me the error:

> Your answers have NOT been registered because of the following errors:
> 
>     The comment text provided for question 'Support for the Proposal ' is not valid UTF-8

Therefore I'm sending them to www-archive, and hopefully I'll be
able to link to them.

-David


------

We'd like to see this charter change a bit.  That desire for change
comes out of our concern about the privacy implications of many of these
APIs.  Researchers have demonstrated that a number of these APIs can be
used for tracking users or for learning various other types of
information about what users are doing, and some of these have actually
been used for tracking web users.  See, for example, this pair of
articles about use of the battery status API for tracking:
https://www.theguardian.com/technology/2016/aug/02/battery-status-indicators-tracking-online
https://www.theguardian.com/technology/2016/nov/01/firefox-disable-battery-status-api-tracking

The APIs proposed in this charter have varying amounts of privacy risk.
It is likely that some of them can be structured to provide a reasonable
amount of information with meaningful user consent, but some of them
cannot.  Therefore we'd like it to be more explicit in the charter that
concluding that a specification cannot be done in an appropriate way is
a possible success condition of the working group.  (The charter
currently mentions that "APIs that cannot be demonstrated to be
implementable securely within the default browser context will not be
released.", but this doesn't explicitly mention privacy and it doesn't
explicitly say that abandoning work is a desirable outcome if that's the
appropriate choice.)

The APIs that we're most concerned about in this regard are:
  Battery Status API
    See articles cited above; we previously unshipped support for this.
  Network Information API
    (I should have more details here, but don't.)
  DeviceOrientation Event specification
    (I should have more details here, but don't.)
  Proximity Sensor
  Ambient Light Sensor
  Accelerometer
  Gyroscope
  Magnetometer
  Orientation Sensor
    These sensors have the problem that web access at a high enough
    resolution to be useful for many of the use cases allows sites using
    the API to learn various sorts of information about the user that
    are hard to explain in a way to get good informed consent, such as
    where the user is, what sort of activities they're doing, what
    they're typing, what activities are happening nearby, etc.

    See, for example:
    https://blog.lukaszolejnik.com/privacy-of-ambient-light-sensors/
    https://blog.lukaszolejnik.com/stealing-sensitive-browser-data-with-the-w3c-ambient-light-sensor-api/
    https://blog.lukaszolejnik.com/privacy-analysis-of-w3c-proximity-sensor/
    https://www.bleepingcomputer.com/news/software/firefox-gets-privacy-boost-by-disabling-proximity-and-ambient-light-sensor-apis/
    https://dieidee.eu/2015/10/14/accelerometer-and-gyroscope-sensor-data-can-create-a-serious-privacy-breach/



While it's useful to have a forum that is appropriate for discussion of
how to address these privacy issues, I don't think there is currently
consensus that it is appropriate to make these APIs part of the web
platform.  Normally I think that would suggest that the documents aren't
ready to be put on the Recommendation track; in this case things are
more awkward because many of them are already on the Recommendation
track.  (That said, it's not entirely clear to me whether AC review of a
charter is expected to represent consensus that a specification is
appropriate for the Web.)

Given that, it would be preferable to move some of these documents off
of the Recommendation track back to earlier stages of incubation until
there's a clearer path for addressing the privacy concerns with them.
If that isn't possible, the working group should at least be given the
explicit possible success criterion of choosing that particular
specifications are not viable, and should be tasked with building
broad consensus outside of the working group that the proposed APIs are
suitable for the web.

-- 
𝄞   L. David Baron                         http://dbaron.org/   𝄂
𝄢   Mozilla                          https://www.mozilla.org/   𝄂
             Before I built a wall I'd ask to know
             What I was walling in or walling out,
             And to whom I was like to give offense.
               - Robert Frost, Mending Wall (1914)