[Day1 - 28 July 2015]
<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: What are OEM data retention plicies? Are you saying they are already sending all vehicle data back to their servers?
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
craig: 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
... size of the data influences
... [ 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 data 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"
... 17 automakers signed the MOU
... 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/
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
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 PII in the spec 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
<inserted> scribenick: ted
[EXI vs gzipped BSON, CBOR]
scribe: still smaller across the
board
... EXI is not compression
... when people share data they use a standard api to produce
xml or json and might compress before sending to other
system
... EXI writes an EXI binary stream instead of XML
... it does not require XML
... but it can fit underneath an xml library
[slide listing the multitude of XML definitions - eg RDF, SVG...]
[all the XML based implementations]
scribe: XML aware applications
tend to produce a representation of the XML (SAX or DOM) and
not the XML itself
... you can develop and test in pure XML and then switch to EXI
after
... adoption wise: we are in 400k automobiles in the U.S. and
expanding
... it is being used for smart energy (appliances and power
meters)
... it is being used for digital radios used by emergency
responders
... gaming industry
... IoT, W3C, V2G (vehicle to grid for electric vehicles), US
DOD and intelligence communities have adopted it
[list of better known customers]
scribe: banking and finance
... VW Car-Net uses it
... this is used in fighter aircraft for both internal
communication on the bus and external
... it is being flight tested in F22 and F35
dave: how long has the spec been around?
john: 2011 for the first edition recommendation. it second edition Rec in 2014
<kaz_> EXI first edition
junichi: how about error detection?
<kaz_> EXI second edition
john: that is in a different layer of the stack as is encryption and security
dan: you mentioned how much more efficient Agile Delta's system is, how does that compare to others?
john: ours was the reference
implementation
... not a fair comparison since we had several years head
start
... i would say 6-5 times faster and maybe 2-6 times smaller
dave: are there many implementations?
paul lists 4 from w3c site
john: cisco, arch, seimens. some private implementations
dave: i'm not seeing python libraries for example
john: it is not widely known. we have a high ratio of engineers to marketers
<kaz_> publicly available EXI implementations
ivan: people are also becoming
lazier with efficiency and throw more hardware at
solutions
... that is going to be needed in IoT
john: those who know about it generally adopt it
ted: so as it applies to our json based spec... when there is need to not interact with the user but send large volumes of data an app using the json api can collect and package up in exi before streaming out
dave: it makes more sense to use json for browser interfaces
john: very true but when you are paying for bandwidth you need to be as compact as possible
<inserted> kaz: there is discussion on EXI within the WoT IG as well, so maybe it would make sense to have joint discussion with them, e.g., during TPAC 2015 in Sapporo
shinjiro: can you convery back to xml?
john: yes, it is called transcoding
ivan: what about open source data stream sniffers?
john: yes you can put a plugin into wireshark for example to see xml extraction
<kaz_> [ think EXI Primer http://www.w3.org/TR/exi-primer/ is a good starting point to know EXI ]
[Day2 - 29 July 2015]
<kaz_> scribenick: kaz_
Use Case Mechanism/Infrastructure
Breakouts
- Use Case
-- Categorization
--- Security
--- Privacy
--- Remote Access
--- Higher Level Functionality
--- Identification
-- Testing
2pm
- Presentations
--- OpenCar
--- AptPod
wonsuk: from ETRI
<junichi> use case spreadsheet: https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=867261678
day2_attendees: Dan, Paul, Greg, Ted, Wonsuk, Sakamoto, Ivan, Urata, Kaz, Hashimoto, Hirabayashi
<Ivan> I have arrived
<paul> https://klg.webex.com/klg/j.php?MTID=m3533658821a3b35ae42e5e77fcf43553
<paul> Meeting number: 731 650 244 Meeting password: Web729
<kaz> scribenick: kaz
<paul> http://www.w3.org/auto/wg/wiki/Use_Cases
<ted> https://www.w3.org/auto/security/wiki/Use_Cases
<paul> https://www.w3.org/auto/security/wiki/Use_Cases
paul: spreadsheet put together by
Hashimoto-san
... and Use Case Wiki by Qing An
... Security Use Case Wiki by Kevin
(quick review by each)
-> https://www.w3.org/auto/security/wiki/Use_Cases Kevin's Security Use Cases
paul: what do we do on
ADAS?
... security issue is authentication
-> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=867261678 spreadsheet on "Use Cases and Concerns"
paul: the spec doesn't cover
logging
... another point is performance
... what do you do for frequent fresh rate?
... also register items for logging?
greg: frequency of ADAS information activation?
dan: would be helpful to capture some high level use cases
paul: would be great to capture
high level use cases like logging ADAS information
... this looks like V2X thing
ivan: does the spec have a space
for future systems?
... robust to system-wide
paul: can you generalize
operations?
... identifying data
... could be a separate interface
ted: no. 6 from the spreadsheet vs. use case 4 from Kevin's wiki
junichi: we don't have to merge all the use cases during the meeting today
ted: require data sharing stated
by governmental/federal instructions
... vs. sharing data with friends
hira: the point I think is granularity of the data
ted: people might be interested
in average speed
... more efficient driving
paul: we should capture high level use cases first
hira: after that we should prioritize the use cases, etc.
paul: the goal is identifying use
cases which are influential to our specs
... from the viewpoint of security and privacy
... our focus is the specs
kaz: btw, it would be better to have an ID (or URL link to the original wiki-based use case description) within the spreadsheet to identify each use case described on the wiki pages
paul: No. 25: driver would like to remotely start vehicle...
(Adam joins)
paul: discussing high level use
cases
... to identify the priority
... auto maker's applications have complete access to all the
data
... 3rd party applications just have access to part of the
data
greg: automaker has concerns
around impact compliance with emissions regulations due to 3rd
party access
... security concern is giving direct access to vehicle
control
paul: meaning accessing a server
rather than directly accessing the vehicle?
... (updated the spreadsheet based on the discussion)
wonsuk: smart things, a venture
company, provides a cloud-based mechanism to control smart home
devices
... the cloud service can make decision on who can access
what
kaz: in that case, the cloud service has authentication capability like fingerprinting?
wonsuk: not 100% sure
... but should have some mechanism for security
... could be fingerprinting plus passwords for payment
service
paul: if HTML5-based headunit use JavaScript to send the data to the cloud server, the speed might be problematic
kaz: Sakamoto-san's demonstration in the afternoon is related to this problem
[ morning break ]
-> https://docs.google.com/spreadsheets/d/14ij-2I-H4HbilVQ_muCmUayVqmVfdbkoke690MA0kdo/edit#gid=0 high level use case spreadsheet
<ted> scribenick: ted
[discussion recalling use cases from Bart @@@ of the Netherlands, emergency responders wanting to know locations of and/or ability to disabled air bags]
http://www.w3.org/2015/07/vehicle-data#idl-def-AirbagStatus
paul: this use case exercise will also be useful in discovering omissions in data spec
ivan: the data polling frequency is extensive
paul: some like traction control
systems and oil pressure you want to know immediately
... it is also possible to have a bad data reading and those
should be discarded
... there is monitoring for events which requires storing
values and computing to calculate changes
... subscribing is polling for all data and determining when an
event happens. separately we want a better event listener
dan: desire for a callback function
wonsuk: there are different
approaches including callback. if the event happens we would
want a handler
... it is less expensive than polling
paul: we might want to add that to the spec
wonsuk: in case of battery
status, you want to see the value changes and not a specific
event
... we have a subscription methodology, we will need to
investigate others
kaz: we may want to have an extended version of subscribe which notices a significant change from previous poll
ted: i agree a listener would be
advantageous and less expensive to developer but that requires
processing upstream to trigger event. will oem do?
... i suspect many won't so i like extending subscription,
cache of previous value, delta to consider change significant
enough to act like a trigger and polling frequency to reduce
cost when we are ok with checking every 10min instead of
10ms
<urata_access> https://github.com/w3c/automotive/issues/29
<urata_access> we did similar discussion recently.
greg: oem is not necessarily going to do the processing themselves or if they do willing to share
shinjiro: we already added
duration to the subscribe method
... we did not want to overly complicate the interface
... i understand how setting a threshold would be useful as
well
... we leave that to implementation specific solutions
... in case where battery is draining or tire wear increasing,
people might want to be notified of delta event for a specific
number
... event listener effectively deprecates subscribe and feel we
should keep with a simpler subscription function
kaz: are you opposed then to extending subscription further?
shinjiro: it is possible. kevron lobbied to keep the interface simple and i feel the same way
dan: if you pass a callback function, your specific logic could reside there
paul: you need two data elements, actual battery voltage and battery status is low
greg: if that low status level is an agreed threshold
dan: passing your threshold value and callback function is what i had in mind, it could be an average or current value
ivan: just send the data to the
callback function and leave the logic to them
... illustrated examples would be helpful
paul: are examples best within the spec or as a standalone document?
ted: concise examples should be included directly, collection of complex ones potentially split out and perhaps even published to an open repo where we can encourage their use and contributions
dan: i can see wanting a cloud based service or in car app running in the background detect the car is parked, it has started raining and closes the windows
paul: we went free form but we
need to think about prioritization, which are candidates for
further expansion etc
... which are out of scope for our specs
... spec was developed for on-board/in-car apps not external
services although that is possible
dan: or a hybrid where data triggered by an event goes to an external service for evaluation, reporting and may send instruction back
[pause for lunch]
paul suggests we review the use cases together to see if they make sense
greg: it would be good in doing so to make clear to the security&privacy tf how they should work on them
paul: yes, first pass should be
if they are things we definitely can expose through the api,
priority, how to expand them
... we do not need to go full uml on them
... genivi tends to do quite a bit of use case mapping and it
can be useful. you should be able to write test cases based on
these
... end goal is to turn these into requirements for testing the
spec
paul reads first one on wiping personal data on rental car
ted: it can perhaps be expanded to any shared vehicle situation, like borrowing a friend's car
dan: true but there may be some differences so maybe better to list separately
http://www.w3.org/2015/07/vehicle-data#personalization-interfaces
dan: clear contact information
paul: we don't do anything there
ted: could be something for the bg to take up because it certainly can be useful for apps to be able to access that
paul: this one can be expanded
certainly
... i imagine the web runtime will not be active when the
vehicle is off but cannot say that definitively, some may want
to keep some background, low power capabilities
ted: there could be a signal sent (oem specific) to wake from suspend mode after which things can be queried
<kaz> kaz: in that case, we need to identify the state/mode of the car and the web runtime
<kaz> ... so we need some mechanism to manage the state and mode
(regarding wake-up signal)
kaz, we should perhaps raise this as an issue in gh
<kaz> yeah
<Dan> We may want to consider not only the mode of the car, but also the mode of the app. There may be things you want to allow the app to do in the background vs. foreground.
<kaz_> ISSUE: for remote controle and wake-up signal, we may need some mechanism to identify the state and the mode of the car, the web runtime and the application
<trackbot> Created ISSUE-1 - For remote controle and wake-up signal, we may need some mechanism to identify the state and the mode of the car, the web runtime and the application. Please complete additional details at <http://www.w3.org/auto/wg/track/issues/1/edit>.
<urata_access> off the topic. You may already but I found Genivi's vehicle web api reference implementation document. I though this might be good example for Testing Framework discussion because it mentions about data simulator and some test cases.
<urata_access> http://git.projects.genivi.org/?p=web-api-vehicle.git;a=blob_plain;f=doc/WebAPIforVehicleDataRI.pdf;hb=HEAD
junichi: we are looking at
resource limits on vehicle and volume of data being
processed
... logging parts to cloud. some want real-time
monitoring
... it is necessary to monitor some sensitive data at least
once a second
... we are providing on-board terminal, user interface and
server side systems
... sever system is able to perform more calculations across
specific and aggregate vehicle information
[review of project cycle - research, prototyping, inspection for mass production, mass production, improvement]
junichi: measurement to vehicle
manufacturers, improve data workflow, ability to reproduce bugs
and evaluate data
... it can be significantly easier to update cars than issue
costly recalls to fix bugs
... there are several r&d teams at different organizations
that are willing to share data
ivan: for reproducing bugs are you recording enough data to be able to reproduce the environment?
junichi: yes
[slide diagram of M2M architecture]
[slide on terminal system]
junichi: this system includes
gps, 3g modules
... we used a usb-can transceiver circuit with read-only
capabilities
... send function was disabled
[data filtering on terminal system]
junichi: we do filtering, re-sampling and data packaging
ivan: what do you mean by re-sampling?
junichi: combining like
data
... and sampling different parameters at different
intervals
[html5 ui]
junichi: you can drag and drop items onto your dashboard. it also can show graph data over time
[demo starts]
junichi: you can drag and drop from list various parameters you want to keep track of
[discussion of local data storage capability and deferred upload when network connectivity is interrupted]
steve: following this remotely you would see it as delayed then?
junichi: correct
paul: what is the main use of this is for oems, to verify their design?
junichi: our system is for gathering real time data. there are separate tools for analysis
paul: do you use other devices other than vtc-100 with the can transceiver or are there other ways you can collect?
junichi: just the vtc-100
shinjiro: what sort of typical time delay for following?
junichi: 10ms, usually worst is 1s
paul: you can guarantee the network?
[laughter]
junichi: i cannot guarantee the
network
... we tried this Nürburgring, at a large test track in
germany, with mountains obstructing cell signal
... we reduce the size of the packets to be transmitted as
small as possible so we can get the payload out when we can,
efficiently
greg: how are you securing the transmission?
junichi: https and device
certification
... right now we are providing the cloud portion of the service
but it can be an organization's private cloud
steve: this is being used when
oem is testing vehicles
... are there any wanting to deploy this is production vehicles
for real world data sampling?
junichi: yes. many are already
doing telematics data gathering
... but typically their data sampling rate is too low
... server is able to detect some dangerous situations and
report back to the user
paul: this seems like an area vector might be interested in
junichi: they are partnering
steve: the exi discussion yesterday from AgileDelta seems pertinent
ivan: did you create the interfaces yourself?
junichi: yes and all in
html5
... we are using binary data format
shinjiro: which, something like exi?
junichi: no, proprietary
steve: i'll review our
architecture in brief and security considerations
... we went through an outside review and certification
... we are a html5 solution. this application framework shows
the different levels, web runtime, localhost capabilities
[slide of all the components]
steve: we isolate all the
different layers and applications, similarly control all
connectivity in and out
... we need to make sure everything is coming from our system,
going through our gateway
... the browser runtime only talks to our local server
... the host layer handles all external connections
[diagram on connectivity]
steve: we make use of html5 web
workers
... actually we have several different models but in this
diagram it is web workers and iframe
... iframe is separated at dom level. we isolate with content
security policy (csp)
... the applications are only allowed to communicate through a
message pipe
... we keep the message communication constrained
... gateway, rest server, logic layer that restricts specific
data access permisssions
... what sorts of concerns are you hearing? what security
issues are you hearing?
dan: we are defining parties and what data they can get at. most things are explicitly read only
steve: we have two ways of
addressing that in our system. anything going into the car is
certified and embedded
... we have policies on which information is accessible to
specific applications. we also generally expose things for read
access
dan: who grants permissions for applications?
steve: the publisher includes in their package manifest what they are seeking access to
hashimoto: how do you handle the app install?
steve: package is download, checksums verified and then installed to run locally
hashimoto: it sounds similar to firefox os model
<inserted> scribenick: kaz_
kaz: question about the interface between the integration layer and component modules via websocket
steve: @@@
paul: explains OpenCar's downloadable version of SDK
steve: separation of HMI and app
logic
... security concerns with downloadable apps?
ivan: you could send data to the headunit to open the door
steve: you need to have
separation mechanism
... something has to say I have a permission
hira: how do you protect apps to be peeped?
steve: using a sandbox container
is one level
... construct a barrier is another
... application should have access to various resources
... certified permission only allow components to access some
specific information
paul: also signed application
steve: this kind of mechanism is common with any downloadable apps
paul: permission from web runtime is not directly tied with the OS
steve: some constraint for
integration
... desire to allow JS codes to access low-level information is
not a good idea
(thanks from all to Steve)
[ afternoon break ]
paul: we did much discussion on
use cases during this f2f meeting
... some same people should overview all the use cases
... I will overview them
... some others should also review them
... issues should be tracked on GitHub
... will do my review this week
... Hashimoto-san should also do the review as the
Security&Privacy TF moderator
... what about Wonsuk as one of the Editors
wonsuk: we need to describe our
use cases more clearly
... also we need to describe our requirements
... and then we can get feedback from others
... should we add descriptions to the wiki?
paul: we got high level use case descriptions
ted: we can continue to use Google Docs for a while
paul: does that make sense?
wonsuk: yeah
paul: at some point we should be
able to say "this is our scope"
... would say less than one month
dan: what is the criteria for prioritization?
paul: have some idea, put it on
the wiki, and have discussion
... we have two meetings
... August
... Asia friendly one and Europe friendly one
... Aug. 4 one is in the morning in Asia
wonsuk: can't make it
paul: should be better to make 1
hour later?
... does the security&privacy tf have regular calls?
hashimoto: no
... holding email discussions
paul: next Tuesday we'll talk
about use cases
... if you guys (security&privacy tf) can talk with each
other beforehand, would be good
... can talk about prioritization
... have a lit of topics
... will send it to the group
<scribe> ACTION: Paul to send out the list of topics based on the f2f discussion to the group [recorded in http://www.w3.org/2015/07/29-auto-minutes.html#action01]
<trackbot> Created ACTION-9 - Send out the list of topics based on the f2f discussion to the group [on Paul Boyes - due 2015-08-05].
paul: will talk about ISSUE-37 as
well
... can you lead the discussion, Wonsuk?
... you can respond to the GitHub issue 37
... got no response from TAG yet
wonsuk: pros/cons of each method
paul: Urata-san also should be
involved
... that's pretty much what I remember
kaz: wanted to double check the
Aug. 4 slot
... 5pm Pacific?
paul: yes
... will send an announcement to the group
kaz: another topic I wanted to mention was demo showcase during TPAC 2015 in Sapporo
ted: should forward the announcement to the group list
kaz: ok, maybe the Member list
hira: question on user identification
paul: have a list of issues
including that
... will send a message to the group
... we can add issues on GitHub
... probably 5-6 issues
hira: ok
greg: onborad vs offboard
ivan: electric vehicle and hybrid
vehicle?
... just curious
greg: in the battery section
ted: trying to get those automakers as well
paul: can we invite them to one of our meetings?
(some discussion on related stakeholders)
paul: maybe you (those don't
participate in the WG yet) can join the BG as well
... next f2f meeting on Monday/Tuesday (Oct. 26/27) in
Sapporo
ted: tx to Paul and OpenCar :)