[admin] Draft minutes 11 Jan 2018 teleconference

Hi All,

The draft minutes from today's teleconference are at:

https://www.w3.org/2018/01/11-dap-minutes.html


And below the same in plain text format. Thanks Fuqiao for scribing and everyone for participating.

Thanks,

-Anssi (Device and Sensors WG Chair)



   [1]W3C

      [1] https://www.w3.org/


                             – DRAFT –
                    DAS Working Group teleconference

11 January 2018

   [2]Agenda [3]IRC log

      [2] https://lists.w3.org/Archives/Public/public-device-apis/2018Jan/0002.html

      [3] https://www.w3.org/2018/01/11-dap-irc


Attendees

   Present
          Alexander_Shalamov, Anssi_Kostiainen, Fuqiao_Xue,
          Mikhail_Podnyakov, Wanming_Lin

   Regrets

   Chair
          Anssi_Kostiainen

   Scribe
          xfq, xfq_

Contents

     * [4]Meeting Minutes
         1. [5]Welcome, agenda review, announcements
         2. [6]Sensor APIs wide review
         3. [7]Generic Sensor API Level 2 feature cherry picking
         4. [8]Battery Status API privacy enhancements
         5. [9]Rechartering

Meeting Minutes

Welcome, agenda review, announcements

   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

Sensor APIs wide review

   <anssik> [10]https://github.com/w3c/sensors/issues/299


     [10] https://github.com/w3c/sensors/issues/299


   anssik: We have this meta-issue (see link on IRC)

   <anssik> [11]https://github.com/w3ctag/design-reviews/issues/

   207

     [11] 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

   <anssik> [12]https://cryptpad.w3ctag.org/code/#/1/view/

   wWjGyJj9JsQEXugZaB9juA/
   sLQghIPquNLW5dOftFYcttHFvcZFlNCYWbYa14Trgn8/

     [12] https://cryptpad.w3ctag.org/code/#/1/view/wWjGyJj9JsQEXugZaB9juA/sLQghIPquNLW5dOftFYcttHFvcZFlNCYWbYa14Trgn8/


   Alexander: we don't have formal response from TAG yet

   <anssik> [13]https://github.com/w3ctag/design-reviews/issues/

   207#issuecomment-351557619

     [13] 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> [14]https://github.com/w3c/accelerometer/issues/30


     [14] https://github.com/w3c/accelerometer/issues/30


   <anssik> [15]https://github.com/w3c/gyroscope/issues/27


     [15] 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

Generic Sensor API Level 2 feature cherry picking

   anssik: The Generic Sensor API is considered feature complete,
   and implemented in Chrome

   <anssik> [16]https://github.com/w3c/sensors/issues/257


     [16] 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

   [17]https://github.com/w3c/sensors/issues/63


     [17] 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> [18]https://github.com/w3c/sensors/projects/5


     [18] 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

Battery Status API privacy enhancements

   <anssik> [19]https://github.com/w3c/battery/pull/

   13#issuecomment-356590244

     [19] 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> [20]http://w3c.github.io/dap-charter/

   DeviceAPICharter.html

     [20] http://w3c.github.io/dap-charter/DeviceAPICharter.html


   anssik: let us know in this PR if you have a good proposal

Rechartering

   <anssik> [21]https://github.com/w3c/dap-charter/


     [21] https://github.com/w3c/dap-charter/


   <anssik> [22]https://wicg.github.io/geolocation-sensor/


     [22] 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> [23]https://w3c.github.io/deviceorientation/

   spec-source-orientation.html

     [23] 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!

Received on Thursday, 11 January 2018 14:48:57 UTC