05:47:42 RRSAgent has joined #web-bluetooth 05:47:42 logging to http://www.w3.org/2015/10/26-web-bluetooth-irc 05:48:46 rrsagent, make logs public 05:49:04 rrsagent, bookmark 05:49:04 See http://www.w3.org/2015/10/26-web-bluetooth-irc#T05-49-04 05:49:30 rrsagent, generate minutes 05:49:30 I have made the request to generate http://www.w3.org/2015/10/26-web-bluetooth-minutes.html anssik 05:50:12 rrsagent, make minutes public 05:50:12 I'm logging. I don't understand 'make minutes public', anssik. Try /msg RRSAgent help 05:50:21 rrsagent, make logs public 05:51:11 Meeting: Web Bluetooth and Web NFC 05:51:20 rrsagent, generate minutes 05:51:20 I have made the request to generate http://www.w3.org/2015/10/26-web-bluetooth-minutes.html anssik 05:51:51 Present+ Kenneth_Christiansen 05:52:03 Agenda: https://www.w3.org/wiki/TPAC/2015/ad-hoc-meetings#Web_Bluetooth_and_Web_NFC 05:53:16 rrsagent, generate minutes 05:53:16 I have made the request to generate http://www.w3.org/2015/10/26-web-bluetooth-minutes.html anssik 05:58:09 aalfar has joined #web-bluetooth 05:58:14 timeless has joined #web-bluetooth 05:58:28 riju has joined #Web-bluetooth 05:58:50 RRSAgent, draft minutes 05:58:50 I have made the request to generate http://www.w3.org/2015/10/26-web-bluetooth-minutes.html timeless 05:59:08 chair: jyasskin 05:59:10 riju has joined #web-bluetooth 05:59:43 jyasskin has changed the topic to: Web NFC and Web Bluetooth discussion 05:59:50 topic: Web Bluetooth 06:00:02 RRSAgent, draft minutes 06:00:02 I have made the request to generate http://www.w3.org/2015/10/26-web-bluetooth-minutes.html timeless 06:00:24 present+ timeless, jyasskin, anssik, dom, kenneth_ 06:00:33 Some links: https://www.youtube.com/watch?v=tRMcMDIyIGQ, https://googlechrome.github.io/samples/web-bluetooth/, https://play.google.com/store/apps/details?id=io.github.webbluetoothcg.bletestperipheral 06:00:35 present+ aalfar 06:00:43 present+ riju 06:01:31 present+ jonathanj 06:02:43 brsun has joined #web-bluetooth 06:02:46 jocelyn has joined #web-bluetooth 06:02:51 present+ jungkee 06:02:57 present+ jocelyn 06:04:25 jungkees has joined #web-bluetooth 06:04:31 JonathanJ has joined #web-bluetooth 06:05:23 tomoyuki has joined #web-bluetooth 06:05:29 i|Some links|-> https://www.youtube.com/watch?v=tRMcMDIyIGQ Web Bluetooth API: Grumpy goes flying| 06:05:53 i|Some links|-> https://googlechrome.github.io/samples/web-bluetooth/ Web Bluetooth Samples 06:06:00 mfoltzgoogle has joined #web-bluetooth 06:06:13 jyasskin: for Bluetooth, I wanted to talk about the spec and show what we have in Google Android 06:06:22 ... get everything aired, make sure everyone is on the same page 06:06:34 [ Spec ] 06:06:44 jyasskin: it goes through the security issues, 06:06:59 ... talks about how you can access and discover devices 06:07:10 [ Security ] 06:07:26 jyasskin: first question that everyone should ask when we offer to give Web Sites access to devices is "how to make that safe" 06:07:38 ... the first thing is to give the user a chooser to let users choose what devices to have access to 06:07:47 ... gets user attention, and gives much more limited scope 06:07:55 ... we also only allow this API for https: content 06:08:01 [ Attacks ] 06:08:10 jyasskin: we worry about web pages getting access to sensitive data 06:08:17 jyasskin: we worry about web pages attacking sensitive devices 06:08:26 ... we only allow access to the GATT protocol 06:08:43 dom has joined #web-bluetooth 06:08:49 q+ 06:08:54 ... Bluetooth is divided into Classic (2.1/3) and LE (4+) 06:09:00 present+ mfoltzgoogle 06:09:39 ... there's a new protocol for LE called GATT: Generic Attribute Profile 06:09:53 ... we in Chrome only initially support BT LE (4+) 06:10:36 dom: so there is nothing in the spec that prevents it to work on classic bluetooth as long as it's on top of GATT 06:10:43 https://webbluetoothcg.github.io/web-bluetooth/#gatt-interaction 06:11:08 jyasskin: if people want me to cover GATT, I can do that now 06:11:22 ... the reason GATT expands to GATT is it's Generic + ATTribute 06:11:39 ... GATT defines a hierarchy of Services, Characteristics, Descriptors 06:11:44 ... each device has a list of Services 06:11:57 ... any semantic thing will be a service 06:12:11 ... I don't think any devices have "included services" 06:12:20 ... a characteristic has a bytestream value and a list of descriptors 06:12:46 ... characteristics could be "heartbeat measurement", "latitude", "longitude" 06:12:53 ... there's a characteristic for subscribing 06:13:27 s/characteristic/descriptor/ 06:13:56 ... Services, Included Services, Characterstics, and Descriptors all four have UUID types identifying them 06:14:06 ... one of the Descriptor types is the method for subscribing to notifications 06:14:20 ... we expose the notion of subscribing to notifications, rather than the descriptor 06:14:46 [ Security ] 06:14:58 jyasskin: because most GATTs are short values, it's easier to write a parser 06:15:06 ... we expect there will be fewer attacks 06:15:14 ... every Bluetooth device is open to the air 06:15:18 ... everyone can attack it 06:15:21 https://developer.bluetooth.org/gatt/Pages/GATT-Specification-Documents.aspx 06:15:51 Josh_Soref: is it true that they're hardened or is it hand waiving? 06:15:56 jyasskin: it's hand waiving 06:16:04 jyasskin: it's possible to identify devices 06:16:17 ... each device has an address, either immutable, or changeable 06:16:30 ... to avoid identifying devices, we don't expose the device address 06:16:38 ... it's still possible for a device to leak its identity 06:17:05 dom: a device could be part of the attack? 06:17:13 Josh_Soref: or it could be poorly implemented and leak itself 06:17:37 QQQ: can you connect to a specific device by ID? 06:17:47 jyasskin: no, the user has to choose the device from the picker 06:17:56 ... you could forcibly filter by criteria 06:18:18 ... this mitigates a piece of the privacy risk (by not exposing MAC addresses) 06:18:24 [ Discovery ] 06:18:35 jyasskin: you call requestDevice(/* filters */) 06:18:44 ... currently the spec only provides filters by UUID 06:18:54 ... looking at devices, many don't advertise services 06:18:58 ... some only provide names 06:19:07 ... we're also looking at manufacturer name 06:19:14 ... so the filter will soon include those two fields 06:19:24 dom: does that increase the fingerprinting surface? 06:19:29 jyasskin: it does 06:19:38 ... manufacturing name is key-value pairs 06:19:52 ... all iBeacons broadcast the same name in Apple's namespace 06:19:57 ... and none of this is particular devices 06:20:04 Travis: what's the end result? 06:20:20 jyasskin: the browser will filter nearby devices to matching devices and then show the user a list of nearby matching devices 06:21:18 Josh_Soref: does the UI favor/highlight paired devices? 06:21:22 jyasskin: not today 06:21:38 ... let me show you Google Chrome Dev with its select 06:21:43 ... any M device supports this 06:21:51 ... I can walk around 06:22:02 ... here I'm saying get battery service, and it shows a list of devices that are nearby 06:22:25 ... right now, we show paired + discovered (thus a device will be shown twice) 06:25:08 Josh_Soref: do users really understand that pairing fully exposes everything? 06:25:43 jyasskin: we're trusting that users will understand that pairing is dangerous 06:25:54 dka: the model is origin limited per device, right? 06:25:57 jyasskin: yes 06:26:57 dka: e.g. individually pairing Skype.com vs. Hangouts would be distinct pairings? 06:26:59 jyasskin: ys 06:27:12 Josh_Soref: but if I pair Skype.com and then use Outlook.com it might work? 06:27:28 jyasskin: it currently only allows top level windows 06:27:33 ... but we need to look at iframes 06:27:40 anssik: how did Geolocation solve this? 06:27:42 dom: they didn't 06:27:47 ... I did a review 06:27:55 ... none deferred based on top level or not 06:28:09 anssik: I think it's a good idea to take a decision, or limit to top level 06:28:30 anssik: perhaps we could ask TAG 06:28:32 jyasskin: there's a proposal for a top level attribute 06:28:41 anssik: it's used for full-screen 06:28:45 dka: is there an issue? 06:28:58 ... I could open an issue in our repo to comment on this issue 06:29:05 https://github.com/WebBluetoothCG/web-bluetooth/issues/57 ? 06:29:09 jungkees: isn't this the space where secure-contexts come in 06:29:14 https://github.com/WebBluetoothCG/web-bluetooth/issues/57 mentions iframe at least 06:29:17 ... don't allow anything in non-secure contexts 06:29:28 jyasskin: we're talking about more restrictions on top of that 06:29:36 ... it already has to be a secure-context 06:29:57 mfoltzgoogle: in some of these device apis, it's challenging for there to be a human readable description 06:30:07 ... what is there for human readable? 06:30:22 jyasskin: we've punted on service descriptions, since it requires a registry of names 06:30:28 mfoltzgoogle: does BTLE have a registry? 06:30:30 jyasskin: no 06:30:34 ... if they did, we'd use it 06:30:37 q+ to ask about re-pairing 06:30:44 ... for device names, we use the device name 06:30:52 ... some don't even have names at all 06:31:00 ... we could use the BT MAC 06:31:08 ... we could specify that the device name is empty 06:31:26 ... there's also an escape hatch in the spec to allow the UA to show non matching devices 06:31:29 wonsuk_ has joined #web-bluetooth 06:31:31 ... Chrome currently doesn't 06:31:38 dom: does that have security implications? 06:32:01 Josh_Soref: the user there has to choose to shoot themselves in their foot? 06:32:10 dom: if you promise people money 06:32:25 jyasskin: if the web site wants the user to pick a particular device, they can filter for that device 06:32:37 ... if the user picks a device that doesn't have a matching service, they'll find the service isn't present 06:32:50 ... the expected service won't be there, a rejected promise, and the page won't work 06:32:56 dom: does it require a user interaction? 06:33:04 jyasskin: i'm using can-show-a-popup from HTML 06:33:18 dom: does that allow easily to repair with the same device? 06:33:46 jyasskin: i have an issue to find the devices you've selected in the past 06:33:59 ... the security model is, if you pair w/ a device, it's yours until you unpair it 06:34:07 ... there's no way to get those devices 06:34:17 dom: for users, you'd have a per-origin-id 06:34:26 jyasskin: and you'd get a list of devices you've been paired 06:35:21 Josh_Soref: I'd favor having the UA manage the memory instead of the App 06:35:31 jyasskin: our security people asked users what they expect 06:35:38 ... users expect permission pairing to last forever 06:35:51 ... a demo we have is a set of juggling balls 06:36:03 ... we're currently missing the api to request multiple 06:36:14 ... and there's no way to know if you've already paired one 06:36:24 ... i think the web site should be able to present its own UI 06:36:32 ... and the UA should be able to identify which ones you've paired 06:36:47 ... the web page could call it multiple times 06:36:53 anssik: for enumerateDevice() 06:37:13 dom: with enumerateDevices() you get the full list of available devices on the platform, with an ID for getUserMedia() 06:37:46 ... depending on the browser, typically, in chrome, once you're granted access to a microphone on an https origin, that applies to all microphones for that origin 06:37:53 Travis: are uuids hard coded into devices 06:38:04 jyasskin: yes, service uuids are kind of protocols, so uuids identify protocols 06:38:25 ... uuid is what it's called in Bluetooth, everyone expects it to be that 06:38:54 [ BluetoothGATTService ] 06:39:04 jyasskin: someone suggested that UUID uuid should be `type` 06:39:53 ... if we were designing from scratch, we would do this 06:40:13 Travis: we should be designing for the future 06:40:27 Josh_Soref: WebGL made mistakes like this, can we avoid this? 06:40:36 Travis: for the record, WebGL 2 is redesigning for this 06:40:58 mfoltzgoogle: how feasible would it be to add origin lists for devices? 06:41:09 jyasskin: I've gone to the BT SIG and tried to start that conversation 06:41:20 ... i'm confident we should do that through them rather than starting here 06:41:24 ... they weren't very receptive 06:41:30 ... it's not clear that they were very receptive 06:41:42 ... not clear if we haven't explained it well, and not sure if they understand 06:41:57 ... basic idea would be to allow device to advertise which origins which origins it's willing to talk to it 06:42:02 ... and tell it which origin is talking to it 06:42:11 ... and if multiple tabs spoke to it, we'd have to switch modes with it 06:42:17 ... useful for the web model 06:42:23 ... safe enough to do that as an opt in thing 06:42:33 ... always have to deal w/ devices that don't advertise that service 06:42:40 ... safe enough to allow devices to talk to that 06:42:56 ... and then as we talk to devices, some manufacturers will talk to SIG 06:43:02 ... also useful for native devices 06:43:16 ... you pair devices to phone, but you have multiple native apps, some safer than others 06:43:20 q+ 06:43:28 dom: what's youre relationship w/ sig? 06:43:33 s/youre/your/ 06:43:41 jyasskin: Google is part of the sig 06:43:50 ... the CG isn't 06:43:59 dom: a few years ago, we had a call with the sig 06:44:04 jyasskin: i don't know 06:44:12 ... I don't know if the CG could be part of the sig 06:44:22 dom: thinking a liaison between W3C and BT SIG 06:44:31 dka: i could see where that would be useful 06:44:39 ... get people in BT SIG talking about work going on here 06:44:47 ... what's going on w/ W3C API 06:44:56 jyasskin: it would be useful to have an official liaison 06:45:11 ... BT SIG has an Internet WG, for a router for GATT traffic, totally insecure 06:45:28 ... it would help them to have communication w/ web people, help us to have communication w/ them 06:45:33 ... i don't have the bandwidth to be that 06:45:38 dom: part of a broader conversation 06:45:49 ... about Web BT CG wants to move forward 06:45:50 mfoltzgoogle has joined #web-bluetooth 06:46:00 ... I don't think W3C could offer a Liaison for a CG 06:46:13 q- mfoltzgoogle 06:46:19 ack me 06:46:19 dom, you wanted to ask about re-pairing 06:46:21 q+ mfoltzgoogle 06:46:31 q? 06:46:35 ack timeless 06:46:48 akeranen has joined #web-bluetooth 06:47:59 Josh_Soref: I'm concerned, I buy a product, I expect to be able to use my device w/ an app of my choice, not just the broken one from my vendor 06:48:08 jyasskin: we'd like to support CORS 06:48:21 ajitomi_ has joined #web-bluetooth 06:48:22 dom: there are discussions on a hardware WG to access SE 06:48:39 ... the question of SE has whether should only connect to some origin 06:48:48 ... if the hardware guys align with the web origin model 06:49:05 jyasskin: we've been talking with Ryan Slevi 06:49:24 ... main argument for more access to BT than hardware is that BT is exposed to random radio waves 06:49:29 ... with BT LE, a lot of people aren't pairing 06:49:40 ... fitbit doesn't do BT pairing, they have their own encryption system 06:49:43 hito has joined #web-bluetooth 06:49:47 ... I haven't done the survey to make this rigorous 06:49:57 ... manufacturers are doing security w/o relying on pairing 06:50:07 dom: i thought encryption in LE was quite weak 06:50:19 jyasskin: in 4.2 it gets better, in 4.0 it's quite weak 06:50:28 ... another reason manufacturers are routing around it 06:50:39 [ BluetoothDevice ] 06:50:54 jyasskin: a BT Device has properties, vendor, ... 06:51:05 ... some are redundant with particular gat service 06:51:21 ... we have a gatt server: connnectGatt() 06:51:30 ... perhaps in some cases you don't need that (advertising?) 06:51:39 [ BluetoothGATTRemoteServer ] 06:51:45 jyasskin: this has a list of services 06:51:53 ... you query one at a time, or get all of a set 06:52:03 [ BluetoothGATTService ] 06:52:20 dom: when you gain access to a device, you get access to all services 06:52:38 jyasskin: when you call requestDevice(), you're limited to the services you asked for 06:52:57 dom: then why were you ... 06:53:10 jyasskin: we're thinking TAG 06:53:13 Josh_Soref: IANA? 06:53:25 jyasskin: the people writing the spec will probably end up designing the registry 06:53:36 ... it's tricky, there's reason to lie on the registry 06:54:05 dom: that's a way to access? 06:54:12 jyasskin: currently we have a blacklist of services, it's in github 06:54:17 ... we'd prefer a whitelist 06:54:26 ... but we'd have to be pretty permissive to let people add themselves 06:54:33 ... risk that an attacker adds a service to the whitelist 06:54:38 ... no good way of vetting 06:55:07 https://github.com/WebBluetoothCG/registries/blob/master/gatt_blacklist.txt 06:55:29 dom: you're importing this into Google Chrome? 06:55:36 jyasskin: not yet, we plan to update dynamically 06:55:46 ... get that recognized in all browsers fairly quickly 06:56:24 Josh_Soref: how do you defend against attackers who block content? 06:56:42 jyasskin: we need them to have clean access to the web fairly regularly 06:56:58 ... if you're not able to update your browser periodically, the attacker can exploit your browser 06:57:07 mfoltzgoogle: the UC in your example of pairing your wearable/heartbeat device 06:57:14 ... seems like a good fit for ServiceWorker 06:57:24 ... you don't support Transferable 06:57:43 jyasskin: we don't have the permission model for permission access to background 06:57:52 mfoltzgoogle: i'm confused 06:58:07 jyasskin: users expect that things are accessible while they're using an app 06:58:15 ... that's not true on Android 06:58:21 dom: it's better on iOS? 06:58:42 jyasskin: yes, iOS changed, it will ask you later if you "were aware that it was getting your info in the background" 06:58:42 ShaneM has joined #web-bluetooth 06:58:52 anssik: do you want to go over issues? 06:59:03 jyasskin: i think the free-form discussion has been good 06:59:12 ... I can also show a video 06:59:18 RRSAgent, draft minutes 06:59:18 I have made the request to generate http://www.w3.org/2015/10/26-web-bluetooth-minutes.html timeless 06:59:28 https://www.youtube.com/watch?v=tRMcMDIyIGQ 06:59:38 present+ ShaneM 06:59:45 dka has joined #web-bluetooth 06:59:51 present+ Dan Appelquist 07:00:35 present+ Ari_Keranen 07:00:52 present+ brsun 07:01:31 i|Some links|-> https://play.google.com/store/apps/details?id=io.github.webbluetoothcg.bletestperipheral https://play.google.com/store/apps/details?id=io.github.webbluetoothcg.bletestperipheral 07:02:26 rrsagent, draft minutes 07:02:26 I have made the request to generate http://www.w3.org/2015/10/26-web-bluetooth-minutes.html timeless 07:03:30 s|Some links: https://www.youtube.com/watch?v=tRMcMDIyIGQ, https://googlechrome.github.io/samples/web-bluetooth/, https://play.google.com/store/apps/details?id=io.github.webbluetoothcg.bletestperipheral| 07:04:36 s|https://play.google.com/store/apps/details?id=io.github.webbluetoothcg.bletestperipheral|BLE Peripheral Simulator 07:04:46 rrsagent, draft minutes 07:04:46 I have made the request to generate http://www.w3.org/2015/10/26-web-bluetooth-minutes.html timeless 07:05:24 q+ 07:06:07 i|[ Spec ]|topic: Web Bluetooth specification 07:06:10 i|[ Spec ]|-> https://webbluetoothcg.github.io/web-bluetooth/ Web Bluetooth 07:07:33 i|[ Security ]|topic: Web Bluetooth security 07:07:38 i|[ Security ]|-> https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy Security and privacy considerations 07:15:11 dka has joined #web-bluetooth 07:19:26 jyasskin has joined #web-bluetooth 07:20:09 i|[ Security ]|topic: Web Bluetooth Attacks on devices 07:20:12 mfoltzgoogle has joined #web-bluetooth 07:20:17 s/topic: Web Bluetooth Attacks on devices// 07:20:29 i|[ Attacks ]|topic: Web Bluetooth Attacks on devices 07:21:01 i|[ Attacks ]|-> https://webbluetoothcg.github.io/web-bluetooth/#attacks-on-devices Attacks on devices 07:21:28 ShaneM has joined #web-bluetooth 07:21:37 dka: Physical Web? 07:21:47 topic: Web Bluetooth General Roadmap 07:22:05 jyasskin: you can't implement the physical web scanner in the current api 07:22:27 ... I filed a TAG issue ... the notion of a referring device 07:22:37 ... both NFC and Bluetooth and USB could open a web page in response to a device 07:22:48 ... if the user has chosen to open a web page, they shouldn't get a redundant device 07:22:56 ... there should be a way to say "here's the device that opened you" 07:23:09 ... initially we could have a Navigator.requestingDevice... 07:23:21 ... user clicks the device in their list, web page opens, and can communicate with the device 07:23:23 dka: interesting 07:23:27 jyasskin: roadmap... 07:23:30 ... scanning 07:23:41 tomoyuki has joined #web-bluetooth 07:23:42 ... - being able to figure out what devices are nearby, we have an idea for how to do that permision 07:23:49 s/mision/mission/ 07:23:56 ... - upgrading from scanned to permission 07:24:02 riju has joined #web-bluetooth 07:24:04 ... background -- from a ServiceWorker 07:24:18 ... acting as a Bluetooth peripheral, possibly over the classic protocol 07:24:40 Josh_Soref: why do you care about Classic v. LE 07:25:06 jyasskin: sorry, I meant: 07:25:12 ... acting as a Bluetooth peripheral 07:25:23 ... separately: acting as a Bluetooth classic peripheral 07:25:33 ... we'll do these after we do the easier pieces 07:25:38 ajitomi has joined #web-bluetooth 07:25:41 dka: the issue around physical web, i didn't understand that flow 07:25:46 ... is that part of the normal ideas? 07:25:56 ... my understanding was you'd have a BTLE advertising a URL 07:26:14 ... once you start a thing, you open a url, you're done w/ the device 07:26:24 ... but you're imagining the web page to maintain a connection to the device 07:26:26 jyasskin: yes 07:26:30 ... imagine the happy meal toy 07:26:38 ... a turtle w/ a couple of LEDs and can play a bit of audio 07:26:44 ... it advertises a physical web url 07:26:52 ... it has BT but not Cell/WiFi 07:27:01 ... the web page has "be happy"/"be sad"/"be green" 07:27:08 ... you control your happy meal toy from your phone 07:27:23 dom: the assumption is that clicking the url gives you permission to interact with the device 07:27:41 jyasskin: security is that clicking it has established something to communicate with it 07:27:49 ... but it's a physical web device, it's granting its concent 07:28:11 Josh_Soref: what's the range of physical web 07:28:37 jyasskin: 100ft 07:28:42 ... range is pretty far 07:28:53 s/100ft/100m/ 07:28:53 Zoltan has joined #web-bluetooth 07:29:28 Josh_Soref: i'm worried about devices 07:29:57 jyasskin: you can build the antenna and attack 07:30:24 shayne: are devices identical? 07:30:35 jyasskin: it's possible to make several chips that are truely identical 07:30:38 ... but two probably couldn 07:30:42 s/... but two probably couldn// 07:30:49 ... but two probably couldn't coexist near eachother 07:31:06 jocelyn: you mentioned act as a sever 07:31:11 s/sever/server 07:31:14 jyasskin: you guys have that 07:31:27 ... there's advertise and act as a server 07:31:37 ... a physical web beacon only needs to advertise, it doesn't need to serve 07:31:43 dom: for standardization 07:31:53 ... have you made any progress on moving to a WG? 07:32:00 jyasskin: i don't think anyone objects to moving to a WG 07:32:06 ... we're about to have a second implementation 07:32:10 ... Chrome isn't finished 07:32:18 ... I think we'd be totally happy going to a WG 07:32:23 dom: DAP is rechartering 07:32:30 ... I guess you'd rather be in Web Platform 07:32:34 jyasskin: I think so 07:32:40 dom: Web Platform just rechartered 07:32:56 jyasskin: we should get on their queue for getting in 07:33:11 Travis: they have a process for pulling things in, and the charter is only one year 07:33:20 jyasskin: I'm not the whole CG, but I think a lot of it is here 07:33:26 ... does anyone think we should stay as a CG? 07:33:27 zkis has joined #web-bluetooth 07:33:33 dka: I'd hope to see implementations out there 07:33:39 present+ zkis 07:34:05 dka: I'd hate to see people slowing down their implementation based on "oh wait, it'll be a WG, we should wait for LC" 07:34:23 anssik: I think we should be able to Fast Track, it's better than FPWD 07:34:33 dom: moving to WG is better than being effective CR 07:34:42 dka: the controversy around the TPAC App 07:34:55 ... giving everyone connected with this, some additional justification for making this happen 07:35:02 ... remove technical barriers 07:35:13