[![W3C][1]][2]

# Device and Sensors Working Group Teleconference

## 18 May 2017

[Agenda][3]

See also: [IRC log][4]

## Attendees

Present

    Frederick_Hirsch, Riju_Bhaumik, Mikhail_Pozdnyakov, Alexander_Shalamov,
Anssi_Kostiainen

Regrets


Chair

    Frederick_Hirsch

Scribe

    dom

## Contents

  * [Topics][5]

    1. [Welcome, scribe selection, agenda review, announcements][6]

    2. [Minutes approval][7]

    3. [HTML Media Capture][8]

    4. [Magnetometer][9]

    5. [Ambient Lights][10]

    6. [Generic Sensor API][11]

    7. [Battery Status API][12]

    8. [Other Business][13]

    9. [Adjourn][14]

  * [Summary of Action Items][15]

  * [Summary of Resolutions][16]

* * *

### Welcome, scribe selection, agenda review, announcements

<fjh> github digest (16 May) [https://lists.w3.org/Archives/Public/public-
device-apis/2017May/0019.html][17]

<fjh> github digest (9 may) [https://lists.w3.org/Archives/Public/public-
device-apis/2017May/0008.html][18]

<fjh> mail list spam removal?

<fjh> Orientation Sensor First Public Working Draft and Motion Sensors
Explainer W3C Note were published

<fjh> [https://lists.w3.org/Archives/Public/public-device-
apis/2017May/0012.html][19]

<fjh> HTML Media Capture CR published 4 May, [https://www.w3.org/TR/html-
media-capture/][20]

<scribe> ScribeNick: dom

### Minutes approval

<fjh> Approve minutes from 4 May 2017

<fjh> [https://lists.w3.org/Archives/Public/public-device-
apis/2017May/att-0004/minutes-2017-05-04.html][21]

<fjh> proposed RESOLUTION: Minutes from 4 May 2017 are approved

**RESOLUTION: Minutes from 4 May 2017 are approved
[https://lists.w3.org/Archives/Public/public-device-
apis/2017May/att-0004/minutes-2017-05-04.html][21]**

### HTML Media Capture

<fjh> Chromium implementation [https://lists.w3.org/Archives/Public/public-
device-apis/2017May/0011.html][22]

<anssik> Test results

<anssik> [http://w3c.github.io/test-results/html-media-
capture/20170428.html][23]

FJH: anything needed on this?

<anssik> Analysis of failures

anssik: my assessment is that the identified failures are false negatives

<anssik> capture_audio-manual.html

<anssik> capture_audio_cancel-manual.html

<anssik> audio capture via <input type=file> not implemented, not a normative
spec requirement since accept attribute defined in HTML spec

anssik: the first 2 failures (referenced above) are due to the fact that audio
capture is not implemented - but that's not a normative requirement

... I think the test cases can be dropped

<anssik> capture_fallback_file_upload-manual.html

<anssik> iOS unable to upload files other than media types, unable to test

anssik: the 3rd failure on ios is specific to the lack of support non-media
upload on that platform

... this means we have fairly widespread adoption of that feature

FJH: that means once the test results are updated we can exit CR

"This Candidate Recommendation is expected to advance to Proposed
Recommendation no earlier than 6 July 2017"

