See also: IRC log
<inserted> scribenick: kaz
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
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
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
-> @@@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:[End of scribe.perl diagnostic output]