See also: IRC log
<fjh> GitHub digest (25 April): https://lists.w3.org/Archives/Public/public-device-apis/2017Apr/0029.html
<fjh> GitHub digest (2 May): https://lists.w3.org/Archives/Public/public-device-apis/2017May/0000.html
<scribe> ScribeNick: anssik
<fjh> Approve minutes from 20 April 2017
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2017Apr/att-0028/minutes-2017-04-20.html
<fjh> proposed RESOLUTION: Minutes from 20 April 2017 are approved
RESOLUTION: Minutes from 20 April 2017 are approved
<fjh> FPWD of Orientation Sensor specification and FPWD of Motion Explainer Note
<fjh> Approved for publication, https://lists.w3.org/Archives/Member/chairs/2017AprJun/0028.html
snapshots prepared: https://lists.w3.org/Archives/Public/public-device-apis/2017May/0002.html
<fjh> ACTION: fjh to submit publication request for Orientation sensor and motion explainer [recorded in http://www.w3.org/2017/05/04-dap-minutes.html#action01]
<trackbot> Created ACTION-798 - Submit publication request for orientation sensor and motion explainer [on Frederick Hirsch - due 2017-05-11].
<fjh> thanks anssi
fjh: I'll proceed with the request
<fjh> Publication request processed; publication in progress for 4 May 2017.
<fjh> CR publication draft fixes to fragments, https://github.com/w3c/html-media-capture/commit/e2424bb8dcbce7c479651ccc02a271c043e2a2ee
<fjh> close ACTION-788
<trackbot> Closed ACTION-788.
published https://www.w3.org/TR/2017/CR-html-media-capture-20170504/
<fjh> ACTION-787?
<trackbot> ACTION-787 -- Kenneth Christiansen to Review screen orientation api with alexander -- due 2017-04-15 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/787
<fjh> close ACTION-787
<trackbot> Closed ACTION-787.
shalamov: have submitted feedback via GH
<fjh> shalamov: have a few more minor issues. Have heard nothing back from editors.
<fjh> close ACTION-792
<trackbot> Closed ACTION-792.
fjh: easy things first, we should publish a new WD
tobie: I wanted to do it yesterday, will do it today
anssik: +1 to publish
<fjh> already agreed to do this
<fjh> ACTION-779?
<trackbot> ACTION-779 -- Tobie Langel to Propose changes to address garbage collection issues -- due 2016-12-08 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/779
fjh: looking through actions, did you handle the GC issue tobie
tobie: there's a bunch of GH issues on this topic
<fjh> ACTION-799: issues recorded in github
<trackbot> Notes added to ACTION-799 .
<fjh> close ACTION-799
<trackbot> Closed ACTION-799.
<fjh> ACTION-781?
<trackbot> ACTION-781 -- Wanming Lin to Track changes in generic sensor api and update ambient light tests accordingly -- due 2016-12-08 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/781
<fjh> close ACTION-781
<trackbot> Closed ACTION-781.
https://github.com/w3c/web-platform-tests/tree/master/ambient-light
<fjh> tobie: reviewed tests including ambient light
shalamov: I'll check if we pull in the latest wpt tests to Chromium
<fjh> ACTION-785?
<trackbot> ACTION-785 -- Tobie Langel to Update milestones on generic sensor issues -- due 2017-03-16 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/785
<fjh> tobie to work on cleaning up issue tracker
tobie: triaging GH issues in progress
<fjh> tobie: first thinking biggest issue is motion, fix permissions / privacy, then look at ALS; but since orientation sensors exist, but implementers not concerned about theoretical attacks, have use cases for ALS so now thinking deal with that first
<fjh> alex: considering security privacy in parallel
<fjh> ScrtibeNick: fjh
tobie: adding generic mitigation strategies to the spec
... expanding on https://w3c.github.io/sensors/#mitigation-strategies
... explaining what is in PR https://github.com/w3c/sensors/pull/191
<tobie> https://w3c.github.io/sensors/#mitigation-strategies
<tobie> https://github.com/w3c/sensors/pull/191
<fjh> tobie: listing mitigation strategies is valuable since can now enable variety of use cases
<fjh> tobie: working on fixes. also how to fit into HTML event loop - tests lacking on HTML side
tobie: in addition, I'm looking at how to integrate this with the event loop in the HTML
<fjh> “Sensor APIs implementation in Chromium: Generic Sensor Framework"
shalamov: few month ago, me and mikhail started to work on a design doc that try to address the permission, security and privacy issues
tobie: initially though this would be a quality of implementation issue turned out to be false assumption, implementers need more concrete guidance
<fjh> threat levels, security policies, permissions etc should be in w3c spec that spans groups
<Zakim> dom, you wanted to mention interest on the previously discussed permission++ workshop
tobie: Generic Sensor API to define shared S&P terminology for other specs to use
dom: gauging interest to have a workshop around the topic
... nothing to announce yet, but people at the AC meeting were supportive
... ws needs to be organized by Wendy and Dom, but lack of cycles currently
<tobie> https://github.com/w3c/sensors/issues/171
tobie: need input from kenneth_ on an issue 171
kenneth_: I'll look at the issue tomorrow
fjh: question on threats, seems we're going back and forth on whether frequency can address security-privacy threats
tobie: applicable mitigation strategies depend on the use cases and sensor types
<fjh> makes sense
<fjh> another example of why listing threats and mitigation strategies is a good approach
tobie: it's a tradeoff, for example frequency, find a good enough frequency that allows the implementation of the use cases while still be security and privacy preserving
shalamov: for ALS we try to mitigate risks by rounding, provide data in steps
... for motion sensors, we are thinking of tackling the threats using focus state
... if an input element that can be focused is focused waiting for user input, we can stop or slow the sensors down to the point they cannot be used for attacks
tobie: having list of risks and mitigation strategies helps us find the solutions for each of these sensors
anssik: is this new information, no existing knowledge on mitigations that work for the Web?
<fjh> tobie: listing problems without offering mitigations is not enough, since security limitations on APIs may not solve right security issues and may prevent use cases
<fjh> this is new for W3C, elsewhere listing threats along with mitigations is done
https://w3c.github.io/battery/#security-and-privacy-considerations
The user agent should not expose high precision readouts of battery status information as that can introduce a new fingerprinting vector.
<fjh> anssik: implementers seem to ignore security and privacy considerations
<fjh> might not if mitigations are mentioned
<fjh> anssik: also they ignore things that are not testable
<fjh> can make testable mitigation strategies
<fjh> anssik: need mitigations to be interoperable
<fjh> anssik: when are we publishing CR for generic sensor API
<fjh> tobie: let me think about it, need to clean up document
tobie: will need to cleanup issues first to be able to say where we stand in terms of CR
<fjh> tobie: 15 open issues, can get it down to 3
<fjh> ACTION-778?
<trackbot> ACTION-778 -- Dominique Hazaël-Massieux to Review tets results pull request for ambient light https://github.com/w3c/test-results/pull/72 -- due 2016-12-08 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/778
<fjh> close ACTION-778
<trackbot> Closed ACTION-778.
<fjh> ACTION-774?
<trackbot> ACTION-774 -- Andrey Logvinov to Transfer https://github.com/w3c/ping/blob/master/wake-lock-privacy.md as github issues -- due 2016-09-15 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/774
<fjh> anssik: related to Ambient Light - attack Lucasz noted - interactions among sensors, possibly related to generic sensor API
anssik: ALS attack uses Wake Lock API to keep the screen awake
<fjh> anssik: wake lock not shipping yet, but should take this potential attack into account
<fjh> anssik: possible topic for workshop
<fjh> @tobie a github issue for this on ALS
tobie: attended a workshop organized by UK university
... workshop scope: how standards make privacy impact on users, standards process, IP, open source
... I gave perspective on the W3C aspects, Lukasz shared battery paper findings
... talks around fingerprinting etc.
<fjh> tobie: Lucasz noted that often API is used for unintended use
battery status mitigations against the tracking scripts: https://github.com/w3c/battery/issues/10
<fjh> ACTION-777?
<trackbot> ACTION-777 -- Anssi Kostiainen to Edit battery to document privacy concerns related to issue 5 -- due 2016-10-13 -- OPEN
<trackbot> http://www.w3.org/2009/dap/track/actions/777
<fjh> in progress
<fjh> should we complete questionnaire given likely to have workshop instead
<fjh> dom: sounds like workshop and issues with travel suggests not planning on TPAC, also Tobie noted he cannot attend TPAC
<fjh> +1
<fjh> anssik: can we have WG meeting in conjunction with workshop?
<fjh> dom: yes
<fjh> anssik: would prefer not to have DAS at TPAC
<fjh> proposed RESOLUTION: DAS will not meet at TPAC
RESOLUTION: DAS will not meet at TPAC
<fjh> dom: can scale down to simply WG meeting if workshop not possible, but expect workshop should be possible
<fjh> dom: have smaller scale workshop
<fjh> anssik: can you please check into possible Intel hosting
<fjh> tobie: we need to get Google and Mozilla participation if we want permissions work to progress
<fjh> fjh: we need to frame this workshop appropriately, so it is worthwhile and gets participation; plan for Europe, need early idea on venue to avoid later problems
<fjh> none
<fjh> Thanks everyone