06:53:40 <RRSAgent> RRSAgent has joined #dap
06:53:40 <RRSAgent> logging to https://www.w3.org/2018/10/23-dap-irc
06:53:56 <xfq> Meeting: Devices and Sensors WG TPAC F2F - Day 2/2
06:54:13 <xfq> RRSAgent, make log public
06:54:18 <xfq> RRSAgent, make minutes v2
06:54:18 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/23-dap-minutes.html xfq
06:55:21 <anssik> anssik has joined #dap
06:58:23 <reillyg> reillyg has joined #dap
07:03:36 <xfq> RRSAgent, make minutes v2
07:03:36 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/23-dap-minutes.html xfq
07:04:06 <xfq> scribenick: xfq
07:07:28 <larsgk> larsgk has joined #dap
07:07:45 <johnpallett> johnpallett has joined #dap
07:08:36 <anssik> Present+ Anssi_Kostiainen, Reilly_Grant, Fuqiao_Xue, Flaki, Yoshiaki_Tanaka, John_Pallett, Mark_Foltz, Lars_Knudsen, Kenneth_Christiansen, Yang_Gu, Mike_ONeill, Takeshi_Sano, Heejin_Chung
07:08:45 <flaki> flaki has joined #dap
07:09:01 <anssik> Present+ Raphael_Kubo_da_Costa
07:09:22 <xfq> Topic: Welcome and introductions
07:09:56 <xfq> anssik: I'm Anssi Kostiainen from Intel, co-chair of the group
07:10:33 <xfq> reillyg: I'm Reilly Grant from Google, co-chair of the group
07:10:46 <xfq> Flaki: I'm Flaki from Mozilla
07:11:23 <xfq> Lars: Invited Expert of the group
07:11:43 <xfq> Kenneth Christiansen: I'm Kenneth Christiansen from Intel
07:11:59 <xfq> Yang_Gu: I'm Yang Gu from Intel
07:12:24 <xfq> Mike_ONeill: I'm Mike ONeill, observer
07:12:34 <xfq> Heejin_Chung: I'm Heejin Chung from Samsung
07:12:48 <xfq> [more intro]
07:13:21 <xfq> anssik: We'll discuss the findings from the W3C Workshop on Permissions and User Consent
07:13:42 <xfq> Topic: Agenda bashing
07:14:01 <xfq> Anssi: After that briefing, we have 2 hours to discuss Generic Sensor Level 2
07:16:15 <xfq> ... Bryan Bernhart pointed out @@ yesterday
07:16:52 <xfq> ... with Reilly we found out three high level stuff to discuss
07:17:11 <xfq> ... exposing sensors in service workers, which is highly controversial
07:18:16 <xfq> present+ Sam_Weiler
07:18:37 <xfq> ... another high level topic is high frequency & batching
07:19:34 <wanming> wanming has joined #dap
07:20:09 <Yang_Gu> Yang_Gu has joined #dap
07:20:54 <xfq> ... Lars will share his finding about sensor discovery
07:21:03 <rakuco> rakuco has joined #dap
07:21:34 <xfq> s/his finding/his findings/
07:22:20 <xfq> reillyg: An additional topic is the relation to rAF
07:22:27 <tomayac> tomayac has joined #dap
07:23:14 <xfq> anssik: for Orientation Sensor, there's a proposal to provide Euler angles
07:23:48 <xfq> ... after lunch, we'll have discussions about WebDriver Extension API for Generic Sensor
07:24:42 <xfq> ... Reilly did some research of Web Bluetooth
07:27:02 <xfq> anssik: We'll also discuss Shape Detection API, WebUSB, WebHID and Serial APIs
07:27:16 <xfq> ... they're kind of in the scope of the working group
07:27:50 <anssik> Present+ Zoltan_Kis
07:28:36 <anssik> Present+ Sam_Weiler
07:28:37 <xfq> ... there're more people in the room, could you briefly introduce yourself?
07:28:56 <xfq> Zoltan_Kis: I'm Zoltan Kis, working on Web of Things API
07:29:05 <anssik> Present+ Thomas_Nattestad
07:29:16 <xfq> Sam_Weiler: I'm Sam Weiler from W3C, working on Security and Privacy
07:29:25 <xfq> Thomas_Nattestad: I'm Thomas Nattestad from Google
07:30:15 <xfq> anssik: Thomas will report the findings from the permissions workshop
07:30:26 <xfq> Topic: Findings from the W3C Workshop on Permissions and User Consent
07:31:21 <weiler> weiler has joined #dap
07:31:27 <weiler> present+
07:31:42 <xfq> anssik: There were good browser vendors attendance in the workshop
07:31:47 <weiler> https://www.w3.org/Privacy/permissions-ws-2018/cfp.html
07:31:55 <weiler> https://www.w3.org/Privacy/permissions-ws-2018/schedule.html
07:32:11 <anssik> -> https://www.w3.org/Privacy/permissions-ws-2018/schedule.html W3C Workshop on Permissions and User Consent Schedule
07:32:16 <xfq> present- weiler
07:33:05 <xfq> Thomas: We can go through the schedule
07:34:21 <xfq> Thomas: @@
07:34:21 <xfq> ... another big problem re permissions is upfront notification about permissions
07:35:04 <xfq> ... how users should be able to control their settings
07:35:04 <xfq> ... how much we should be expecting from the users
07:35:16 <xfq> ... we had interesting discussion on XR
07:35:22 <xfq> s/discussion/discussions/
07:35:59 <xfq> ... ask permissions in contexts, e.g., in AR/VR experiences
07:36:42 <xfq> ... a "would you like this website to give you VR experience?" prompt
07:36:42 <xfq> ... the users would need to understand the implications
07:38:08 <xfq> Anssi: the UI/UX of the permissions can be improved too
07:38:08 <xfq> ... similar to on-boarding of apps
07:38:37 <xfq> ... animation/interaction instead of a string
07:38:53 <xfq> ... can we have an alternative way to do permissions prompt?
07:39:20 <tomayac> tomayac has joined #dap
07:40:12 <xfq> ???: a big challenge of VR in general is that users should understand what VR does
07:40:12 <xfq> ... understand what all the computer vision algorithms can do with data from camera
07:40:34 <xfq> anssik: like time-bound permissions discussed yesterday
07:40:42 <hjchung> hjchung has joined #dap
07:40:56 <xfq> weiler: real-world geometry
07:42:36 <johnpallett> link to Immersive Web CG repo for privacy & security is here: https://github.com/immersive-web/privacy-and-security
07:42:38 <xfq> s/???: a/johnpallett/
07:42:47 <xfq> s/johnpallett/johnpallett: a/
07:43:11 <johnpallett> Explainer in progress capturing threat vectors and possible mitigations here: https://github.com/immersive-web/privacy-and-security/blob/master/EXPLAINER.md
07:43:20 <xfq> anssik: we need to find a novel way to animate/visualize the permissions
07:44:36 <xfq> reillyg: @@
07:44:36 <xfq> ... how privacy-sensative low-level data makes sense in high level
07:44:50 <xfq> s/sensative/sensitive/
07:46:06 <xfq> John_Pallett: @@ bundling not just permissions, but also information the users should know
07:47:28 <xfq> Thomas: there're two very different kind of permissions
07:47:28 <xfq> ... one is the really dangerous ones, blackmail etc.
07:47:28 <xfq> ... the other is more data
07:47:28 <xfq> ... geolocation is in the second camp
07:47:52 <xfq> ... it can be used for ad-targeting
07:51:27 <xfq> reilly: even for the geolocation case, it can be in the first camp
07:51:27 <xfq> ... some users do not want to share their data, and may not know that their geolocation data was used by the website
07:51:39 <xfq> s/their data/their location/
07:53:29 <xfq> Thomas: currently, fingerprinting is fairly easy
07:53:29 <xfq> ... in the future we can use code analysis to detect if the website is using permissions they're not supposed to use
07:53:29 <xfq> ... instead of disabling the feature completely
07:55:32 <xfq> Mike_ONeill: API of metadata of permissions
07:55:32 <xfq> Thomas: what if people lie?
07:55:32 <xfq> Mike_ONeill: then they break the law
07:58:13 <xfq> Mike_ONeill: @@
07:58:13 <xfq> anssik: the concept of URL doesn't exist for normal people
07:58:13 <xfq> ... e.g., iOS Safari only displays the domain name
07:59:02 <reillyg> s/reilly: even/reillyg: even/
07:59:58 <xfq> ... example.com uses [placeholder] data for [how long]
08:04:44 <xfq> [scribe missed some parts]
08:04:54 <anssik> Present+ Alex_Turner
08:07:49 <xfq> anssik: you need to give the developers the incentive, otherwise they'll ask more than they need
08:08:05 <xfq> ... that's why better UX is needed
08:10:52 <xfq> weiler: a question we must be asking, is if we should add this at all
08:10:52 <xfq> ... some users might not be able to understand the depth of risk they're taking here
08:12:02 <xfq> Thomas: Electron as an example
08:12:02 <xfq> ... people use it because they need it
08:12:02 <xfq> ... but it's very insecure sometimes
08:13:54 <anssik> RRSAgent, draft minutes v2
08:13:54 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/23-dap-minutes.html anssik
08:13:58 <xfq> Thomas: perhaps PWA installation is not as much trust as native installation
08:19:31 <xfq> reillyg: in the Chrome manifest, there are required permissions, and optional permissions
08:20:42 <reillyg> s/Chrome manifest/Chrome extension manifest/
08:21:09 <tomayac> Present+ tomayac
08:21:52 <tomayac> Permissions could be listed in a `permissions` property in the Web App Manifest
08:22:17 <tomayac> And then grouped by level of “scariness”, which would allow less scary ones to be bundled in prompting
08:23:41 <xfq> weiler: Nick Doty did write a guide for permissions
08:23:42 <xfq> ... it might help
08:24:23 <xfq> https://lists.w3.org/Archives/Public/public-2018-permissions-ws/2018Oct/0000.html
08:24:57 <tomayac> “permissions”: [{“push_notifications”: {“rationale”: [“Inform the user of new content they have shown interest in”, “Alert the user of general breaking news”]}}]
08:25:01 <xfq> weiler: changes to oauth about how oauth permissions might be used
08:25:39 <xfq> ... different trust of the browser chrome vs the web page
08:26:22 <xfq> ... there was a workshop about permissions in 2014
08:26:23 <xfq> https://www.w3.org/2014/07/permissions/
08:28:21 <xfq> anssik: is the guide created by Nick for spec authors?
08:28:35 <xfq> weiler: yes
08:28:43 <xfq> ... spec authors, or browser vendors
08:32:28 <youenn> youenn has joined #dap
08:32:34 <xfq> weiler: for the privacy bits, which is mostly this is about
08:32:34 <xfq> ... helping their effort is probably the best way to push this forward
08:32:34 <xfq> anssik: some privacy experts might not be UI/UX experts
08:40:41 <tomayac> The spec could add recommendations as to the bundling of permissions (based on “once”, “permanent”,…)
08:42:00 <hjchung> hjchung has joined #dap
08:44:49 <yang_gu> yang_gu has joined #dap
08:45:27 <anssik> RESOLUTION: Permissions being a cross-cutting concern across multiple groups we believe that we should find a forum for discussing these issues and that specifications should provide developers with affordances for expressing the scope of permission requests (i.e. duration and bundling) and the rationale for the permission request so that browser vendors can process that data to inform their UX.
08:46:26 <anssik> ACTION: ThomasTheDane to connect Reilly with relevant Chrome PM to explore cross-group cutting group affordances
08:46:26 <trackbot> Error finding 'ThomasTheDane'. You can review and register nicknames at <https://www.w3.org/2009/dap/track/users>.
08:46:29 <xfq> RRSAgent, make minutes v2
08:46:29 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/23-dap-minutes.html xfq
08:53:20 <xfq> xfq has joined #dap
09:06:20 <iclelland> iclelland has joined #dap
09:21:40 <anssik> scribenick: anssik
09:21:58 <anssik> Present+ Ada_Rose_Cannon
09:22:46 <anssik> Ada: Ada from Samsung IWWG co-chair, interested in ALS
09:23:17 <anssik> Ada: TOPIC: Ambient Light Sensor
09:23:34 <anssik> s/Ada: TOPIC: Ambient Light Sensor/TOPIC: Ambient Light Sensor/
09:24:32 <anssik> Ada: interested in IW use cases to allow the model change according to the ambient light of the environment
09:24:54 <anssik> Reilly: ALS API has an open PR for RGB support in addition to intensity
09:25:20 <wanming1> wanming1 has joined #dap
09:26:12 <anssik> ... encourage to note the IW use case in the respective issue https://github.com/w3c/ambient-light/issues/9
09:27:11 <anssik> Ada: feedback from the developer is that this is highly requested
09:27:23 <larsgk> larsgk has joined #dap
09:29:17 <anssik> ... without this support, need to extract this RGB information from camera
09:29:27 <QingAn> QingAn has joined #dap
09:30:39 <anssik> Reilly: if we didn't provide ALS as a dedicated API for RGB, you could attach an instance of the AmbientLightSensor to the XRDevice interface with that as an extension
09:31:14 <ada> ada has joined #dap
09:31:22 <ada> https://github.com/immersive-web/proposals/issues/27
09:31:53 <anssik> Reilly: also Gamepad could reuse e.g. Accelerometer
09:32:25 <yamagile> yamagile has joined #dap
09:36:18 <anssik> RRSAgent, draft minutes v2
09:36:18 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/23-dap-minutes.html anssik
09:39:04 <johnpallett> johnpallett has joined #dap
09:39:44 <anssik> [agreement]
09:39:46 <anssik> RESOLUTION: promote RGB feature to Level 1 to address the Immersive Web use case
09:41:43 <zolkis> zolkis has joined #dap
09:41:59 <anssik> TOPIC: Generic Sensor Level 2
09:42:03 <anssik> -> https://github.com/w3c/sensors/projects/5 Generic Sensors Level 2
09:44:21 <anssik> Reilly: when it comes to Workers, we generally agreed that adding support for dedicated workers has not issues, since they're attached to a frame
09:45:05 <anssik> ... benefit is that will help avoid jank
09:45:16 <anssik> anssik: what is the implementation effort to expose to workers?
09:45:40 <anssik> Reilly: not significant
09:46:42 <anssik> Tom: what can you do in the background with WebBluetooth API?
09:48:56 <anssik> Reilly: for WebUSB and WebBT we keep the connection open even if the page is not visible, provide UI indicators to keep the user informed
09:49:26 <anssik> ... unlike sensors, when you're connected to a device, there's an expectation there's shared state you do not want to interfere with
09:49:54 <anssik> ... a bi-direction connection is different from delivering events one-way
09:51:21 <anssik> anssik: what are the other features exposed to dedicated workers?
09:52:06 <anssik> Reilly: IndexedDB, Fetch, XHR at least
09:53:11 <anssik> ... within the limited scope of dedicated workers, as long as we can spec how that feature interacts with events in a frame, no known concern how that's done
09:53:27 <anssik> anssik: this could be polyfilled, but that'd have worse performance
09:54:29 <reillyg> RESOLUTION: Start work to expose sensor APIs to dedicated workers as they track an active frame and so there are no additional permissions questions.
09:57:26 <anssik> Reilly: there's three categories for background work: 1) receiving the sensor events in the background, e.g. GPS logging app in realtime or batched 2) summarized view that  is not available real-time, but can be queried e.g. fitness tracker 3) geofencing in which you set a trigger condition
10:03:39 <iclelland> iclelland has joined #dap
10:06:31 <anssik> Reilly: two different use cases: e.g. active tracking for navigation and one for geofencing
10:06:59 <anssik> Tom: advise from Jake, long running tasks not applicable for service worker
10:08:42 <anssik> Tom: you'd need to use system wake lock https://w3c.github.io/wake-lock/#dfn-system-wake-lock to keep the app running
10:09:30 <anssik> -> https://w3c.github.io/wake-lock/#wake-locks "Screen wake lock" and "System wake lock"
10:12:38 <anssik> Reilly: for geofencing we have a path to follow for Service Workers
10:22:27 <anssik> -> https://w3c.github.io/geofencing-api/ (obsoleted) Geofencing API
10:22:40 <tomayac_> tomayac_ has joined #dap
10:22:50 <tomayac_> The paper I keep referring to: https://t.co/OxiuEg8uVL
10:24:23 <anssik> -> https://gist.github.com/mkruisselbrink/70c95b3068e1bbe9b668 Background sensor use cases
10:25:47 <anssik> anssik: suggest we talk to Marijn to learn from the past
10:32:36 <anssik> larsgk: how about combination of multiple events as a trigger?
10:36:15 <anssik> Reilly: agreement?
10:36:18 <anssik> [silence]
10:36:24 <anssik> RESOLUTION: Investigate further Geolocation and Wake Lock integration to allow active sensor tracking
10:36:32 <anssik> ACTION: Reilly to talk to Marijn to understand why Geofencing API work was abandoned
10:36:32 <trackbot> Created ACTION-814 - Talk to marijn to understand why geofencing api work was abandoned [on Reilly Grant - due 2018-10-30].
10:36:40 <anssik> ACTION: Tom to talk Geofencing at the Service Workers WG F2F, seek that group's feedback
10:36:40 <trackbot> Error finding 'Tom'. You can review and register nicknames at <https://www.w3.org/2009/dap/track/users>.
10:37:16 <anssik> TOPIC: Sensor discovery
10:38:19 <larsgk> https://github.com/larsgk/imo/blob/master/GenericSensorDiscovery.md
10:39:04 <anssik> larsgk:  has been working with sensors and actuators for a number of years
10:39:29 <anssik> ... recently working with different companies helping them move from native stacks to the web, in medical and industrial space
10:39:54 <anssik> ... sensor discovery an issue, would be nice to have a system to add and remove sensors from the generic sensor context
10:40:53 <anssik> ... few cases: most mobile phones have sensors of varying quality, so you could detect and use sensors around you via Generic Sensor API, do sensor fusion
10:41:50 <anssik> ... vehicle monitoring, how to interact with sensors in cars, monitor the health of your car, integrate with weather services, optimize UX of connecting to external sensors
10:42:24 <anssik> ... able to interact with sensors e.g. in a supermarket dynamically
10:43:42 <anssik> [discovery use cases described in https://github.com/larsgk/imo/blob/master/GenericSensorDiscovery.md#sensor-discovery]
10:44:24 <tomayac> Regarding my AI: https://github.com/w3c/ServiceWorker/issues/1303
10:44:54 <tomayac> Sorry, deep link got eaten: https://github.com/w3c/ServiceWorker/issues/1303#issuecomment-432195867
10:49:59 <iclelland> iclelland has joined #dap
10:50:44 <iclelland> iclelland has joined #dap
10:51:22 <anssik> tapping NFC tag would be considered an implicit trust signal https://w3c.github.io/permissions/#implicit-signals
10:55:53 <anssik> Reilly: unlikely browsers implement industrial sensor specific features, those requirements can be addressed with WebUSB and WebBT
10:59:25 <anssik> ... would be good to see whether we can get someone build a polyfill on top of WebBT
11:22:29 <Zakim> Zakim has left #dap
11:28:50 <iclelland> iclelland has joined #dap
11:35:18 <xfq> xfq has joined #dap
11:40:12 <xfq_> xfq_ has joined #dap
11:42:49 <wanming1> wanming1 has left #dap
11:42:52 <wanming1> wanming1 has joined #dap
11:43:34 <iclelland> iclelland has joined #dap
11:49:28 <iclellan1> iclellan1 has joined #dap
11:55:31 <takio> takio has joined #dap
11:57:15 <xfq_> xfq_ has joined #dap
11:58:51 <johnpallett> johnpallett has joined #dap
12:03:05 <larsgk> larsgk has joined #dap
12:03:22 <wanming> anyone on the webex?
12:03:42 <rakuco> not yet, I think
12:04:00 <wanming> isn't the meeting started at 2pm?
12:04:08 <rakuco> we need to finish discussing some items from the previous session, and anssik's returning from lunch
12:04:23 <wanming> got, thanks!
12:04:47 <rakuco> let me know if it gets too late for you though
12:05:05 <wanming> it doesn't matter :)
12:10:38 <rakuco> wanming: can you hear us right now?
12:10:49 <wanming> no
12:10:54 <wanming> no one in the webex
12:11:10 <wanming> have you called the webex?
12:12:45 <rakuco> anssik will try to set up the bridge
12:13:09 <wanming> thanks
12:13:37 <wanming> seem it needs the host joined in, @xfq_
12:13:55 <xfq_> ok, joining
12:15:57 <wanming> i see you on the webex, but still hearing nothing..
12:17:32 <wanming> can anyone hear me
12:20:16 <anssik> TOPIC:  WebDriver Extension API for Generic Sensor
12:20:17 <foolip> foolip has joined #dap
12:21:56 <xfq> xfq has joined #dap
12:23:19 <wanming> Present+ Wanming_Lin
12:23:44 <anssik> Present+ foolip
12:24:01 <anssik> foolip: come bug me for anything related
12:24:24 <anssik> [we're fixing the webex bridge bear with us]
12:26:10 <anssik> raphael: worked on multiple Chromium and Blink parts, and sensors, Wanming is part of the QA team
12:27:06 <anssik> ... problem is a generic one, testing hardware capabilities without actual sensors impossible in an automated fashion currently
12:27:58 <anssik> ... the problem generalized across other features that interface with hardware
12:28:10 <anssik> ... target to be able to test across multiple browsers
12:28:18 <wanming> a bit noise
12:28:43 <wanming> and the volume is a bit low
12:29:21 <anssik> [showing slides]
12:33:54 <iclelland> iclelland has joined #dap
12:37:51 <Zakim> Zakim has joined #dap
12:39:13 <anssik> RRSAgent, draft minutes v2
12:39:13 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/23-dap-minutes.html anssik
12:40:01 <anssik> Present+ Wanming_Lin(Remote)
12:44:31 <anssik> -> https://rawgit.com/Honry/sensors/webdriver-extension/webdriver-extension/ WebDriver Extension API for Generic Sensor PR preview
12:50:42 <anssik> [presentation finished, slides to be shared shortly]
12:50:56 <anssik> raphael: any questions, comments?
12:50:56 <anssik> foolip: this is perfect for what you want to test, WebDriver is unidirectional protocol so works in this case
12:51:25 <anssik> ... worth looking at mocking geolocation, how the API would look like
12:53:43 <anssik> Reilly: a number of questions, WebUSB needs a bi-dir connection that's not currently supported
12:54:50 <anssik> the Chrome-specific protocol is bi-directional
12:55:05 <anssik> s/the Chrome-specific protocol is bi-directional/... the Chrome-specific protocol is bi-directional/
12:55:16 <anssik> ... another issue around permissions: no permission support in WebDriver
12:55:30 <anssik> ... we wrote the API for that, someone just needs to implement it
12:55:50 <anssik> s/... we wrote the API for that, someone just needs to implement it/foolip: we wrote the API for that, someone just needs to implement it/
13:01:07 <anssik> ACTION: foolip to connect Raphael and Wanming with ChromeDriver maintainers
13:01:07 <trackbot> Error finding 'foolip'. You can review and register nicknames at <https://www.w3.org/2009/dap/track/users>.
13:08:07 <iclelland> iclelland has joined #dap
13:08:57 <wanming> wanming.lin@intel.com
13:10:20 <anssik> Present+ Alexis_Menard
13:12:29 <wanming> https://docs.google.com/presentation/d/1Kvl0fFFApaEwlp0Cd9yVneHMlvCWAdGo0ArNlgOkeLE/edit#slide=id.g448575a9a1_4_0
13:12:49 <wanming> people outside intel, need permission access :(
13:13:22 <anssik> -> https://docs.google.com/presentation/d/1Kvl0fFFApaEwlp0Cd9yVneHMlvCWAdGo0ArNlgOkeLE/ WebDriver Extension API for Generic Sensors presentation slides
13:13:44 <anssik> RRSAgent, draft minutes v2
13:13:44 <RRSAgent> I have made the request to generate https://www.w3.org/2018/10/23-dap-minutes.html anssik
13:17:09 <wanming> wanming has left #dap
13:20:37 <xfq> xfq has joined #dap
13:22:11 <takio> takio has joined #dap
13:24:46 <yang_gy> yang_gy has joined #dap
13:24:54 <yang_gu> yang_gu has joined #dap
13:25:38 <xfq> xfq has joined #dap
13:29:27 <ada> ada has joined #dap
13:30:42 <youenn> youenn has joined #dap
13:42:24 <iclelland> iclelland has joined #dap
13:55:14 <anssik> TOPIC: High frequency & batching
13:55:57 <anssik> Reilly: initially we attempted to sync with rAF loop, but Chromium implementation was pulled since there was not a very good model
13:57:02 <anssik> ... for example, 120 Hz frequency, batching two readings per rAF loop running at 60 Hz required
13:57:27 <anssik> ... initial thoughts align with whatever input stack (keyboards and such) is doing
14:00:50 <anssik> ... primary issue around sensor timing is Provide a way of tying sensor requests to animation frames #4
14:02:36 <anssik> anssik: what are the most valuable use cases for high frequency (>60 Hz)?
14:02:50 <anssik> Reilly: gaming, VR/XR
14:04:40 <anssik> ... if we want to provide higher frequency input, we could gate this into e.g. XR context
14:06:05 <mfoltzgoogle> mfoltzgoogle has joined #dap
14:06:19 <johnpallett> johnpallett has joined #dap
14:06:19 <mfoltzgoogle> Pointer Events level 2 Extensions: https://w3c.github.io/pointerevents/extension.html#dom-pointerevent-getcoalescedevents
14:06:37 <zolkis> zolkis has joined #dap
14:10:32 <anssik> Flaki: SLAM, motion capture might be use cases for high frequency
14:14:38 <anssik> John: camera and sensor alignment for AR benefits from high frequency sampling
14:14:56 <anssik> [brainstorming use cases for high frequency]
14:16:59 <johnpallett> I can take an AI to follow up with people using capture to see whether alignment with sensor data would help for AR use cases
14:17:15 <anssik> ACTION: John to follow up with people using capture to see whether alignment with sensor data would help for AR use cases
14:17:15 <trackbot> Error finding 'John'. You can review and register nicknames at <https://www.w3.org/2009/dap/track/users>.
14:18:54 <anssik> -> https://w3c.github.io/deviceorientation/ DeviceOrientation Event Specification
14:19:41 <anssik> TOPIC: DeviceOrientation Event Specification
14:20:28 <anssik> [reviewing open PRs]
14:20:36 <anssik> -> https://github.com/w3c/deviceorientation/pulls Open PRs
14:22:58 <anssik> -> https://github.com/w3c/deviceorientation/pull/10 Add screen-adjusted device orientation attributes to DeviceOrientationEvent interface
14:24:24 <anssik> [silence]
14:24:25 <anssik> RESOLUTION: Close the issue
14:24:35 <anssik> s/RESOLUTION: Close the issue/RESOLUTION: Close the issue #10/
14:24:55 <anssik> -> https://github.com/w3c/deviceorientation/pull/12 Add deviceorientation and devicemotion feature detection conformance requirement #12
14:25:51 <anssik> [no objections]
14:27:20 <anssik> -> https://github.com/w3c/deviceorientation/pull/34 Add the ondeviceorientationabsolute event handler attribute #34
14:27:56 <anssik> Reilly: Chrome usage below 0.0007%, given this extremely low consider deprecating this in Chrome
14:29:38 <anssik> ... the question to the group is, if Chrome decides not to deprecate ondeviceorientationabsolute, should we merge the PR #34?
14:31:31 <anssik> [agreement]
14:31:38 <anssik> RESOLUTION: If Chrome keeps this event then this PR should be modified to add a non-normative note about the additional event available in some user agents. If Chrome deprecates then this can be closed without merging.
14:31:58 <anssik> -> https://github.com/w3c/deviceorientation/pull/43 update rotationRate alpha, beta, gamma description to be the same as implementation #43
14:32:17 <anssik> Reilly: propose we merge this PR, since the spec should reflect the (sometimes messy) reality of implementations
14:34:03 <anssik> This aligns with per https://www.w3.org/TR/html-design-principles/#priority-of-constituencies
14:35:07 <anssik> -> https://github.com/w3c/deviceorientation/pull/49 Make security and privacy normative #49
14:36:26 <anssik> [no concerns]
14:36:55 <anssik> -> https://github.com/w3c/deviceorientation/pull/55 Remove '?' from dictionary members of DeviceMotionEventInit #55
14:38:16 <anssik> Reilly: the diff between the implementation behavior will not surface in real-world use, unlikely to break existing content
14:39:18 <anssik> [no concerns]
14:39:58 <anssik> ACTION: Reilly to discuss with Chrome API owners whether to deprecate ondeviceorientationabsolute event
14:39:58 <trackbot> Created ACTION-815 - Discuss with chrome api owners whether to deprecate ondeviceorientationabsolute event [on Reilly Grant - due 2018-10-30].
14:40:27 <anssik> ACTION: Anssi to take an action to rebase #49
14:40:28 <trackbot> Created ACTION-816 - Take an action to rebase #49 [on Anssi Kostiainen - due 2018-10-30].
14:42:13 <anssik> kenneth: could we add a note redirecting readers to the actively being worked on spec
14:43:10 <anssik> ACTION: Anssi to add a note to DeviceOrientationEvent that "Implementors need to be aware that the future work is now happening on the Generic Sensor-based specifications"
14:43:11 <trackbot> Created ACTION-817 - Add a note to deviceorientationevent that "implementors need to be aware that the future work is now happening on the generic sensor-based specifications" [on Anssi Kostiainen - due 2018-10-30].
14:44:40 <anssik> MarkF: is the Generic Sensor work a superset of DeviceOrientationEvent
14:45:37 <anssik> Reilly: yes, there's also a polyfill that implements a subset of Generic Sensor atop DeviceOrientationEvent https://github.com/kenchris/sensor-polyfills
14:46:08 <anssik> MarkF: can we polyfill DeviceOrientationEvent on top of Generic Sensors
14:46:15 <anssik> Reilly: yes