<inserted> scribenick: kaz

Introduction

hira: Hirabayashi from KDDI

hashi: Hashimoto from KDDI

kaz: Kaz Ashimura from W3C working with Ted for the Automotive groups

urata: Urata from ACCESS

junichi: Junichi Sakamoto from AptPod

john: John Schneider from AgileDelta, Editor of EXI

ted: Ted Guild from W3C

dave: Dave Jensen from RoadRules

greg: Greg Brannon from AAA

paul: Paul Boyes form OpenCar

ivan: Adam from Nokia

Spec

paul: we have isses, e.g., refactoring APIs

<ted> Issues list

<ted> Issue 37, refactoring the API

paul: that's one of the big issues

greg: maybe we could quickly review the situation?

paul: (summarizes the group's activities)

<ted> Data Spec and Vehicle API FPWD

ted: (mentions the IRC channel is available at http://irc.w3.org/?channels=auto

paul: (shows the Automotive wiki)
... the spec split into to two pieces

-> https://www.w3.org/auto/wg/wiki/Main_Page WG wiki

-> http://rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html vehicle API spec (Editor's draft on rawgit)

-> http://www.w3.org/TR/#tr_Automotive published version of the specs

-> http://www.w3.org/TR/vehicle-information-api/ vehicle api fpwd

paul: defines access methods

-> http://www.w3.org/2015/07/vehicle-api.html vehicle api (snap shot version)

paul: can get information from the Web runtime

<ted> vehicle data spec snapshot

paul: there was discussion on zones
... availability of the data

<ted> [browser for meeting room projector had javascript disabled, breaking respec formatting hence snapshots]

greg: some auto maker may not provide information even if some of them is available?

paul: GENIVI, etc., did the basic work
... some data fallback might happen if the data is not available

<ted> paul provides some history on early input for the spec, how some elements are not exposed by different manufacturers, in different model cars etc

dave: the example codes provide good information

<ted> example in spec

dave: the signature of the apis
... get, set, subscribe, unsubscribe

greg: set for actuation?

paul: heater level, etc.
... that part has security issues, so started security&privacy TF
... largest topic (on "set") is security

dave: there is error interface as well

<ted> ivan: what identifiers do we have besides vin?

<ted> paul: world manufacturer id (wid)

<ted> Identification in the vehicle data spec (fpwd)

greg: identify the user as well?

ivan: applications might be very user-specific

<ted> ted: certainly some use cases - a car specific profile for different drivers that use it. seat, mirror position, preferred climate settings etc

ivan: potentially some users are interested in user-specific data

<ted> ivan: the vehicle/fleet owner might like to know things about how a given driver is behaving in the car

ivan: missing piece is identifying users
... user signature corresponding to seat, mirror settings

john: e.g., for 9.9 seat interface

-> http://www.w3.org/TR/vehicle-data/#seat-interface seat interface

paul: identifying users in the car

hira: The question is how we get user id.

<ted> Ways to identify a user - bluetooth device, pin, voice etc (Editor's draft snapshot)

paul: user identification interface
... action for somebody?
... we'll have a breakout tomorrow

greg: is there interface for locking?

ted: child, window and door lock status - read-only?

greg: somebody may want to have a interface to unlock the door remotely

dave: somebody commented on GitHub

<ted> s/child lock?/child, window and door lock status - read-only/

<ted> dave: some would prefer a verb instead of set function eg door.unlock instead of door.setLock(unlock)

<KevG> Hi guys, audio is still very faint are the microphones in the same room :-)

<KevG> Sounds like only one is working and its along way from Paul??

<KevG> Thanks, much appreciated...

<KevG> Possibly slightly

paul: Hirabayashi-san mentioned in Santa Clara before

john: cloud sourcing antilock problem?

<ted> [aggregate information for possible alerts like icing on part of a roadway]

john: do you have any information for antilocking?

<ted> Anti-lock braking

paul: (shows 9.2.1)
... related to geolocation information

ivan: granularity of geolocation information may be related to privacy issues

greg: additional use cases?

paul: up to the group
... would to see is having informative use cases
... why we need use identification, etc.
... another thing is the size of the information
... e.g., JSON is not necessarily compact
... compact format for low-level devices?
... would make the spec useful

hira: JSON is very heavy for general ITS purposes

john: EXI is 10 times compact than JSON
... faster and smaller
... we can save money by using compact format

-> http://www.w3.org/TR/exi/ EXI 1.0 spec (second edition)

paul: (look at the Abstract section of the vehicle API spec)

-> http://www.w3.org/TR/vehicle-information-api/#abstract Abstract

paul: need states of heater, etc.
... lots of data element which need states
... higher, medium, lower, etc.
... would see an extensible mechanism to manage states

greg: how to map the data spec to actual cars?
... has to have diverse set of mapping mechanism

<ted> JLR implementation evaluation presentation

greg: need to comply to specific regulations based on the location

ted: put a link to JLR's presentation

paul: (opens JLR's presentation)

<ted> 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

ivan: merging data of discussion within a car manufacturer internal, out sourcing, etc.

paul: spec review and JRL alignment
... JLR signal review and treatment

Kevin: PaulW did the review
... quite a lot of challenges for OEMs
... implementing the interfaces

paul: you can see some of the security concerns
... everyone wants the data like money

Kevin: vehicles have to be protected

greg: but don't think we need to talk about new access point within car
... head units are already installed in cars

Kevin: OEMs need to provide a mechanism to protect connected cars
... so that cars are not hackable
... hackers might be going to reverse-engineer the firmware
... need to protect multiple software during the long car lifetime

[ morning break ]

<ted> scribenick: ted

W3C IVI Exploitation Discussion

Presenter: Craig Smith from Theia Labs

Craig: we started with web and hardware penetration tests and security and have moved into cars
... i had a two hour long commute and wanted to modify my ivi system for other purposes
... this year has been pretty automotive specific. we run Open Garages to talk about cars, share modifications and research
... there is a balance between how much you can discuss before you get cease and desists
... i wrote the car hackers manual last year to go with a cyber-security class
... 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
... i have nda in place with some oem so i cannot say specifics on any given vehicles for instance

[slides attached to https://lists.w3.org/Archives/Public/public-auto-privacy-security/2015Jul/0016.html]

Craig: we'll pull an IVI system out of a vehicle, attach power supply and be able to examine it on test bench (desk)
... target update/upload mechanism - cd/dvd tray, usb, etc
... i look at jtag and sd cards as well
... the real goal is to get into the os
... once you are in the os you are common ground for general exploits (escallate to eg root privs)
... 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
... 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)
... they do not use encryption often, seldom no pki authentication
... lack of segregation of systems
... 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
... the OS itself usually doesn't have the usual hardening practices in place
... you are going after code execution. what vehicle controls you can get at, enough to steal it or just privacy/spying
... there are amplification attacks for example nfc from keyfobs. some people started keeping their keys in the freezer after that hit the news...
... 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
... you can sometimes simply grab a text file logging interesting evens that the oems feel they may want (or already send upstream to them)

greg: so you're saying oems are already sending data home?

craig: yes, in some cases. it can also just be last several hours so they can find out what was going on
... there are no retention policies in place
... stunt hacking - latest big example was the Jeep hacking story
... there is legislation pending for security experts limiting what they can do, requiring licensing etc
... clearly i'm against that

[craig describing his web based "fleet management"/botnet system]

craig: with a little bit of infrastructure you have something very scalable
... 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
... 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
... 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
... the buses tend to be interconnected
... you sometimes have to jump from one system to another
... the digital radio broadcast hack is perhaps more interesting than the jeep cherokee/sprint one
... you could send an exploit over a radio broadcast

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
... how do we go from where we are today to a more security vehicle? focus on attack vectors?

-> https://www.iamthecavalry.org/ I Am the Cavalry is working on exposing bad practices

craig: i am the cavalry is working together collaboratively, making observations on vulnerabilities, providing recommendations on better design, etc
... encourage oem to create responsible disclosure channels. we are acting as a clearing house between researchers discovering things and oems
... discovery acknowledgement is usually all people want
... evidence capture is an important use case, for accident forensics, proof of exploitation, etc
... over-the-air updates are essential
... 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
... risks and vulnerabilities will emerge and you need to be able to address them

[discussion of the bmw key issue and how they upgraded ota, disclosure from expert went through assistance of aaa of germany]

[similar to iamthecalvary tries to help in this arena]

craig: some are proponents of firewalls and encryption without looking at other concerns
... here i am not sure firewall approach would work. it just blocks one attack vector and i'll look at another
... you should have systems looking for anomolies

-> https://www.iamthecavalry.org/domains/automotive/5star/ 5 star security

craig: tesla is a great example with clear privacy policy, upgrades and responsible disclosure

dave: if you have segregation then ota upgrades can be problematic

craig: absolutely especially when you have air gaps. you have to do a chain of custody for upgrades, it is more work
... completely isolated systems are not a bad thing in some areas, attackers can't get at them either
... CAN buses are extremely efficient and well designed for their initial needs but lacking security design
... we are starting to see traditional can switch to ethernet+udp and then firewalling will make more sense

ivan: without speaking about specific vehicles, can you give us some stats or percentages, examples of complexity

craig: modern vehicles expose many attack vectors are a soft security core
... 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
... it is kind of bad right now
... [unminuted major oem] has just created a 50 person security team, which is pretty impressive since there are not that many auto security people
... retraining and acquiring people
... there is a scramble to solve the problem by throwing money at outsourced solutions and some of those systems are wholly insufficient
... even with all that energy they can miss one component
... 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

dan: do you do threat modeling?

craig: yes, going through the various channels
... it identifies what you should be focusing on
... i like to do threat boundaries based on distance - tpms is short range, cellular is open to the internet
... 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

dave: you mentioned some thoughts on privacy

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

greg: there is pressure for full disclosure on what they are collecting and what they are doing with it

craig: only one i'm aware of with good disclosure at the moment is tesla
... v2x is not just about sharing data but also being used for financial transactions

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

craig: it was interesting to see all the methods and data types spelled out as you have
... it is a higher and cleaner level of abstraction compared to what you typically have to do at a much lower level
... how it is implemented will be important

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

greg: many attackers would first focus would be on an api as a convenience before looking for lower level exploits

ted: and perhaps replace or bypass the shared library if on the same system

[comments on reverse engineering shared libs to learn bus dialects]

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
... i wouldn't be opposed to owner being able to clear their "black box" cache

ted: legally an individual does not have to incriminate themselves, their cars still can

[who owns the data?]

[discussion on policy and legislation]

<kaz> hira: thought some of the BG participants said that security issues are issues of implementations

<inserted> ... do you think we need discussion from the viewpoint of standardization?

craig: high level policies and legislation do not have enough details or teeth
... some can be more explicit and required like mandating over the air upgrade

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

<kaz> [ afternoon session starts ]

<kaz> scribenick: kaz

Privacy topics by Greg

-> @@@greg Vehicle Data Access

ted: BG does incubator work
... WG focuses on standardization
... have you sent your slides out to the ML?

greg: not yet. just for WebEx now

<ted> [slides broadcast in webex]

greg: would share some ideas with the group
... about vehicle data access
... [U.S. LEGISLATIVE AND REGULATORY CLIMATE]
... federal trade commission group discusses vehicle communication
... will continue discussion with wireless companies
... national highway traffic sfety administration
... impact for the need to additional vehicle data
... copyright of the data, ownership of the data the vehicle produces
... privacy aspect of the vehicle data
... give the consumer choice
... legislation
... Senator Markey introduced
... about the state lavel: Santa Clara in California, Rhode Island
... AAA supporters there
... don't expect opposition of wireless careers
... size of the data influences
... giving right information might cause danger for women
... [ AAA's Consumer Rights for Car Data ]
... transparency, Choice, Security
... consumers have a right to expect that vehicle manufacturers and service providers will use reasonable measures
... still lacking today is "Choice"
... consumers have a right

ivan: regarding "Choice"
... you can make great reasons
... but there is a sweet spot between us
... data could be annonymized to be shared

greg: the consumer should have the choice
... from 0 to some
... the simplest term is that the API working
... you choose to share the data
... have transparency for the choice
... one question is that auto manufacturers are the keepers at the moment
... the date goes through auto manufacturers by default
... but is that really the choice?

paul: the machine creates lots of the data, and the manufacturers created the vehicles

greg: is that really a choice of the user?
... vehicles create the data and the manufacturers keep the data

ivan: e.g., edge computing
... as for on-board computing
... might be better to have another choice rather than sending all the data to the auto manufactures
... may come down to legal

paul: more consumer choice driven

greg: for example, your car generates the data

paul: I might serve data to car manufacturers to create a better car

greg: understand that "Choice" is the most difficult one
... [ OEMs: Consumer Privacy Protection Principles ]
... automaker principles in Nov. 2014
... transparency and security
... FAQ mentions "Choice"
... 7 automakers joined the discussion
... agreement on the core princeple
... but not a consensus so far
... AAA thinks this an excellent first step
... how the consumer has right choice?

<ted> Automotive Alliance

greg: memorandum published recently

@@@link to the memorandum

scribe: [ Security Options? ]
... automotive manufacturers would like restrict access
... National Automotive Services TF
... secure data release model
... record to maintain

<ted> NASTF SDRM Faq - the spec itself requires a login to access

greg: bridge of security
... has different security levels of access
... third party requests registration

ivan: if I was a consumer who accesses the data
... there is a kind of friction

greg: balance on who should access which data
... maybe different levels

ivan: go through very specific data

paul: very few people want to manage the data

ivan: could use fingerprinting to identify the data
... physical security
... who accesses which data
... certifying agency?

ted: I may want to share my personal information with AAA
... make sense to share the public key, the identifier key?

paul: trusted organization?

greg: should be discussed by the security TF?

paul: OEMs don't want to keep that kind of information which cost them
... we need to address the availability based on user's preference

hira: user's privacy policy

<ted> 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

paul: we didn't have this level of privacy preference

kaz: should we have multiple level of choices?, e.g., driver/owner's personal preference and governmental instructions?

ivan: possibly

paul: tomorrow we should have discussion on security&privacy
... we have at least three guys

dave: discussions on security&privacy within W3C?
... issues with mobile phones, etc.

ted: the group can decide if we want to define policy ourselves
... but we don't have to do all by ourselves

dave: the possible "registry" equivalent to the one for mobile?

ted: could be one or more registries

greg: OEMs are aware of this model...

kaz: can understand the difficulty because the voice working group tried voice biometrics 5 years ago...

hira: there are groups working on privacy/security within W3C

<John_Schneider> http://www.w3.org/TR/2010/NOTE-dap-privacy-reqs-20100629/

<John_Schneider> http://www.w3.org/TR/2012/NOTE-app-privacy-bp-20120703/

greg: do you have intention to introduce your work to the Do Not Track group?
... no...

hira: user data tracking is mandatory (or at least important) to your business?

greg: yes, very helpful

ted: with AAA, opting in to use cell phone tower information is a menu option before speaking with a dispatcher

hira: some of us don't want to let people know where they are

greg: knowing where they're and getting information realtime is very useful
... vehicle GPS as well

<ted> ted: being able to relay diagnostics data would be helpful too

<junichi> usacase & concerns. I'll talk lator: https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=0

i/usecase/topic: Hashimoto-san/

junichi: first would talk about Firefox OS phone
... Mozilla has developed a FirefoxOS-based phone
... with full HTML5 environment
... and security package written by me
... certified APIs for security purposes
... automotive vehicle APIs should also consider security layer
... so would ask you all for opinions

paul: anybody can use APIs with Web runtime
... how do you map web runtime APIs to OS level APIs?
... e.g., geolocation APIs and speech APIs?
... Markus from Mozilla gave similar questions

junichi: there is some procedure to certificate the contributed implementations

paul: any apps have to be authorized, that is OEMs' approach

junichi: all vehicle APIs should be safe

paul: what do you mean by "safe"?
... OEMs look at that closely
... anybody can develop any apps for automotive
... but OEMs are keen to see if they're safe as apps for automotive

junichi: thought defining the scope of the security&privacy TF was important
... but think we are almost finalizing the scope

kaz: before diving into the details, we should recognize there are at least three pieces for security discussion based on Paul's comment
... 1. API spec itself, 2. implementation of the APIs (runtime), and 3. automotive apps using the APIs which work with the implemented runtime
... please keep that in mind

junichi: ok

<scribe> ... (continues the explanation on the contributions so far)

[ Proposed Collaborative Work Procedures for Security & Privacy ... ]

[ Proposed Procedure for Security & Privacy Consideration ]

junichi: would like to gather use cases
... as broad as possible
... (shows a google spreadsheet)
... category | situation, use case | concern | reported by |
... e.g., remotely unlock the door
... at the time of the "last call" we should be going to have some requirements for security
... during procedure 2, we should identify "in-scope use cases" and "out-of-scope use cases"

greg: are we duplicated existing work?

paul: what is the main deliverable?

junichi: the main deliverable is security requirements for the vehicle APIs

<junichi> https://www.w3.org/auto/security/wiki/ASP_TF

<junichi> https://www.w3.org/auto/security/wiki/ASP_TF

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
... or do we want to build the list from scratch?

ivan: maintain the quality of the data is also important
... maintaining the quality should not violate the security/privacy

junichi: the balance is important
... we can think about maintaining the quality and possible violation of security/privacy separately
... and think about the balance later
... we don't use the vehicle API to "control" automotive at least at the moment
... we might want to use the date to analyze it and provide some service based on the data
... but won't control the automotive itself

ivan: there is set capabilities

junichi: unlock is one example
... some of us might think some use case is in-scope but some don't

greg: where/how to have the discussion on which should be included and which should not?

ivan: we'd have a big bucket of use cases
... use cases themselves should be general ones

paul: there are three places to discuss use cases within the group
... security consideration should be applied to all the use cases
... they should be integrated
... where is the easiest place to do that?
... 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
... we should talk about how to handle general use cases, e.g., using Google Docs
... also we should talk about testing

kaz: HTML5 testing infrastructure?

paul: would talk some more

john: e.g., need for 2 implementations

ted: general framework for spec testing

(some discussion of possible implementations)

paul: will put the plan for tomorrow together today

hira: would talk about privacy work briefly

[ Overview of Privacy Protection Functionality ]

hira: based on ISO/IEC 29100
... would brush up this picture based on our use cases
... your comments are helpful
... we have to prepare many choices
... maybe hundreds of users share one car
... existing privacy work: ISO/IEC 29100, OECD, EU, APEC, US, Japan

[ Section & Process of Privacy Breach ]

[ Proposed Procedure ]

hira: procedure for when/how to do
... work with other related groups
... to generate technical descriptions in the spec by the end of 2015

junichi: not 100% sure what kind of privacy descriptions should be included on privacy at the moment
... Do Not Track is one the possiblity

paul: privacy aspect could be informative
... how OEMs handle privacy elements could be mentioned

ivan: almost reactive part of the spec
... like the car as use's extension

dan: is there any privacy API now?

<kaz_> ivan: seat setting but mirror setting, etc., could be also preset

<ted> scribenick: ted

john: presenting a bit on efficient xml interchange (EXI)
... I was editor of that standard, my employer contributed the initial proposal after evaluating all the options availed
... there was a question about json earlier today so added a slide on comparing that
... efficiency - exhibiting a high rate of output for resources available
... resourcing being disk space, bandwith, processing cycles, memory etc
... it is possible to quantitate evaluating alternatives
... why worry about efficiency? you have high costs to mitigate or limited resources
... if you can do the same job with less cpu, lower capability radio, etc

<kaz_> EXI Primer (might be useful to understand EXI)

john: this affects the bottom line, either initial manufacturing or ongoing cost like monthly bandwidth usage
... EXI is something new. it is a different approach combining information and formal language theories
... its goal is to combine and compact the data as much as possible

This is scribe.perl Revision: 1.140  of Date: 2014-11-06 18:16:30  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Jensen/Jensen from RoadRules/
Succeeded: s/topic/topic (on "set")/
Succeeded: s/adam: identification?//
Succeeded: s/Identification/Identification in the vehicle data spec (fpwd)/
Succeeded: s/vehicle manufacturer id/world manufacturer id (wid)/
Succeeded: s/etc/etc (Editor's draft snapshot)/
Succeeded: s/lock/lock for doors/
FAILED: s/child lock?/child, window and door lock status - read-only/
Succeeded: s/ ... what's the method?/hira: The question is how we get user id./
Succeeded: s/child lock for doors/child, window and door lock status - read-only/
Succeeded: s/interlock/antilock/
Succeeded: s/Charter/Abstract section of the vehicle API spec/
Succeeded: s/a mechanism/an extensible mechanism/
Succeeded: s/... need/greg: need/
Succeeded: s/AdamC:/Kevin:/
Succeeded: s/protect cars/protect connected cars/
Succeeded: s/adam:/ivan:/g
Succeeded: s/can buses/CAN buses/
Succeeded: s/... do you think we need discussion from the viewpoint of standardization?//
Succeeded: i/high level/... do you think we need discussion from the viewpoint of standardization?
Succeeded: s/ownership/ownership of the data the vehicle produces/
Succeeded: 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/
Succeeded: s/Chice/Choice/
Succeeded: 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/
Succeeded: s/OEMS/OEMs/
Succeeded: s/... the genetor/who accesses which data/
Succeeded: s/who/... who/
Succeeded: s/... do/greg: do/
Succeeded: s/many options?/with aaa, opting in to use cell phone tower information is a menu option before speaking with a dispatcher/
Succeeded: s/aaa/AAA/
Succeeded: s/OEMs are painful with this model.../OEMs are aware of this model.../
FAILED: i/usecase/topic: Hashimoto-san
Succeeded: s/APIs/APIs?/
Succeeded: s/"/"?/
Succeeded: s/final/main/
Succeeded: i/topic: Introduction/scribenick: kaz
Found ScribeNick: kaz
Found ScribeNick: ted
Found ScribeNick: kaz
Found ScribeNick: ted
Inferring Scribes: kaz, ted
Scribes: kaz, ted
ScribeNicks: kaz, ted
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] Paul_Boyes(OpenCar) Adam_Abramski Adam_Crofts(JLR)[remote] Greg_Smith(Theia_Labs) Ivan_Sucharski(Here)

WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting

Got date from IRC log name: 28 Jul 2015
Guessing minutes URL: http://www.w3.org/2015/07/28-auto-minutes.html
People with action items: