See also: IRC log
<fjh> github digest (16 May) https://lists.w3.org/Archives/Public/public-device-apis/2017May/0019.html
<fjh> github digest (9 may) https://lists.w3.org/Archives/Public/public-device-apis/2017May/0008.html
<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
<fjh> HTML Media Capture CR published 4 May, https://www.w3.org/TR/html-media-capture/
<scribe> ScribeNick: dom
<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
<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
<fjh> Chromium implementation https://lists.w3.org/Archives/Public/public-device-apis/2017May/0011.html
<anssik> Test results
<anssik> http://w3c.github.io/test-results/html-media-capture/20170428.html
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
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
<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)
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
<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
<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
<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
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/of upload/non-media upload/ Succeeded: s/with touch/with touch when an element has focus/ Succeeded: s/we discussed in privacy discussions earlier/we discussed such an approach in privacy discussions earlier/ Succeeded: s/fjh: thanks,/thanks,/ Succeeded: s/fjh: thanks everyone/thanks everyone/ Present: Frederick_Hirsch Riju_Bhaumik dom Mikhail_Pozdnyakov Alexander_Shalamov Anssi_Kostiainen Found ScribeNick: dom Inferring Scribes: dom Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2017May/0022.html Found Date: 18 May 2017 Guessing minutes URL: http://www.w3.org/2017/05/18-dap-minutes.html People with action items: anssi[End of scribe.perl diagnostic output]