See also: IRC log
<scribe> ScribeNick: dom
<fjh> Updated minutes page, https://www.w3.org/2009/dap/minutes.html
<fjh> add to agenda approval of 25 Aug minutes
<scribe> Agenda: https://lists.w3.org/Archives/Public/public-device-apis/2016Oct/0000.html
<fjh> Note - TPAC specific item at end of agenda
Frederick: TPAC seems to have been great
... agenda includes minutes approval, updates on WebIDL if possible, Vibration PER
... Generic Sensor - I tried to pull out the various topics that were worth reviewing
... Concrete sensors - maybe review the naming issue
... Battery - implementation status
... *Sensor status check
... groups coordination - follow up to TPAC discussions
... anything else that we need to talk about today?
Anssi: we can give an update on our priorities for sensors, both in terms of implementations and specs
<fjh> proposed RESOLUTION: Approve 8 Sept Minutes, https://www.w3.org/2016/09/08-dap-minutes.html
RESOLUTION: Approve 8 Sept Minutes, https://www.w3.org/2016/09/08-dap-minutes.html
<fjh> Approve F2F minutes from TPAC F2F, 19-20 Sept 2016
<fjh> https://www.w3.org/2016/09/19-dap-minutes.html
<fjh> https://www.w3.org/2016/09/20-dap-minutes.html
<fjh> proposed RESOLUTION: Minutes from 19-20 Sept 2016 F2F are approved
RESOLUTION: Minutes from 19-20 Sept 2016 F2F are approved https://www.w3.org/2016/09/19-dap-minutes.html https://www.w3.org/2016/09/20-dap-minutes.html
<fjh> Thanks to Anssi for chairing.
Frederick: Thanks Anssi for chairing that meeting!
<fjh> https://www.w3.org/wiki/TPAC2016/SessionIdeas#WebIDL_Future_Work
Anssi: this was about soliciting feedback on new features that should be baked into WebIDL
... there were minutes taken that I could find out
Frederick: any direct impact on our group?
Anssi: Tobie will also be editing the WebIDL spec now
<anssik> https://www.w3.org/wiki/TPAC2016/SessionIdeas#WebIDL_Future_Work
Anssi: if we need some WebIDL adjustment, it will just be easier :)
<anssik> https://public.etherpad-mozilla.org/p/webidl
<dom_scribe> Meeting notes for WebIDL breakout
Anssi: nothing specific that concerns us at the moment; the main message is that WebIDL is now evolving
Frederick: Level 1 got published, Level 2 started right
<fjh> PER https://www.w3.org/TR/2016/PER-vibration-20160818/
<fjh> comments until 18 Sept. Next step to REC?
Frederick: the comment period for the Vibration PER has finished
<fjh> https://lists.w3.org/Archives/Public/public-device-apis/2016Sep/0024.html
Frederick: we received comments from APA that Dom replied to indicating we can't do normative changes at this stage
<fjh> dom: going to REC, have started process, waiting director decision
<fjh> dom: need to formally handle APA WG comment
<fjh> dom: especially if we add recommendation in next stage of spec
dom: we probably should file the issue in our repo with a v2 label
<scribe> ACTION: Anssi to file APA's comment as a GH issue on the vibration repo [recorded in http://www.w3.org/2016/10/06-dap-minutes.html#action01]
<trackbot> Created ACTION-775 - File apa's comment as a gh issue on the vibration repo [on Anssi Kostiainen - due 2016-10-13].
ACTION-775: mark it as v2
<trackbot> Notes added to ACTION-775 File apa's comment as a gh issue on the vibration repo.
<scribe> ACTION: Frederick to send formal answer to APA WG comment [recorded in http://www.w3.org/2016/10/06-dap-minutes.html#action02]
<trackbot> Created ACTION-776 - Send formal answer to apa wg comment [on Frederick Hirsch - due 2016-10-13].
<fjh> I will formally respond with link to issue and noting this is deferred to v.next
<fjh> Summary of long term vs short term issues/levels
<fjh> Review next steps/plans for major issues and long term vs short term
<fjh> - relationship to workers
<fjh> - permissions (including workers)
<fjh> - performance & scaling with # of sensors
Frederick: the discussions at the F2F meeting seem to have been good
<fjh> - remote sensors
<fjh> summary status of moving features from Level 2 to level 1
<fjh> remaining open issues?
Frederick: there is this discussion on short / long term evolutions, how to put that into levels
... it wasn't entirely clear from the minutes which are which
Tobie: we had WIFI issues which prevented us from updating GH issues live
... I have a good picture of what needs to be done for v1
... I'll clean this all up and make it more palatable before the next call
Frederick: so - for workers?
Tobie: that's pretty much the only one we don't have a strong decision for
... It was brought up in the TAG review by Alex for performance considerations
... Kenneth has been arguing for Worklets rather than Workers
... We assigned an action item to figure out in more depth Alex' concerns
... it's pretty much the only req that is unclear for v1/v2
... It also depends on how v1 ties with concrete sensors (it matters for some, not for others)
<fjh> Tobie notes ambient light is a special case, with fewer performance concerns
<fjh> so it can come first
Tobie: getting the performance story is critical to get this shipped in implementations
<fjh> maybe all motion sensors
Frederick: re permissions - what's the story?
Tobie: solving permissions is critical
... there is also the question on how to hook with the permissions spec
... I took an action item in the WebAppSec to make a PR for what we need, which I think is likely to be accepted
<fjh> is Maryam_Mehrnezhad offering to help with security section of spec?
Tobie: we also had discussions on privacy with maryam, a security researcher, and she was keen on helping with the privacy section of the specs
... we need both generic guidelines and sensor specific ones
Frederick: so, for permissions, we need to register names, but won't need to rearchitect the permission spec
Tobie: there was a question on whether to target low or high level names for permissions
... we've converged towards using low level names, and let UA deal with how to present the requests to the user
Frederick: this resolves the question of having confusing granularity of permissions, right?
Tobie: right
Frederick: remote sensors is deferred?
Tobie: right
Frederick: there was discussions of moving back quite a bit of stuff from level 2 to level 1
Tobie: what we did was work through the level 1, level 2, future work based on implementors feedback
... what's in github right now should be mostly the correct outcome of our triage
... 80% of the open issues just need to be folded into the spec
... once they are closed, it will get much clearer
Frederick: there were discussions on spec naming
... I've wondered if we should include "concrete sensor" somewhere in the title
... anything else that spans across multiple specs beyond naming?
<fjh> consistent spec naming (include 'concrete sensor'?)
Tobie: I think it was just naming (with the rest covered by the generic sensor spec)
Frederick: what's the status?
<fjh> Status re implementations
<fjh> https://www.w3.org/TR/2016/CR-battery-status-20160707/
<anssik> https://github.com/w3c/battery/issues/5
<fjh> this is blocking issue
<anssik> https://lists.w3.org/Archives/Public/public-device-apis/2016Jul/0000.html
Anssi: mozilla had raised a concern back in June
... of possible misuse by some services, and mozilla might consider unship this
... since then, we haven't seen concrete proposals, nor have we heard back
<anssik> http://caniuse.com/#search=battery
Anssi: my suggestion is that we should document the privacy concerns and ship the spec
... it's already shipping in browsers in any case
... I haven't heard suggestions for normative improvements, and the spec gives already a lot of freedom to UA vendors to make their implementation privacy-sensitive
Frederick: I think that the API is well in-line with privacy BP
... this sounds like a good approach
<fjh> ACTION: anssik to edit Battery to document privacy concerns related to issue 5 [recorded in http://www.w3.org/2016/10/06-dap-minutes.html#action03]
<trackbot> Created ACTION-777 - Edit battery to document privacy concerns related to issue 5 [on Anssi Kostiainen - due 2016-10-13].
<fjh> note, a pull request would be welcome
<fjh> I might be able to help here
<fjh> then next step would be PR transition request
<fjh> next steps
<fjh> https://www.w3.org/TR/ambient-light/
Anssi: we are looking to shipping this by the end of this year - it would the first one to ship
Frederick: are we going to get another implementation of that API?
Anssi: do you want us to get one pre-CR?
Frederick: no, was just wondering
Dom: I was thinking this would move to CR at the same time as Generic Sensor (although they don't have to)
Tobie: that makes sense to me too
Frederick: to me too
<fjh> I think CR would be a good tool to generate interest and implementation participation
Tobie: we should aim at making our docs CR-ready around the same time as the implementation ships
Frederick: the goal of CR is to get interest and involvement from implementors
... I think we have consensus that the two specs should go together to CR
... I would like to see it this year
Anssi: me too
Tobie: let's have this as our goal then
Anssi: current focus is on getting ambient light out of the door
Anssi: main issue here is whether to split the low / high level features
... (boolean vs distance)
... but probably not worth discussing today
<fjh> https://www.w3.org/TR/proximity/
<anssik> https://github.com/w3c/proximity/issues/4
<fjh> https://www.w3.org/TR/accelerometer/
<fjh> https://www.w3.org/TR/gyroscope/
<fjh> https://www.w3.org/TR/magnetometer/
Anssi: there was some renaming of interfaces and properties
... they are experimentally implemented as well
... these ones have a strong performance component
<fjh> goal is to CR on generic sensor & ambient light this year, others follow later
Tobie: I've been thinking of folding all these motion sensors into a single spec
... it would provide the low level as well as high level sensors that developers would like want to use in most common cases
... that's my mid-term plan for this
mikhail: so you'd like to join them into a motion sensor spec?
tobie: I would keep the API as is, but put them together in a single spec
... all motion sensors rely on these 3 low level sensors
... fused in different ways
... this would also allow to address high level sensors on platforms that don't have e.g. a gyroscope
... I'm not suggesting a generic motion sensor
<fjh> rationale is not just spec packaging but need to account for fusion and combined use of the lower level sensors
<fjh> is that right?
Tobie: having them into a single spec makes sense e.g. from a security / privacy perspective
... it would have high-level sensors such as gravity, device orientation
... it will likely be a big spec
... the spec would have at the top the 3 low level APIs (gyroscope, magnetometer, accelerometer), and then the derived high level APIs (orientation, gravity, etc)
<fjh> tobie notes some security concerns will relate to the combination of lower level APIs
mikhail: dev would still be able to use low and high level, right?
tobie: yes - they may come with different permissions
... but having it all together in a single spec will help make it more consistent
riju: but won't privacy & security moved up to generic sensor?
tobie: everything that's common should move to generic
... but there are specificities that need to appear in concrete sensors
... e.g. security concerns specific to high frequency sensors such as key logging don't belong in generic sensor
... that's my current thinking - nothing set in stone
Frederick: let's skip
<fjh> incubating a generic-sensor based geo API (noted during F2F) - next step?
Frederick: so there was this plan to incubate a geo location API as generic sensor?
Anssi: no high priority, but Giri was happy for us to incubate something
... plan is to do it in the WICG
... geo requires some of the v2 features (e.g. one-shot request)
<fjh> coordinate with Web of Things CG/IG, review security/privacy practices?
Frederick: what was the outcome of the discussions with WoT IG?
... was that mostly a shared awareness discussion?
Anssi: yes - no specific action out of this
... we also had a TAG member (Hadley) attending during the first day
Anssi: great wine and food!
... no wine for lunch as in France though
... Next one is in the San Francisco Airport >:)
... thanks riju, mikhail, alex, tobie for joining
<fjh> Updated minutes page, https://www.w3.org/2009/dap/minutes.html
<dom_scribe> DAS teleconferences calendar
<fjh> none