<anssik> [https://github.com/w3c/html-media-capture/issues/12][24]

anssi: there is one thing about how we reflect enum types in IDL attributes

... but riju doesn't think that's a blocker; we will investigate this

riju: the support for enum for attribute reflection was removed;
implementations are using DOMString

Anssi: one approach would be re-import the definition of enum into the spec

... or we could change the IDL to DOMString

... we will investigate and report back

Dom: might be worth bringing change soon so that we can stick with the current
PR entrance date of July 6

<fjh> dom: publish CR before 6 June would not need to change PR schedule

### Magnetometer

<anssik> I provided a synthesis of the discussion in:

<anssik>
[https://github.com/w3c/magnetometer/issues/16#issuecomment-302066759][25]

anssik: there are use cases both calibrated & uncalibrated magnetometer

<anssik> Editor's conclusion: There are key use cases for both calibrated
magnetometer and uncalibrated magnetometer, as well as various native apps
that make use of both of these capabilities. This suggests we should consider
uncalibrated magnetometer of similar importance to the existing (calibrated)
magnetometer.

fjh: some of the concerns are around usability / understanding from developers

... we need to straighten up how this gets presented

anssik: a separate constructor (rather than a parameters-based approach) was
the one that seemed to gain consensus

... remains to find the right naming

<anssik> Editor's conclusion: Consensus on the API design emerged, exact
naming of the interfaces remains an issue. In the interest of focusing the
energy of the participants on more burning issues than naming things, the
editor merged the PR inviting further feedback regarding naming of the
interfaces to be provided in issue #16.

fjh: a process issue around how pull requests get merged before consensus is
clear

... seems to have happened a couple of times now

anssik: the pull request just landed a proposal in the editors draft, which
seems OK as editors draft aren't expected to reflect consensus all the time

... the other case was around use cases for ambient light which I landed as
non-normative content

... I didn't see that as controversial

FJH: it's probably ok; we should hear from tobie if he feels otherwise

Anssik: this pull request that I landed was open 7 months ago, so it's good to
get preliminary closure on this (although naming isn't done yet)

### Ambient Lights

FJH: apparently we're not auto-publishing updates to that one?

anssik: bikeshed + echidna is still not completely solved

<anssik> [https://github.com/w3c/sensors/issues/74][26]

<fjh> dom: can use bikeshed command line to publish WD

anssik: I can do the "manual" thing

<fjh> dom: thought the integration was working, that Tobie had something
working, need to find out from Tobie what is not working or status

dom: not clear what's blocking the automated approach

anssik: I'll publish an updated WD of ALS

<anssik> Security and Privacy considerations for ALS

<anssik> [https://github.com/w3c/ambient-
light/issues/13#issuecomment-302393458][27]

Anssi: Alex can show that we can mitigate the threats in the article

Alex: in normal conditions, rounding to 50 lumen would enough to mitigate this
risk

<fjh> alex: hard to reproduce vulnerability without creating unrealistic
conditions of screen brightness, flashing, wake lock etc

Alex: (in our test setup)

anssik: we can leave the exact rounding to implementors

<fjh> dom: are there more threats related to light? do we have a general
theory?

<fjh> dom: can we model concerns, so we can mitigate more in advance

alex: I tried formalizing the threats, but there are too many variables in the
real world

<fjh> alex: tried to model considering reflectivity of surfaces etc but too
hard to do for variety of surfaces

alex: (e.g. reflection from real wordl objects)

... it's not a linear problem

... so it's very difficult to model the attack vector

fjh: it feels already good that we can solve that already hard-to-exploit case

anssik: so we should update the ALS spec privacy & security section with
rounding - would it be normative?

alex: this research is just a first step to initiate a conversation with
Google security team, & Lukasz

... I think we need to wait for that discussion to settle before changing the
spec

anssik: that makes sense, but I was wondering if we should be put a normative
minimum rounding threshold

### Generic Sensor API

<anssik> Rewrite Abstract Operations

<anssik> [https://github.com/w3c/sensors/pull/197][28]

anssik: I've identifed 3 issues that can be worth an overview

Mikhail: we were advised by Chrome engineers to decouple change notification
from sensors & requestAnimationFrame

... coupling in the real world creates disadvantages as it reduced the FPS

... this is important as Tobie was planning to integrate the concept of rAF in
the specs

... the pull request brings consistency between implementation & spec

... I've restructed the abstract operations so that they match with the real
world

... and dropped unneeded operations

... it also fixes some pending issues

... incl the fact that sensor objects can influence each other (where two
sensors with different options influence each other)

... I tried to make the execution flow more consistent by setting up a common
structure for the algo

<fjh> dom: aliigning with implementations can be good or bad depending on the
circumstances, is this only for chrome or is it general enough

mikhail: it's general

anssik: yes, it's implementation agnostic

<anssik> Add Input Elements to Mitigation Strategies

<anssik> [https://github.com/w3c/sensors/pull/190][29]

<anssik> [https://github.com/w3c/sensors/issues/189][30]

alex: the proposal is to stop all sensors that can interact with touch when an
element has focus - i.e. currently motion sensors and ambient light

anssik: this would mean stopping sensors when using a third-party payment
system in a game for instance

<fjh> are there any unexpected consequences?

anssik: that sounds reasonable

alex: another approach is to reduce the polling frequency in these conditions

... the point of this issue is that we can use focus state to enforce
different security policies that affect sensors

anssik: I think this is breaking new ground - we haven't found other features
in the platform using this for security/privacy

... alex can help push this forward if tobie can't

... this feels pretty important to have in the spec

<fjh> would be good to note this in the spec

<anssik> Take into account user gestures as an input for security policy
enforcement #196

<anssik> [https://github.com/w3c/sensors/issues/196][31]

<fjh> good idea to use user actions

<fjh> we discussed such an approach in privacy discussions earlier

Alex: the idea is to take into account trusted events for sensors privacy &
security

FJH: how would this work at the generic sensor level?

dom: I assume you would only get access to a sensor object out of a trusted
event callback

### Battery Status API

<anssik> [https://github.com/w3c/battery/issues/10][32]

<anssik> [https://github.com/w3c/battery/pull/11][33]

anssik: the spec was updated

riju: implementation is done, missing just test cases

anssik: question is what next step - do we need an updated CR?

fjh: +1

... I'll do a CfC once the document is ready

<scribe> **ACTION:** Anssi to prepare a new CR draft for battery [recorded in
[http://www.w3.org/2017/05/18-dap-minutes.html#action01]][34]

<trackbot> Created ACTION-799 - Prepare a new cr draft for battery [on Anssi
Kostiainen - due 2017-05-25].

<fjh> dom: impact on Firefox?

<anssik> [https://github.com/w3c/battery/issues/5#issuecomment-257617533][35]

### Other Business

<fjh> dom: Vibration API will not be shipping in Safari

<fjh> anssik: doesn’t affect anything, dead code removal

<fjh> anssik: looked into hosting but Newcastle might offer more space

<fjh> thanks, now we need to consider whether we have resources to put
together a workshop

<fjh> thanks everyone

### Adjourn

## Summary of Action Items

**[NEW]** **ACTION:** Anssi to prepare a new CR draft for battery [recorded in
[http://www.w3.org/2017/05/18-dap-minutes.html#action01][36]]


## Summary of Resolutions

  1. [Minutes from 4 May 2017 are approved
https://lists.w3.org/Archives/Public/public-device-
apis/2017May/att-0004/minutes-2017-05-04.html][37]

[End of minutes]

* * *

Minutes formatted by David Booth's [scribe.perl][38] version 1.144 ([CVS
log][39])

$Date: 2015/11/17 08:39:34 $

   [1]: https://www.w3.org/Icons/w3c_home

   [2]: http://www.w3.org/

   [3]: https://lists.w3.org/Archives/Public/public-device-
apis/2017May/0022.html

   [4]: http://www.w3.org/2017/05/18-dap-irc

   [5]: #agenda

   [6]: #item01

   [7]: #item02

   [8]: #item03

   [9]: #item04

   [10]: #item05

   [11]: #item06

   [12]: #item07

   [13]: #item08

   [14]: #item09

   [15]: #ActionSummary

   [16]: #ResolutionSummary

   [17]: https://lists.w3.org/Archives/Public/public-device-
apis/2017May/0019.html

   [18]: https://lists.w3.org/Archives/Public/public-device-
apis/2017May/0008.html

   [19]: https://lists.w3.org/Archives/Public/public-device-
apis/2017May/0012.html

   [20]: https://www.w3.org/TR/html-media-capture/

   [21]: https://lists.w3.org/Archives/Public/public-device-
apis/2017May/att-0004/minutes-2017-05-04.html

   [22]: https://lists.w3.org/Archives/Public/public-device-
apis/2017May/0011.html

   [23]: http://w3c.github.io/test-results/html-media-capture/20170428.html

   [24]: https://github.com/w3c/html-media-capture/issues/12

   [25]: https://github.com/w3c/magnetometer/issues/16#issuecomment-302066759

   [26]: https://github.com/w3c/sensors/issues/74

   [27]: https://github.com/w3c/ambient-light/issues/13#issuecomment-302393458

   [28]: https://github.com/w3c/sensors/pull/197

   [29]: https://github.com/w3c/sensors/pull/190

   [30]: https://github.com/w3c/sensors/issues/189

   [31]: https://github.com/w3c/sensors/issues/196

   [32]: https://github.com/w3c/battery/issues/10

   [33]: https://github.com/w3c/battery/pull/11

   [34]: http://www.w3.org/2017/05/18-dap-minutes.html#action01]

   [35]: https://github.com/w3c/battery/issues/5#issuecomment-257617533

   [36]: http://www.w3.org/2017/05/18-dap-minutes.html#action01

   [37]: #resolution01

   [38]: http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

   [39]: http://dev.w3.org/cvsweb/2002/scribe/