Device and Sensors Working Group Teleconference -- 18 May 2017

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

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

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

<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

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

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

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

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

<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

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

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]

<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

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

Device and Sensors Working Group Teleconference

18 May 2017

Attendees

Contents

Welcome, scribe selection, agenda review, announcements

Minutes approval

HTML Media Capture

Magnetometer

Ambient Lights

Generic Sensor API

Battery Status API

Other Business

Adjourn

Summary of Action Items

Summary of Resolutions