– DRAFT –
DAS Working Group teleconference
11 January 2018
anssik: Last time we met was before TPAC
… the wide review period ended at the end of last year
… let's plan on the following actions
… we have informal feedback from TAG, Security IG, and PING
… we can look at usage stats of Battery Status API
… also recharting of DAS
… any other agenda items?
… Generic Sensor API Level 2 feature cherry picking
<anssik> https://github.com/w3c/sensors/issues/299
anssik: We have this meta-issue (see link on IRC)
<anssik> https://github.com/w3ctag/design-reviews/issues/207
anssik: all horizontal groups except i18n and a11y groups were asked for feedback
… let's go through them one-by-one
… in the TAG review, I'm happy that Mozilla is looking into the new sensor APIs
… I think all feedback in the issue can be addressed as clarifications in specs
… there's no real blockers
Alexander: we don't have formal response from TAG yet
<anssik> https://github.com/w3ctag/design-reviews/issues/207#issuecomment-351557619
anssik: Tom Ritter is a security researcher from Mozilla, and I'm happy we can have his feedback.
<anssik> https://github.com/w3c/accelerometer/issues/30
<anssik> https://github.com/w3c/gyroscope/issues/27
anssik: see links on IRC for PING's feedback for Accelerometer and Gyroscope
… we decided to skip i18n/a11y wide review because it's mostly out-of-scope
… see other groups' feedback in the issue
anssik: The Generic Sensor API is considered feature complete, and implemented in Chrome
<anssik> https://github.com/w3c/sensors/issues/257
anssik: the Generic Sensor API is a dependency of the WebVR API on Chrome, in some devices
… I'll let Alexander briefly summrize the issue linked above.
Alexander: sometimes the window manager @@ X / Y
… @@ from one coordinate system to another coordinate system
… @@ developer can use this API instead of do it manually
anssik: @@4
… In order to make it happen developers have to use the Screen Orientation API to do this manually
PROPOSED RESOLUTION: #257 will be made level 1
https://github.com/w3c/sensors/issues/63
anssik: the way to change frequency setable
… one use case is to save resources of the UIs
… there are other use cases as well
… I propose we cherry-pick it into level 1 to get it in CR
PROPOSED RESOLUTION: #63 will be added to level 1
<anssik> https://github.com/w3c/sensors/projects/5
anssik: we still need more use cases, and think more about security/privicy considerations
… see all level 2 issues in the link above
<anssik> https://github.com/w3c/battery/pull/13#issuecomment-356590244
anssik: a couple of months ago, we looked at cross-origin usage and insecure origin usage of the Battery Status API
… they are 1.1% and 0.7% respectively
… as Mounir said in that PR, security/privacy restrictions will block much usage of the API
… please take a look at the issue
<anssik> http://w3c.github.io/dap-charter/DeviceAPICharter.html
anssik: let us know in this PR if you have a good proposal
<anssik> https://github.com/w3c/dap-charter/
<anssik> https://wicg.github.io/geolocation-sensor/
anssik: If you have feedback for the draft charter, please go to the GitHub repo and file a new issue
<anssik> https://w3c.github.io/deviceorientation/spec-source-orientation.html
anssik: we added Geolocation Sensor
… we also added DeviceOrientation Event specification, because the Geolocation WG was closed
… we'll get the Wake Lock API impl aligned
… Thanks everyone!
Succeeded: s/In order to make it happen developers have to use the Screen Orientation API to do this manually/... In order to make it happen developers have to use the Screen Orientation API to do this manually/
Succeeded: s/SOLUTION/RESOLUTION/
Succeeded: s/in that issue/in that PR/