01:52:29 RRSAgent has joined #dap 01:52:29 logging to http://www.w3.org/2015/10/28-dap-irc 01:52:50 RRSAgent, make logs public 01:52:56 Meeting: Generic Sensor API TPAC 2015 breakout 01:52:57 Chair: Tobie Langel 01:53:04 Present+ Anssi_Kostiainen 01:53:07 Tobie: Hi. Editor of the Generic Sensor API spec, for Intel. 01:53:07 Topic: Generic Sensor API 01:53:14 Tobie: Lots of sensors being used nowadays. 01:53:14 ... In mobile devices, now IoT. Lot of different sensors to expose. Goal of the project is to have a common base to expose sensors to developers. 01:53:14 ... Sensor spec are often highly underspecified, which leads to interoperability issues. 01:53:15 ... Also, exposing new sensors to the Web should not mean having to re-think the problem space again and again. Topics such as privacy and security should be common to all. 01:53:17 ... These are the reasons why we're doing that. 01:53:17 ... The spec itself does not specify any concrete interface. 01:53:22 ... I'm looking at already published APIs to instantiate the spec. Also looked at other APIs such as the Automotive ones. 01:53:22 ... Two main kinds of interaction with sensors: 01:53:28 ... 1. continuous monitoring 01:53:28 ... 2. change based on a threshold. 01:53:28 [showing example 3 from spec] 01:53:32 Tobie: The example shows the two use cases. 01:53:37 ... Third case would be device orientation where you want to continuously know how the device is in space. One of the things that is missing from existing sensor specifications is better integration with hardware in terms of latency: low-level vs. high-level. The low-level concept is pretty useful in some use cases. 01:53:37 Louay: Support for multiple sensors of the same type? 01:53:42 Tobie: Totally. I forgot to mention that. 01:53:42 Louay: Can the browser do some discovery? 01:53:47 Tobie: Discovery is a very interesting problem. It very much depends on what kind of sensors you have. GPS chips would be local to the device, but as soon as you move to vehicles or WoT or Bluetooth networks, that's tough. 01:53:47 ... Discovery is not in this version of the spec. We decided to tackle this in a future revision of the spec. 01:53:52 ... There are on-going works such as the Bluetooth API. 01:53:52 Anssi: The spec provides an extension point. 01:53:52 Louay: The WoT IG discusses this, with the Thing API for instance. I have demos around that, come to the hall to see it. 01:53:57 ahaller: One of our works will be the Semantic Sensor ontology. 01:54:02 ... How will you what type of sensor you will be dealing with? 01:54:02 Anssi: It's about feature detection 01:54:06 Tobie: I have a section about that, but it's really about local sensors. 01:54:49 s/you what/you know what 01:55:34 Hyunjin has joined #dap 01:55:53 oonishi has joined #dap 01:55:54 Tobie: There will be some information, not written in the spec. I want to make sure that concrete specs can extend that easily. I'm very much looking at the Generic Sensor API as a low-level building block that you can build on top of. 01:55:55 Nick_Doty: Thinking about privacy issues. Discovering sensors individually is useful but I'm curious how we're going to do that for generic sensors. 01:55:55 Tobie: A lot of sensors have privacy problems. Many of them are common to most of them. 01:55:55 ... So it seems useful to tackle these common problems in the spec 01:56:20 anssik has changed the topic to: Generic Sensor API breakout session https://www.w3.org/wiki/TPAC/2015/SessionIdeas#Generic_Sensor_API 01:56:23 ... All of the boilerplate privacy/security concerns would be in the spec, while specific ones will be defined in concrete specs. 01:56:57 i/Chair: Tobie Lange/scribe: tidoust/ 01:57:24 Tobie: Things such as naming sensors, exposing high-level or low-level sensors. 01:57:56 ... When I started looking into it, I noticed that people kind of copy-pasted bits from other specs. I'm trying to rationalize this approach. 01:58:23 Kenneth: What is the timeline? 01:58:56 Riju: On the Chromium side, I'll start implementing next week. End of this year, I will release Ambient Light implementation. 01:59:13 Tobie: Right, that spec will be written on top of the Generic Sensor API. 01:59:29 Nick_Doty: other browser vendors interest? 01:59:38 Anssi: work started based on Mozilla feedback. 02:00:03 ... We want to fix issues that arised in first device APIs now. 02:00:34 ... I cannot speak on behalf of other browser vendors. Microsoft has it on its roadmap. 02:00:51 ... So there's some commitment. Apple is the only missing block here, I think. 02:01:08 kto has joined #dap 02:01:38 Shijun_Sun: I'm from Microsoft. Do you think there will be some impact from the Device APIs WG to other working groups? 02:02:04 Tobie: Yes, I can't speak for other groups but that's the goal. 02:02:14 ... Geolocation would be a good candidate. 02:02:22 npdoty has joined #dap 02:02:34 Shijun_Sun: It would be good to bring the topic for Media Capture, joint work between DAP and WebRTC. 02:02:49 Geolocation discussed device orientation this week 02:03:05 ... We've been looking at device rotations, tied to the camera 02:03:09 So I'm not sure we are all on the same page about where that api is going 02:03:52 Tobie: If you have use cases for exposing that to developers, it would make a lot of sense to use the same API. Naming might be used to split ambient light sensors that are not linked to the camera from those that are in the device for instance. 02:04:25 please feel free to open issues for topics raised at this session at https://github.com/w3c/sensors/issues 02:04:35 ... You certainly don't think of getUserMedia in terms of a sensor thing, but the rest fits well, I think 02:04:52 Anssi: Please open an issue on the GitHub repo, people! 02:06:18 jyasskin: Do you have a polyfill? 02:06:36 Tobie: Yes, we played with a few specs, including the Geolocation API. 02:07:08 Whoa, are we going to hang off of window rather than navigator? 02:07:13 ... There are polyfills. I should have a working demo, but broke it on my way here, sorry about that. 02:07:42 ... I don't think we're going to be able to polyfill device orientation in a way that solves performance issues, obviously! 02:08:03 ... I think I have a polyfill for the Battery API. 02:08:22 I think there is interest in an absoluteorientationevent in DeviceOrientation that might fit that use case 02:08:38 currently supported by Safari and interest from Chrome 02:08:39 Dave_Raggett: Wondering about the relation with the Streams API 02:08:53 ... Electrocardiogram would be an example of streaming sensor. 02:09:19 npdoty: IDL interfaces produce a window.InterfaceName. One can suppress that, but not reparent it. 02:09:36 Tobie: If you look at async primitive space, you have Promises for one-off events, then you have Observable for a bunch of events. The sensor space we're dealing with sits somewhere in the middle. 02:10:07 ... I think it would be a mistake to not make the distinction between streams and discrete events. Our mental model is different. 02:10:21 ryuichi has joined #dap 02:10:42 Dave_Raggett: heartbeat is just an example. You could have regular different measurements and other things. 02:10:45 jyasskin: that doesn't mean it has to be window.sensors as opposed to navigator.sensors (but yeah, all the types would still pollute global scope) 02:11:06 Tobie: Two main kinds of sensors: precise interval measurement, and those where you're really interested in the notion of change. 02:11:06 Mek: Yep. I think Tobie said he's dropped the foo.sensors namespace entirely. 02:11:51 ... Most sensors pull the data out, and then pretend to push it when a threshold is met. 02:12:23 Tobie: Heartbeat example is interesting because it's a high-level sensor that could be built on top of lower-level sensors. 02:12:35 ... The data you get out is a computation of other types of sensor data. 02:13:39 Mick: Confused about high-level / low-level 02:14:19 Claes has joined #dap 02:14:25 Tobie: For the purpose of the spec, those that are tied to an implementation, we call them low-levels. 02:14:38 Dave_Raggett: There are different families of sensors in terms of patterns. 02:14:49 s/Mick/Mikko_Terho/ 02:15:26 ... In the IoT space, lots of people think in terms of reading a value. Not really thinking in terms of streams. There is perhaps a taxonomy of different sensor types independent of the specification 02:15:32 s/specification/implementation. 02:15:37 For Geolocation, we consider it a feature, rather than a bug, of having a datatype agnostic to the particular mechanism to determine it 02:16:32 Is it useful to define a lot of low level sensors if we don't expect them to be used or for users to understand them? 02:16:45 Mick: For high-level sensors, you'll get a callback, basically. At the low level, you do the monitoring. My recommendation is that the high-level API output chould be changes. 02:17:17 ... Then if you want to monitor a complete stream, you need to change the model. 02:17:46 s/Mick:/Mikko_Terho:/g 02:18:14 Jiru: we're not considering cameras as sensors per se. 02:18:33 Dave_Raggett: Then there's some sort of assumption of what sensor types are. 02:18:36 q+ 02:18:39 ... Have you considered the notion of timestamp? 02:18:43 akeranen has joined #dap 02:19:16 Tobie: Every reading is timestamped with a high-res timestamp. 02:19:26 ... Based on the local clock. 02:20:19 Claes: Have you considered to use the Streams API in the end, for a future version perhaps? 02:20:41 Tobie: If you need a stream, I think you do not need something like the Sensor API. 02:20:58 ... I'm thinking about 1Khz sensors, roughly. 02:21:07 s/Jiru:/Riju:/g 02:21:47 Claes: The Streams API is a good starting point. Lots of functionality from it could be reused. I think it should be considered. 02:22:04 Dave_Raggett: Maybe the assumptions should be made explicit at the beginning of the spec. 02:22:24 Tobie: OK, I'm happy to look into it, e.g. for the device orientation API. 02:22:27 jystewart has joined #dap 02:22:38 Anssi: I think Claes is looking at it from the perspective of raw sockets. 02:22:50 Tobie: Could you put an issue on the GitHub? 02:22:54 Claes: Yes. 02:23:16 Adam_Alfar: [missed comment] 02:24:36 Mikko_Terho: Also need a way to agree on what constitutes a change betwee browser and sensor 02:24:49 Tobie: Links back to discussion on threshold we had yesterday. 02:25:19 Mikko_Terho: It goes beyond that. I might be only be interested in 5 degree changes in temperature for instance. 02:25:36 Tobie: Right, the API addresses some use cases but not all of them. 02:25:51 Mikko_Terho: I would differentiate these 2 cases 02:26:04 Yeah, there seems like an efficiency and privacy/minimization advantage to letting the site request the level of detail it needs 02:26:29 Riju: This API gives something to developers that is not exposed by other concrete APIs: the ability to set the frequency with which you get readings. 02:27:07 Dave_Raggett: Continuously-changing variables can be approximated with discrete values. Have you discussed this? 02:27:18 Tobie: No. 02:27:24 Anssi: I think we don't have concrete sensor products in mind for this. 02:27:45 Dave_Raggett: You could measure a sound, for instance. 02:27:55 Tobie: That's where I would say that this out of scope. 02:28:02 ... Would you be willing to open an issue? 02:28:12 please feel free to open issues for topics raised at this session at https://github.com/w3c/sensors/issues 02:28:14 Dave_Raggett: Yes. 02:29:20 Present+ Claes_Nilsson 02:29:36 [some discussion on the topic] 02:29:55 Dave for scope, also look at https://github.com/w3c/sensors/issues/1 and comment there 02:30:20 q+ Virginie 02:30:40 q? 02:30:41 Shinju_Sun: Do you think it would be useful to give developers the accuracy of the measurement? For some sensors, the accuracy may depend on the value, fluctuating. 02:30:49 Tobie: Yes, accuracy is in. 02:30:59 ... specific to each measurement. 02:31:09 ... already in the draft. 02:31:39 Shinju_Sun: I noticed you're using Promise already. And also talk about low latency. What do you consider low latency? 02:31:54 dka has joined #dap 02:32:03 q+ on setting area/level of interest in frequency, difference or shape 02:32:06 Tobie: The API is EventTarget so you're listening to callbacks. Promises are used as a convenience method for one-off readings. 02:32:23 Zakim has joined #dap 02:32:33 q+ Virginie 02:32:38 q+ 02:32:41 ... One of the things I want to do for performance is to see how this can be tied to requestAnimationFrame 02:33:09 ... The most critical requirements I've seen are linked to virtual reality, not to throw up ;) 02:33:55 ... If it's combined with animation frame rates and WebGL, it should be doable to have the right latency. 02:34:08 q+ dka 02:34:46 ... I'm trying to figure out how to do that in the spec. I don't even know if it's doable from an implementation perspective. 02:34:49 ack Vi 02:34:55 q? 02:35:19 Virginie_Galindo: I'm from Gemalto. There are some concerns about sensor data connections. 02:35:44 ... There were some new models starting to be discussed: you may want to read data from sensors without anyone listening to that. 02:35:56 ... Have you thought about transferring sensor data in a cyphered way? 02:36:04 ... Has it been discussed? 02:36:15 DKA: That's what I was going to ask. 02:36:29 ack dka 02:36:52 Tobie: I'm not sure I understand the question properly. 02:37:33 Virginie_Galindo: The question is about indicating whether the reading was transfered securely. 02:37:41 oonishi has joined #dap 02:38:00 ... You need to have secret keys. You may want to convey data that is conveyed in clear and data that is not in clear. 02:38:14 Tobie: Would that be available to the Web application? 02:38:29 Virginie_Galindo: I'm really thinking about the future. Please think about that. 02:38:50 Anssi: I think we ran the spec to the security group for review already. 02:39:03 Tobie: I want to understand the use cases more precisely. 02:39:23 Nick_Doty: you want encrypted values coming from the sensors that the browser would not be able to decrypt? 02:40:45 Virginie_Galindo: [@@2 use cases] 02:41:07 Kenneth: you may want to send the data without reading it to a server. 02:41:23 Tobie: A kind of opaque reading is what you need. 02:42:07 DKA: Related to permissions and fingerprinting and stuff like that. Regarding permissions, in the Powerful features spec, it talks about knowledge of external devices as being a powerful feature. 02:42:18 Francois: I think that's already in the spec 02:42:18 Tobie: Yes. 02:42:39 ... Permission is an implementation detail. You just scope that out in the spec. 02:42:48 DKA: The spec needs to be clear about that though. 02:43:12 Tobie: Right, the spec will have a section that is larger than the title it has right now. 02:43:43 ... There is HTTPS concerns, so it's pulled that as a requirement in that spec. 02:43:55 DKA: I would also encourage you to take a look at fingerprinting. 02:44:17 Tobie: I started to read that on my way here. Great stuff (altough this broke my laptop). 02:44:46 ahaller2: Fingerprinting may be already a lost case. 02:44:59 DKA: Discussed on the TAG. 02:45:40 Unsanctioned tracking: http://www.w3.org/2001/tag/doc/unsanctioned-tracking/ 02:46:07 Dave_Raggett: Detecting when a Web site looks suspicious. Can this be detected? Could the spec say something about that? Third-party apps could perhaps monitor sensors somehow. 02:46:27 Nick_Doty: Researchers have done that in a way that instruments the browser. 02:46:38 Tobie: You really want to handle that somewhere else. 02:46:47 Dave_Raggett: Yes but that could be called out in a Privacy section. 02:47:03 q+ 02:47:24 Johannes: Can the value be opaque to this API? Does the API really have to understand what it's dealing with? 02:47:41 Tobie: Does the operating system or user agent need to understand the value? 02:47:48 ... This is the usual security vs. performance issue question. 02:49:09 I think there is a privacy advantage to the fusion approach as well, potentially 02:49:16 ... You can build a pedometer using data from a gyroscope. You have to read it at something like 60Hz. You're draining the battery. Now if you let the underlying system do that, it may be able to do sensor fusion and expose a pedometer, thus improving performance and saving battery. 02:49:35 ... The more you move to the sensor, the better the results in terms of performance. 02:50:29 ... I don't really have good use cases in mind for opaque readings. For the use cases that we've looked at that are around non-opaque readings, it's better to move closer to the sensor. 02:51:00 Louay: About connectivity issues with remote sensors. Do we need a feature in the Generic Sensor API? 02:51:45 Tobie: Yes, probably some error events. Part of handling the error could be to create a new sensor again to talk to the sensor again. I don't expect the sensor to survive disconnection issues for the time being. 02:52:00 [breakout session adjourned] 02:52:13 RRSAgent, draft minutes 02:52:13 I have made the request to generate http://www.w3.org/2015/10/28-dap-minutes.html tidoust 02:54:15 s/[@@2 use cases]/One use case is that of a sensor provides cyphered values, not readable by the Web app (for privacy reason). Second use case is aggregation several data readings by the Web app and encryption by the Web app afterwards./ 02:54:21 RRSAgent, draft minutes 02:54:21 I have made the request to generate http://www.w3.org/2015/10/28-dap-minutes.html tidoust 03:03:32 tidoust2 has joined #dap 03:21:22 kotakagi has joined #dap 03:37:06 stakagi has joined #dap 03:44:02 hellojintae has joined #dap 04:06:44 mfoltzgoogle has joined #dap 04:15:42 tidoust2 has joined #dap 04:28:43 stakagi has joined #dap 04:30:06 jyasskin has joined #dap 04:30:25 oonishi has joined #dap 04:32:02 jyasskin has left #dap 04:34:11 oonishi has left #dap 04:37:01 ahaller2 has joined #dap 04:38:18 dka has joined #dap 04:38:24 dom has joined #dap 04:39:11 hellojin_ has joined #dap 04:39:16 ahaller2 has left #dap 04:44:15 youenn has joined #dap 04:52:39 mfoltzgoogle has joined #dap 04:52:54 Zakim has left #dap 04:58:00 ccho4 has joined #dap 05:08:54 ccho4 has joined #dap 05:30:59 jystewart has joined #dap 05:40:45 mfoltzgoogle has joined #dap 05:41:24 jystewart has joined #dap 05:43:07 hellojintae has joined #dap 05:43:22 dka has joined #dap 05:45:41 tidoust has joined #dap 05:46:44 jystewart has joined #dap 05:51:51 dom has joined #dap 05:52:30 jystewart has left #dap 05:52:36 stakagi has joined #dap 05:55:08 dom has joined #dap 06:03:30 mfoltzgoogle has joined #dap 06:09:24 hellojin_ has joined #dap 06:44:59 stakagi has joined #dap 07:04:13 mfoltzgoogle has joined #dap 07:05:40 tidoust has joined #dap 07:05:48 dom has joined #dap 07:11:31 jystewart has joined #dap 07:28:36 jystewart has joined #dap 07:46:51 stakagi has joined #dap 08:11:16 stakagi has joined #dap 08:14:32 jystewart has joined #dap 08:59:28 mfoltzgoogle has joined #dap 09:11:16 jystewart has joined #dap 09:13:07 jystewart has left #dap 09:19:54 stakagi has joined #dap 10:36:50 kotakagi_ has joined #dap 11:21:56 mats has joined #dap 13:11:37 hellojintae has joined #dap 13:15:16 hellojintae has joined #dap 13:23:51 mfoltzgoogle has joined #dap 14:07:23 tidoust has joined #dap 14:55:15 tidoust has joined #dap 18:38:46 youenn has joined #dap 20:11:17 mats has joined #dap 22:10:45 stakagi has joined #dap 22:39:26 stakagi_ has joined #dap 23:27:15 anssik has joined #dap 23:51:48 dom has joined #dap 23:56:27 hellojintae has joined #dap 23:59:25 stakagi has joined #dap