16:06:28 RRSAgent has joined #auto 16:06:28 logging to http://www.w3.org/2015/07/28-auto-irc 16:06:31 Zakim has joined #auto 16:09:26 topic: Introduction 16:09:39 hira: Hirabayashi from KDDI 16:09:54 hashi: Hashimoto from KDDI 16:10:55 kaz: Kaz Ashimura from W3C working with Ted for the Automotive groups 16:11:03 urata: Urata from ACCESS 16:11:22 junichi: Junichi Sakamoto from AptPod 16:12:14 john: John Schneider from AgileDelta, Editor of EXI 16:12:22 Present+ Tatsuhiko_Hirabayashi(KDDI), Junichi_Hashimoto(KDDI), Kaz_Ashimoto(W3C), Junichi_Sakamoto(Aptpod), Shinjiro_Urata(Access), John_Schneider(Agile), Ted_Guild(W3C), Dave_Jenson(RoadRules), Greg_Brannon(AAA), Dan_White(Here), Kevin_Gavigan(JLR)[remote] 16:12:52 Hirabayashi has joined #auto 16:13:38 ted: Ted Guild from W3C 16:13:48 dave: Dave Jensen 16:14:12 s/Jensen/Jensen from RoadRules/ 16:14:57 greg: Greg Brannon from AAA 16:16:15 paul: Paul Boyes form OpenCar 16:16:17 Present+ Paul_Boyes(OpenCar) 16:16:52 Chair: Paul 16:17:23 adam: Adam from Nokia 16:18:09 urata_access has joined #auto 16:18:51 Topic: Spec 16:18:56 paul: we have isses, e.g., refactoring APIs 16:18:59 -> https://github.com/w3c/automotive/issues/ Issues list 16:19:24 -> https://github.com/w3c/automotive/issues/37 Issue 37, refactoring the API 16:19:27 paul: that's one of the big issues 16:20:37 greg: maybe we could quickly review the situation? 16:20:53 paul: (summarizes the group's activities) 16:21:03 -> http://www.w3.org/TR/#tr_Automotive Data Spec and Vehicle API FPWD 16:22:03 ted: (mentions the IRC channel is available at http://irc.w3.org/?channels=auto 16:22:35 paul: (shows the Automotive wiki) 16:23:20 John_Schneider has joined #auto 16:23:32 djensen47 has joined #auto 16:23:50 paul: the spec split into to two pieces 16:25:20 -> https://www.w3.org/auto/wg/wiki/Main_Page WG wiki 16:25:39 gbrannon has joined #auto 16:26:05 -> http://rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html vehicle API spec (Editor's draft on rawgit) 16:29:02 paul has joined #auto 16:29:05 -> http://www.w3.org/TR/#tr_Automotive published version of the specs 16:29:31 -> http://www.w3.org/TR/vehicle-information-api/ vehicle api fpwd 16:30:54 paul: defines access methods 16:32:12 -> http://www.w3.org/2015/07/vehicle-api.html vehicle api (snap shot version) 16:32:36 paul: can get information from the Web runtime 16:32:40 -> http://www.w3.org/2015/07/vehicle-data.html vehicle data spec snapshot 16:32:49 ... there was discussion on zones 16:32:58 ... availability of the data 16:33:21 [browser for meeting room projector had javascript disabled, breaking respec formatting hence snapshots] 16:33:58 AdamC has joined #auto 16:33:59 greg: some auto maker may not provide information even if some of them is available? 16:34:31 paul: GENIVI, etc., did the basic work 16:36:08 ... some data fallback might happen if the data is not available 16:36:21 paul provides some history on early input for the spec, how some elements are not exposed by different manufacturers, in different model cars etc 16:37:04 dave: the example codes provide good information 16:37:22 -> http://www.w3.org/2015/07/vehicle-api.html#introduction example in spec 16:37:37 dave: the signature of the apis 16:38:17 ... get, set, subscribe, unsubscribe 16:40:09 greg: set for actuation? 16:40:15 paul: heater level, etc. 16:40:50 ... that part has security issues, so started security&privacy TF 16:41:13 ... largest topic is security 16:41:31 s/topic/topic (on "set")/ 16:42:15 dave: there is error interface as well 16:42:41 adam: what identifiers do we have besides vin? 16:42:53 paul: vehicle manufacturer id 16:43:36 adam: identification? 16:44:14 s/adam: identification?// 16:44:30 -> http://www.w3.org/2015/07/vehicle-data#idl-def-Identification Identification 16:45:04 junichi has joined #auto 16:45:51 s/Identification/Identification in the vehicle data spec (fpwd)/ 16:45:54 s/vehicle manufacturer id/world manufacturer id (wid)/ 16:46:57 greg: identify the user as well? 16:48:13 adam: applications might be very user-specific 16:48:39 ted: certainly some use cases - a car specific profile for different drivers that use it. seat, mirror position, preferred climate settings etc 16:49:16 KevG has joined #auto 16:49:19 adam: potentially some users are interested in user-specific data 16:49:37 rrsagent, draft minutes 16:49:37 I have made the request to generate http://www.w3.org/2015/07/28-auto-minutes.html kaz 16:50:09 present+ Adam_Abramski 16:51:19 adam: the vehicle/fleet owner might like to know things about how a given driver is behaving in the car 16:52:06 Present+ Adam_Crofts(JLR)[remote] 16:52:27 adam: missing piece is identifying users 16:53:23 adam: user signature corresponding to seat, mirror settings 16:53:50 john: e.g., for 9.9 seat interface 16:54:00 -> http://www.w3.org/TR/vehicle-data/#seat-interface seat interface 16:54:29 paul: identifying users in the car 16:54:34 ... what's the method? 16:54:56 -> http://www.w3.org/2015/07/vehicle-data#idl-def-IdentificationType Ways to identify a user - bluetooth device, pin, voice etc 16:55:12 paul: user identification interface 16:56:01 s/etc/etc (Editor's draft snapshot) 16:56:15 paul: action for somebody? 16:56:45 ... we'll have a breakout tomorrow 16:57:04 greg: is there interface for locking? 16:57:31 ted: child lock? 16:57:42 s/lock/lock for doors/ 16:58:43 greg: somebody may want to have a interface to unlock the door remotely 16:59:01 dave: somebody commented on GitHub 16:59:23 s/child lock?/child, window and door lock status - read-only/ 16:59:59 dave: some would prefer a verb instead of set function eg door.unlock instead of door.setLock(unlock) 17:00:25 Hi guys, audio is still very faint are the microphones in the same room :-) 17:00:55 s/ ... what's the method?/hira: The question is how we get user id. 17:01:14 Sounds like only one is working and its along way from Paul?? 17:02:12 rrsagent, make log public 17:02:19 rrsagent, draft minutes 17:02:19 I have made the request to generate http://www.w3.org/2015/07/28-auto-minutes.html kaz 17:02:30 Thanks, much appreciated... 17:03:18 s/child lock for doors/child, window and door lock status - read-only/ 17:03:43 Possibly slightly 17:04:09 paul: Hirabayashi-san mentioned in Santa Clara before 17:04:36 john: cloud sourcing interlock problem? 17:04:46 s/interlock/antilock/ 17:05:06 [aggregate information for possible alerts like icing on part of a roadway] 17:05:25 john: do you have any information for antilocking? 17:05:54 -> http://www.w3.org/2015/07/vehicle-data#antilockbrakingsystem-interface Anti-lock braking 17:06:26 paul: (shows 9.2.1) 17:07:12 paul: related to geolocation information 17:08:06 adam: granularity of geolocation information may be related to privacy issues 17:08:57 greg: additional use cases? 17:09:26 paul: up to the group 17:09:58 ... would to see is having informative use cases 17:10:09 ... why we need use identification, etc. 17:10:52 ... another thing is the size of the information 17:11:06 ... e.g., JSON is not necessarily compact 17:11:35 ... compact format for low-level devices? 17:12:56 ... would make the spec useful 17:13:41 hira: JSON is very heavy for general ITS purposes 17:13:59 john: EXI is 10 times compact than JSON 17:14:05 Kev_G has joined #auto 17:14:19 ... faster and smaller 17:14:58 ... we can save money by using compact format 17:15:56 -> http://www.w3.org/TR/exi/ EXI 1.0 spec (second edition) 17:16:04 paul: (look at the Charter) 17:17:03 s/Charter/Abstract section of the vehicle API spec/ 17:17:49 -> http://www.w3.org/TR/vehicle-information-api/#abstract Abstract 17:18:23 paul: need states of heater, etc. 17:19:15 ... lots of data element which need states 17:19:36 ... higher, medium, lower, etc. 17:19:53 ... would see a mechanism to manage states 17:21:10 s/a mechanism/an extensible mechanism/ 17:22:50 greg: how to map the data spec to actual cars? 17:24:11 ... has to have diverse set of mapping mechanism 17:24:36 -> https://lists.w3.org/Archives/Member/internal-autowebplatform/2014Dec/att-0000/JLR_to_W3C_Presentation_presented_at_genivi.pdf JLR implementation evaluation presentation 17:24:41 ... need to comply to specific regulations based on the location 17:25:15 s/... need/greg: need/ 17:25:39 Paul has joined #auto 17:25:46 ted: put a link to JLR's presentation 17:26:28 paul: (opens JLR's presentation) 17:26:45 paul_ has joined #auto 17:27:41 ted: oem will be able to expose some initially and add gradually as they are more comfortable with privacy protections, renegotiate data usage with tier one ECU manufacturers, etc 17:28:02 adam: merging data of discussion within a car manufacturer internal, out sourcing, etc. 17:31:53 paul: spec review and JRL alignment 17:32:16 ... JLR signal review and treatment 17:33:42 AdamC: PaulW did the review 17:34:11 ... quite a lot of challenges for OEMs 17:34:41 ... implementing the interfaces 17:35:22 s/AdamC:/Kevin:/ 17:36:15 paul: you can see some of the security concerns 17:37:24 Present+ Greg_Smith(Theia_Labs) 17:39:03 paul: everyone wants the data like money 17:40:41 Kevin: vehicles have to be protected 17:42:17 greg: but don't think we need to talk about new access point within car 17:43:12 ... head units are already installed in cars 17:43:56 Kevin: OEMs need to provide a mechanism to protect cars 17:44:12 ... so that cars are not hackable 17:44:38 s/protect cars/protect connected cars/ 17:45:26 ... hackers might be going to reverse-engineer the firmware 17:46:21 ... need to protect multiple software during the long car lifetime 17:46:53 [ morning break ] 17:46:57 rrsagent, draft minutes 17:46:57 I have made the request to generate http://www.w3.org/2015/07/28-auto-minutes.html kaz 17:47:46 present+ Ivan_Sucharski(Here) 17:47:53 s/adam:/ivan:/g 18:03:58 scribenick: ted 18:04:11 Topic: W3C IVI Exploitation Discussion 18:04:51 Presenter: Craig Smith from Theia Labs 18:05:32 Craig: we started with web and hardware penetration tests and security and have moved into cars 18:06:26 ... i had a two hour long commute and wanted to modify my ivi system for other purposes 18:06:46 kaz_ has joined #auto 18:07:16 ... this year has been pretty automotive specific. we run Open Garages to talk about cars, share modifications and research 18:07:34 Zakim has left #auto 18:07:56 ... there is a balance between how much you can discuss before you get cease and desists 18:08:38 ... i wrote the car hackers manual last year to go with a cyber-security class 18:09:15 ... we will have a new book coming out later this year. the previous was high level and had presentations as supporting materials for the class 18:09:49 ... i have nda in place with some oem so i cannot say specifics on any given vehicles for instance 18:12:12 [slides attached to https://lists.w3.org/Archives/Public/public-auto-privacy-security/2015Jul/0016.html] 18:12:43 Craig: we'll pull an IVI system out of a vehicle, attach power supply and be able to examine it on test bench (desk) 18:13:16 ... target update/upload mechanism - cd/dvd tray, usb, etc 18:13:46 ... i look at jtag and sd cards as well 18:14:06 ... the real goal is to get into the os 18:14:28 ... once you are in the os you are common ground for general exploits (escallate to eg root privs) 18:15:18 ... exploitations are easy as they tend to be running older versions of software. catalog the software present and then look at their security bug lists 18:16:39 ... there are simple misconfigurations that can be taken advantage and assumptions things like the cellular network are secure (man-in-the-middle possible with about $1k of hardware) 18:17:23 ... they do not use encryption often, seldom no pki authentication 18:17:59 ... lack of segregation of systems 18:18:30 ... if you have code execution at the os level and the only thing preventing full communication with the can bus is a shared library restricting it, you replace it 18:18:58 ... the OS itself usually doesn't have the usual hardening practices in place 18:19:49 ... you are going after code execution. what vehicle controls you can get at, enough to steal it or just privacy/spying 18:21:20 ... there are amplification attacks for example nfc from keyfobs. some people started keeping their keys in the freezer after that hit the news... 18:22:21 ... once you have shell access on the IVI OS you are perhaps more interested in spying than controlling the vehicle. can you get access to mic, geolocation 18:24:05 ... you can sometimes simply grab a text file logging interesting evens that the oems feel they may want (or already send upstream to them) 18:24:13 greg: so you're saying oems are already sending data home? 18:24:49 craig: yes, in some cases. it can also just be last several hours so they can find out what was going on 18:25:02 ... there are no retention policies in place 18:25:30 ... stunt hacking - latest big example was the Jeep hacking story 18:26:46 ... there is legislation pending for security experts limiting what they can do, requiring licensing etc 18:27:11 ... clearly i'm against that 18:28:20 [craig describing his web based "fleet management"/botnet system] 18:28:38 craig: with a little bit of infrastructure you have something very scalable 18:30:04 ... when you have a vulnerability you are not sure the scope of vehicles it might apply to, varies from year to year and model depending on versions of software installed 18:30:54 ... some of the hurdles: you might be a vm and need to get out to main system, not connected to desired bus, telematics are separated 18:31:54 ... if the packet you want to [re]play (recorded some other way) are on a different bus (eg rpm) it often turns out you can send it on the wrong bus 18:32:36 ... the buses tend to be interconnected 18:33:17 ... you sometimes have to jump from one system to another 18:33:51 ... the digital radio broadcast hack is perhaps more interesting than the jeep cherokee/sprint one 18:34:20 ... you could send an exploit over a radio broadcast 18:37:14 greg: we have done a little research in this area and it is in line with what you are saying. once you're on the car you're on... the number of attack vectors are ridiculous 18:38:08 ... how do we go from where we are today to a more security vehicle? focus on attack vectors? 18:40:09 -> https://www.iamthecavalry.org/ I Am the Cavalry is working on exposing bad practices 18:41:10 craig: i am the cavalry is working together collaboratively, making observations on vulnerabilities, providing recommendations on better design, etc 18:42:34 ... encourage oem to create responsible disclosure channels. we are acting as a clearing house between researchers discovering things and oems 18:42:47 ... discovery acknowledgement is usually all people want 18:45:35 ... evidence capture is an important use case, for accident forensics, proof of exploitation, etc 18:45:53 ... over-the-air updates are essential 18:46:55 ... i want to see more of a shift where someone submits and issue and it gets acknowledged and fixed without waiting until they get to the point a recall is compelled 18:47:39 ... risks and vulnerabilities will emerge and you need to be able to address them 18:48:27 [discussion of the bmw key issue and how they upgraded ota, disclosure from expert went through assistance of aaa of germany] 18:48:49 [similar to iamthecalvary tries to help in this arena] 18:51:10 craig: some are proponents of firewalls and encryption without looking at other concerns 18:51:43 ... here i am not sure firewall approach would work. it just blocks one attack vector and i'll look at another 18:53:21 ... you should have systems looking for anomolies 18:54:02 -> https://www.iamthecavalry.org/domains/automotive/5star/ 5 star security 18:54:55 craig: tesla is a great example with clear privacy policy, upgrades and responsible disclosure 18:55:08 dave: if you have segregation then ota upgrades can be problematic 18:55:39 craig: absolutely especially when you have air gaps. you have to do a chain of custody for upgrades, it is more work 18:56:10 ... completely isolated systems are not a bad thing in some areas, attackers can't get at them either 18:58:15 ... can buses are extremely efficient and well designed for their initial needs but lacking security design 18:58:41 s/can buses/CAN buses/ 18:58:58 ... we are starting to see traditional can switch to ethernet+udp and then firewalling will make more sense 18:59:44 ivan: without speaking about specific vehicles, can you give us some stats or percentages, examples of complexity 19:00:19 craig: modern vehicles expose many attack vectors are a soft security core 19:01:19 ... there are a bunch of vehicles out there with vulnerabilities. there are some oem who have been informed of a remote vulnerability and due to cost have not issued a recall, hoping others do not discover it 19:01:29 ... it is kind of bad right now 19:02:21 ... [unminuted major oem] has just created a 50 person security team, which is pretty impressive since there are not that many auto security people 19:02:30 ... retraining and acquiring people 19:03:30 ... there is a scramble to solve the problem by throwing money at outsourced solutions and some of those systems are wholly insufficient 19:04:35 ... even with all that energy they can miss one component 19:05:40 ... that doesn't mean you shouldn't focus on better protecting the bigger attack surfaces. you should also focus on what you are trying to protect against 19:06:28 dan: do you do threat modeling? 19:06:48 craig: yes, going through the various channels 19:07:56 ... it identifies what you should be focusing on 19:08:38 ... i like to do threat boundaries based on distance - tpms is short range, cellular is open to the internet 19:09:33 ... so if you have something from internet direct to userland, you should focus on that there. make sure it is in a chroot like environment as an initial step 19:09:55 dave: you mentioned some thoughts on privacy 19:10:59 craig: there is a ton of data collection go on right now with data going upstream. the shoe is going to drop on that one 19:11:17 greg: there is pressure for full disclosure on what they are collecting and what they are doing with it 19:11:47 craig: only one i'm aware of with good disclosure at the moment is tesla 19:12:50 ... v2x is not just about sharing data but also being used for financial transactions 19:13:24 dave: have you had a chance to look at what we're working on. you said you don't look too close into apps as an attack vector 19:13:40 craig: it was interesting to see all the methods and data types spelled out as you have 19:14:12 ... it is a higher and cleaner level of abstraction compared to what you typically have to do at a much lower level 19:14:26 ... how it is implemented will be important 19:18:59 ted @@@ on modsec web server model 19:21:10 greg: many attackers would first focus would be on an api as a convenience before looking for lower level exploits 19:21:41 ted: and perhaps replace or bypass the shared library if on the same system 19:23:31 [comments on reverse engineering shared libs to learn bus dialects] 19:24:55 craig: it use to be that i could get a more complete maintenance manual for my car, now we many lines of copyrighted software and i'm not allowed to understand how my car works 19:26:55 craig: i wouldn't be opposed to owner being able to clear their "black box" cache 19:27:35 ted: legally an individual does not have to incriminate themselves, their cars still can 19:27:45 [who owns the data?] 19:29:17 [discussion on policy and legislation] 19:29:40 hira: thought some of the BG participants said that security issues are issues of implementations 19:29:51 craig: high level policies and legislation do not have enough details or teeth 19:29:58 ... do you think we need discussion from the viewpoint of standardization? 19:31:28 craig: some can be more explicit and required like mandating over the air upgrade 19:32:52 s/... do you think we need discussion from the viewpoint of standardization?// 19:32:58 i/high level/... do you think we need discussion from the viewpoint of standardization? 19:33:18 ted @@on risk and cost of recalls - postage on usb fobs alone.. good we have legislators pushing this industry 19:36:48 I have made the request to generate http://www.w3.org/2015/07/28-auto-minutes.html ted 20:50:53 Paul has joined #auto 20:52:21 kaz has joined #auto 21:02:15 [ afternoon session starts ] 21:02:20 scribenick: kaz 21:02:58 topic: Privacy topics by Greg 21:03:19 -> @@@greg Vehicle Data Access 21:03:34 ted: BG does incubator work 21:03:48 .... WG focuses on standardization 21:04:59 ... have you sent your slides out to the ML? 21:05:12 greg: not yet. just for WebEx now 21:05:26 [slides broadcast in webex] 21:07:02 greg: would share some ideas with the group 21:07:12 ... about vehicle data access 21:08:05 ... [U.S. LEGISLATIVE AND REGULATORY CLIMATE] 21:08:28 ... federal trade commission group discusses vehicle communication 21:08:59 ... will continue discussion with wireless companies 21:09:17 ... national highway traffic sfety administration 21:09:33 ... impact for the need to additional vehicle data 21:09:44 junichi has joined #auto 21:09:49 ... copyright of the data, ownership 21:10:10 s/ownership/ownership of the data the vehicle produces/ 21:10:21 ... privacy aspect of the vehicle data 21:10:34 ... give the consumer choice 21:11:01 ... legislation 21:11:15 ... Senator Markey introduced 21:12:07 ... about the state lavel: Santa Clara in California, Rhode Island 21:12:28 ... AAA supporters there 21:12:52 ... don't expect opposition of wireless careers 21:13:12 ... size of the data influences 21:13:43 ... giving right information might cause danger for women 21:14:28 ... [ AAA's Consumer Rights for Car Data ] 21:14:42 ... transparency, Choice, Security 21:16:18 ... consumers have a right to expect that vehicle manufacturers and service providers will use reasonable measures 21:16:42 ... still lacking today is "Choice" 21:17:25 ... consumers have a right 21:18:14 ivan: regarding "Chice" 21:18:22 s/ted @@on risk and cost of recalls - postage on usb fobs alone.. good we have legislators pushing this industry/ted: on risk and cost of recalls - the postage alone on 1.4m usb fobs might be enough on financial balance sheet to sit on an upgrade so it is good to have pressure from legislatures on this industry/ 21:18:26 s/Chice/Choice/ 21:18:27 s/ted @@@ on modsec web server model/ted: are you familiar with apache modsec? i would prefer the ivi be a client only with no can bus access and api implemented on a web server model with rules spelling out who can access what - like the smartphone data access policy model mentioned earlier/ 21:18:58 ivan: you can make great reasons 21:19:10 ... but there is a sweet spot between us 21:19:40 ... data could be annonymized to be shared 21:19:52 greg: the consumer should have the choice 21:19:57 ... from 0 to some 21:20:23 ... the simplest term is that the API working 21:20:33 ... you choose to share the data 21:20:48 ... have transparency for the choice 21:21:12 ... one question is that auto manufacturers are the keepers at the moment 21:21:49 ... the date goes through auto manufacturers by default 21:21:58 ... but is that really the choice? 21:22:26 paul: the machine creates lots of the data, and the manufacturers created the vehicles 21:23:15 greg: is that really a choice of the user? 21:23:48 ... vehicles create the data and the manufacturers keep the data 21:24:02 ivan: e.g., edge computing 21:24:22 ... as for on-board computing 21:25:02 ... might be better to have another choice rather than sending all the data to the auto manufactures 21:25:34 ... may come down to legal 21:27:07 paul: more consumer choice driven 21:27:50 greg: for example, your car generates the data 21:28:41 paul: I might serve data to car manufacturers to create a better car 21:29:04 greg: understand that "Choice" is the most difficult one 21:29:25 ... [ OEMS: Consumer Privacy Protection Principles ] 21:29:35 s/OEMS/OEMs/ 21:29:56 ... automaker principles in Nov. 2014 21:30:20 ... transparency and security 21:30:28 ... FAQ mentions "Choice" 21:31:03 ... 7 automakers joined the discussion 21:31:18 ... agreement on the core princeple 21:31:28 ... but not a consensus so far 21:31:58 ... AAA thinks this an excellent first step 21:32:29 ... how the consumer has right choice? 21:33:08 -> http://www.autoalliance.org/automotiveprivacy Automotive Alliance 21:33:17 ... memorandum published recently 21:33:38 @@@link to the memorandum 21:33:56 ... [ Security Options? ] 21:34:49 ... automotive manufacturers would like restrict access 21:35:10 ... National Automotive Services TF 21:35:29 ... secure data release model 21:36:58 ... record to maintain 21:37:25 -> http://www.nastf.org/i4a/pages/index.cfm?pageid=3543 NASTF SDRM Faq - the spec itself requires a login to access 21:38:04 greg: bridge of security 21:39:12 greg: has different security levels of access 21:40:09 ... third party requests registration 21:40:46 ivan: if I was a consumer who accesses the data 21:41:10 ... there is a kind of friction 21:41:25 greg: balance on who should access which data 21:42:10 ... maybe different levels 21:42:22 ivan: go through very specific data 21:43:04 paul: very few people want to manage the data 21:43:47 ivan: could use fingerprinting to identify the data 21:44:00 ... physical security 21:44:44 ... the genetor 21:45:31 s/... the genetor/who accesses which data 21:45:39 s/who/... who/ 21:45:48 ... certifying agency? 21:46:49 ted: I may want to share my personal information with AAA 21:47:34 ... make sense to share the public key, the identifier key? 21:48:06 paul: trusted organization? 21:50:24 greg: should be discussed by the security TF? 21:51:06 paul: OEMs don't want to keep that kind of information which cost them 21:53:04 ... we need to address the availability based on user's preference 21:53:31 hira: user's privacy policy 21:54:06 ted: a registry may be a good model, it can be community and commercially maintained. it can store public keys, ensure third parties conform to security best practices (eg no-sslv3, specific ciphers) etc 21:54:23 paul: we didn't have this level of privacy preference 21:55:54 Presentation has joined #auto 21:55:59 kaz: should we have multiple level of choices?, e.g., driver/owner's personal preference and governmental instructions? 21:56:20 ivan: possibly 21:56:41 John_Schneider has joined #auto 21:57:59 paul: tomorrow we should have discussion on security&privacy 21:58:09 ... we have at least three guys 21:58:24 dave: discussions on security&privacy within W3C? 21:58:44 ... issues with mobile phones, etc. 21:59:12 ted: the group can decide if we want to define policy ourselves 21:59:59 ... but we don't have to do all by ourselves 22:01:30 dave: the possible "registry" equivalent to the one for mobile? 22:02:14 ted: could be one or more registries 22:03:37 greg: OEMs are painful with this model... 22:05:36 kaz: can understand the difficulty because the voice working group tried voice biometrics 5 years ago... 22:05:59 hira: there are groups working on privacy/security within W3C 22:06:07 http://www.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/ 22:06:19 http://www.w3.org/TR/2012/NOTE-app-privacy-bp-20120703/ 22:06:32 ... do you have intention to introduce your work to the Do Not Track group? 22:06:52 s/... do/greg: do/ 22:07:19 greg: no... 22:07:52 hira: user data tracking is mandatory (or at least important) to your business? 22:07:56 greg: yes, very helpful 22:08:05 ted: many options? 22:08:41 hira: some of us don't want to let people know where they are 22:09:03 s/many options?/with aaa, opting in to use cell phone tower information is a menu option before speaking with a dispatcher/ 22:09:13 greg: knowing where they're and getting information realtime is very useful 22:09:23 ... vehicle GPS as well 22:09:33 s/aaa/AAA/ 22:10:43 ted: being able to relay diagnostics data would be helpful too 22:14:25 s/OEMs are painful with this model.../OEMs are aware of this model.../ 22:18:11 usacase & concerns. I'll talk lator: https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=0 22:24:40 John_Schneider has joined #auto 22:26:02 i/usecase/topic: Hashimoto-san/ 22:26:29 junichi: first would talk about Firefox OS phone 22:26:50 ... Mozilla has developed a FirefoxOS-based phone 22:26:58 ... with full HTML5 environment 22:27:23 ... and security package written by me 22:28:00 ... certified APIs for security purposes 22:28:30 ... automotive vehicle APIs should also consider security layer 22:28:39 ... so would ask you all for opinions 22:29:19 paul: anybody can use APIs with Web runtime 22:30:14 ... how do you map web runtime APIs to OS level APIs 22:30:59 s/APIs/APIs?/ 22:31:26 ... e.g., geolocation APIs and speech APIs? 22:32:43 ... Markus from Mozilla gave similar questions 22:33:22 junichi: there is some procedure to certificate the contributed implementations 22:34:14 paul: any apps have to be authorized, that is OEMs' approach 22:34:31 junichi: all vehicle APIs should be safe 22:34:41 paul: what do you mean by "safe" 22:34:47 s/"/"?/ 22:35:51 ... OEMs look at that closely 22:36:22 ... anybody can develop any apps for automotive 22:36:59 ... but OEMs are keen to see if they're safe as apps for automotive 22:39:37 junichi: thought defining the scope of the security&privacy TF was important 22:39:55 ... but think we are almost finalizing the scope 22:42:38 kaz: before diving into the details, we should recognize there are at least three pieces for security discussion based on Paul's comment 22:43:43 ... 1. API spec itself, 2. implementation of the APIs (runtime), and 3. automotive apps using the APIs which work with the implemented runtime 22:44:39 ... please keep that in mind 22:45:25 junichi: ok 22:45:47 ... (continues the explanation on the contributions so far) 22:46:33 [ Proposed Collaborative Work Procedures for Security & Privacy ... ] 22:47:01 [ Proposed Procedure for Security & Privacy Consideration ] 22:47:13 rrsagent, draft minutes 22:47:13 I have made the request to generate http://www.w3.org/2015/07/28-auto-minutes.html kaz 22:47:32 junichi: would like to gather use cases 22:48:06 ... as broad as possible 22:48:58 ... (shows a google spreadsheet) 22:50:12 ... category | situation, use case | concern | reported by | 22:51:09 ... e.g., remotely unlock the door 22:51:49 ... at the time of the "last call" we should be going to have some requirements for security 22:54:05 ... during procedure 2, we should identify "in-scope use cases" and "out-of-scope use cases" 22:54:31 greg: are we duplicated existing work? 22:56:01 paul: what is the final deliverable? 22:56:22 s/final/main/ 22:56:47 junichi: the main deliverable is security requirements for the vehicle APIs 22:56:57 https://www.w3.org/auto/security/wiki/ASP_TF 22:57:30 chair has joined #auto 22:57:36 https://www.w3.org/auto/security/wiki/ASP_TF 22:59:57 kaz: I think Greg wanted to ask if we want to include existing use cases by e.g., ISO, FTC, in our use case list 23:00:15 ... or do we want to build the list from scratch? 23:00:44 ivan: maintain the quality of the data is also important 23:01:45 ... maintaining the quality should not violate the security/privacy 23:02:01 junichi: the balance is important 23:02:45 ... we can think about maintaining the quality and possible violation of security/privacy separately 23:02:50 ... and think about the balance later 23:03:27 ... we don't use the vehicle API to "control" automotive at least at the moment 23:04:03 ... we might want to use the date to analyze it and provide some service based on the data 23:04:20 ... but won't control the automotive itself 23:04:32 ivan: there is set capabilities 23:04:46 junichi: unlock is one example 23:05:10 ... some of us might think some use case is in-scope but some don't 23:05:39 greg: where/how to have the discussion on which should be included and which should not? 23:06:44 ivan: we'd have a big bucket of use cases 23:07:00 ... use cases themselves should be general ones 23:07:39 paul: there are three places to discuss use cases within the group 23:08:02 ... security consideration should be applied to all the use cases 23:08:27 ... they should be integrated 23:09:34 ... where is the easiest place to do that? 23:19:00 ... given people's availability in this f2f meeting, would be better to continue the detail of this (security/privacy tf) during tomorrow's breakout discussion 23:19:31 ... we should talk about how to handle general use cases, e.g., using Google Docs 23:19:55 ... also we should talk about testing 23:20:41 kaz: HTML5 testing infrastructure? 23:20:48 paul: would talk some more 23:21:13 john: e.g., need for 2 implementations 23:21:25 ted: general framework for spec testing 23:23:35 (some discussion of possible implementations) 23:25:13 paul: will put the plan for tomorrow together today 23:25:56 John_Schneider_ has joined #auto 23:26:02 hira: would talk about privacy work briefly 23:26:18 [ Overview of Privacy Protection Functionality ] 23:26:35 hira: based on ISO/IEC 29100 23:27:00 ... would brush up this picture based on our use cases 23:27:11 ... your comments are helpful 23:28:00 ... we have to prepare many choices 23:29:04 ... maybe hundreds of users share one car 23:31:12 ... existing privacy work: ISO/IEC 29100, OECD, EU, APEC, US, Japan 23:31:35 [ Section & Process of Privacy Breach ] 23:31:54 [ Proposed Procedure ] 23:32:07 hira: procedure for when/how to do 23:33:01 ... work with other related groups 23:34:30 ... to generate technical descriptions in the spec by the end of 2015 23:35:06 junichi: not 100% sure what kind of privacy descriptions should be included on privacy at the moment 23:35:29 ... Do Not Track is one the possiblity 23:35:45 paul: privacy aspect could be informative 23:36:16 ... how OEMs handle privacy elements could be mentioned 23:37:00 ivan: almost reactive part of the spec 23:38:36 ... like the car as use's extension 23:39:57 dan: is there any privacy API now? 23:43:21 kaz_ has joined #auto 23:43:51 ivan: seat setting but mirror setting, etc., could be also preset 23:45:15 scribenick: ted 23:45:51 john: presenting a bit on efficient xml interchange (EXI) 23:46:27 ... I was editor of that standard, my employer contributed the initial proposal after evaluating all the options availed 23:46:48 ... there was a question about json earlier today so added a slide on comparing that 23:47:22 ... efficiency - exhibiting a high rate of output for resources available 23:47:41 ... resourcing being disk space, bandwith, processing cycles, memory etc 23:48:01 ... it is possible to quantitate evaluating alternatives 23:48:27 ... why worry about efficiency? you have high costs to mitigate or limited resources 23:48:56 ... if you can do the same job with less cpu, lower capability radio, etc 23:48:59 -> http://www.w3.org/TR/exi-primer/ EXI Primer (might be useful to understand EXI) 23:49:28 ... this affects the bottom line, either initial manufacturing or ongoing cost like monthly bandwidth usage 23:49:42 rrsagent, draft minutes 23:49:42 I have made the request to generate http://www.w3.org/2015/07/28-auto-minutes.html kaz_ 23:49:54 ... EXI is something new. it is a different approach combining information and formal language theories 23:50:15 ... its goal is to combine and compact the data as much as possible 23:50:29 i/topic: Introduction/scribenick: kaz/ 23:50:30 rrsagent, draft minutes 23:50:30 I have made the request to generate http://www.w3.org/2015/07/28-auto-minutes.html kaz_ 23:50:36 ... we needed to condense information and exchange speed as much as possible 23:51:00 ... open web protocols are massive/overly verbose 23:51:11 ... we had to take a very different bit count specific approach 23:51:26 ... what are our design principles? we came up with 5 23:51:44 ... generality, performance, simplicity, efficiency, robust 23:51:58 ... we wanted to make xml competitive again 23:52:56 ... we see interest in various embedded systems which tend to not have much computing resources so needs to be performant (eg not consume too cpu cycles compressing) 23:53:19 ... to our knowledge this is the most efficent, compact way to exchange data today 23:54:32 ... it is 10x smaller than gzip compressing regular xml and 10x faster to parse/process 23:55:36 [chart showing asn1 compacting. exi consistently outperformed across all tests] 23:56:45 ... not all EXI implementations demonstrate the same compactness and speed, Agile Delta's is the most performant 23:58:12 ... with larger data sets it is even more pronounced when compared to compressed xml, it starts off 23x better and after 1MB you are 100x better 23:58:30 [EXI vs Fast Infoset] 23:58:50 ... we see about 20x performance over Fast Infoset 23:59:09 [EXI vs REST & JSON] 23:59:57 ... EXI is again dramatically better