<ted> [agenda review]
<ted> scribenick: ted
Shinjiro Urata, Access
Junichi Hashimoto, KDDI
Tatsuhiko Hirabayashi, KDDI
Kazuyuki Ashimura, W3C
Adam Abramski, Intel
Paul Boyes, OpenCar
Yingying Chen, W3C
Qing An, Alibaba
Kevin Gavigan, JLR
Adam Crofts, JLR
Peter Winzell, Mitsubishi
Ted Guild, W3C
Wonsuk Lee, ETRI
Daisuke Ajitomi, Toshiba
Hidenobu Ito, Fujitsu
@@3_second_row_names
Adam: review spec process,
timeline check, what needs to be done
... if it is interesting to the group give a summary of the BG
meeting and presentation Paul, Ted and I made at Genivi AMM
session
... implementations and testing (both required by the
specs)
... Generic Sensor API with Tobie Langel
... Security, possibly engage with some WoT folks this or
tomorrow afternoon
<kaz> Toru_Kawaguchi(Panasonic), Mikio_Sasaki(Mitsubishi_Electric), Jet_Villegas(Mozilla), Hiroto_Inoshita(Keio_Univ.), J_Alan_Bird(W3C)
Adam: tomorrow morning is pretty
busy with breakout session starting with Web Payments in room
206 (2nd floor)
... after we will liaise with Geolocation back in this
room
... both sessions have detailed agenda [on screen and in email
archives]
... after lunch meeting with TV Control API CG who is working
with us on Media Tuner API (BG activity) and avoid duplicating
work
Paul: we have had a flurry of
activity, reviewing and resolving issues
... although there are still some outstanding issues it is
quieting down
... we need to move on our timeline toward REC
... we are required to have at least two implementations to
advance in W3C specification status
<kaz> ted: explains how to use the W3C Github repository, and ask if we could remove the master branch and use the gh-pages branch for spec publication
-> https://lists.w3.org/Archives/Public/public-automotive/2015Oct/0003.html Proposal to switch to gh-pages branch for Echidna
RESOLUTION: editors and chairs agree to accept proposal to switch to gh-pages for automated publishing
Paul asks JLR about implementation status
Adam and Kevin will get confirmation from Paul Wheller before sharing
Paul: about the infamous issue 32, in spite of the back and form I believe the current status is to stay as is due to existing [partial] implementations
Wonsuk: we left it for now but
wanted to discuss with Tobie and GeoLocation WG to get their
advice which we can do this week as part of our breakout
sessions
... we can also defer until a later stage in the recommendation
process (as it tends to get more attention and review then)
Paul: there are a few outstanding issues
Adam: one is contingent on issue 32 refactoring
https://github.com/w3c/automotive/issues/56
action ted to close issue 56 as out of scope/not relevant to our WG based on conversations/understanding from JLR and Volvo at Genivi
<trackbot> Created ACTION-10 - Close issue 56 as out of scope/not relevant to our wg based on conversations/understanding from jlr and volvo at genivi [on Ted Guild - due 2015-11-02].
[based on JLR RVI proposal and Gunnar explanation of where in the stack offline/wakeup interactions will take place - outside of web runtime]
Adam: one of the reference implementations we hope to get is from Genivi in their stack. Paul, Ted and I are working with them to get commitment and timeline
Paul: it might be helpful to explain what Genivi is to some in the room
Adam: Genivi is comprised of 180 or so organizations, OEM, tier 1, silicon etc
<hira> http://www.linuxplumbersconf.org/2014/ocw/sessions/2559
Adam: they are working together on creating a code stack, much of which is open source, on many aspects of connected vehicle
Adam: they have been coordinating
with W3C extensively and overlap of members between the
different consortia
... we have been colocating our business group meetings with
their all member meeting and did so last week in Seoul
Wonsuk: who is leading that implementation? I see a mix of different companies and outside contributors
Paul: from the OEM perspective
they want a common stack to be able to integrate with a number
of prospective tier ones
... they have common components (eg definition on interacting
with linux bluez - bluetooth)
... they define abstract interfaces and reference
implementations of those interfaces
Ted: their stack is designed so you can supply alternate implementations of the different blocks in the stack
Paul: they did not want to get into the Web level HMI so are bringing their ideas in that area to W3C
<kaz> GENIVI Compliant page
Paul: to benefit from wider web
perspective and other W3C working groups
... Auto Grade Linux (part of the Linux Foundation) is doing
similar to Genivi
... Gunnar from Volvo is the architect for Genivi and gave us
their perspective on security approach
<kaz> Automotive Grade Linux
PeterW: is there anyone leading their reference implementation of the W3C Vehicle specs?
Paul: we are working on that with them and they're aware
Adam: the expert group (their version of WG) of theirs that makes the most sense on creating a reference implementation is their network group
Ted: @@harman, qnx, discussion with p-robin, jlr?. more the merrier, need to get more details on status and timeline
PeterW: QT too (in their web runtime)
Adam: Access may be providing us an update too
Jet: Mozilla is interested in
providing a runtime for automotive
... where should we get going in that effort? AGL, Genivi,
W3C?
Paul: all of the above
... you'll want to look at the other browser vendors effort
like crosswalk. we see many doing this in chromium at
present
Adam: there is a QT + WebKit browser proof of concept from Pelagicore in the Genivi Network group that you should also look into
Paul: again maybe Access as another browser vendor might want to speak up
<kaz> GENIVI Proof-Of-Concept
Shintaro: developing a browser based on WebKit but not using Qt
DaveR: we have some similar work
in W3C Widgets that this is similar to that might be worth
looking at further
... in the automotive context speed is really critical for UI
interactions
Kevin: it varies based on the data but absolutely
DaveR: a non-native implementation would be slower
Paul: auto industry is looking at html5 from my perspective is to leverage web technologies, draw from large pool of web developers, own their ui
Kevin: there are limits to native as well. we want a rich user experience that web allows
DaveR: I am reminded of native vs web apps on phones
Kevin: there are some very big differences and challenges in those two platforms (auto and smartphones)
Paul: some of this data is coming
through with some lag eg 20ms
... not all of the data is useful either
Kevin: optimizing startup time is a bigger issue than performance of web platform
<kaz> [ break ]
Adam: anyone care to start us off?
Kaz: it is required with Proposed
Rec
... there are two options, one to use the test framework
created by html5 group
... i believe there will be a breakout session for testing
browsers in tvs on wednesday
Ted suggests a couple volunteers join this session, take notes to send to group mailing list and report on a subsequent call
Peter Winzell volunteers
<kaz> breakout session ideas
Qing_An: I intend to setup a breakout session on Wednesday as well on LBS to try to get more people involved in our activity there
scribe: I am also looking forward to summary of this topic from BG meeting last week and our liaison session with GeoLocation tomorrow
Adam: are the times set for this session
<kaz> kaz notes there are several sessions on testing in general, and would suggest we attend
Kaz: it is an "unconference" model so no set times until it starts
<wonsuk> GitHub Repos for test suites for Web Platform specifications—including WHATWG, W3C and others: https://github.com/w3c/web-platform-tests
<kaz> TV testing session
<wonsuk> Geolocation API Test Suite: http://dev.w3.org/geo/api/test-suite/
<kaz> implementation report
Adam: we talked about
presentation we made to session track at Genivi AMM. LBS+voice,
Security, Genivi multi-user
... the presentation Paul, Ted and I made went well and was
well attended (will send slides to ml)
... Ted gave overview of W3C and draw comparisons to Genivi
model. I covered BG activity and ambitions, Paul WG spec work
and Junichi's Security Talk
... I am going to be promoting our W3C standards work on Genivi
Projects site with Jeremiah Foster to increase awareness of our
activity
... there was discussion of various efforts like SmartDevice
for integration of devices and head unit better
Ted: believe I mentioned during that session on this topic how that should coordinate with W3C Device API WG
Paul: another thing that came up
was specification versus working software. that is one of the
areas of contention between AGL and Genivi
... also how there are many different competing standards
bodies in this space. For security there is a consortium of
European auto makers
... Toyota attended that meeting and is going to use SDL
... time to implementation is very important for AGL people.
OEM want things that work now and don't want to wait on
standards even though their time to market usually spans a few
years
PeterW: re smartlink is anyone looking at android out?
<yingying> http://projects.genivi.org/smartdevicelink/home
[Dave Singer leaves]
Adam: we would like apple or google to get involved
PeterW: would like to have a common api to android out and apple carplay
Adam: are they going to have access to CAN?
Paul: not unless they work with the OEMs
Kevin: issue is how to do so in a safe controlled way
<Kev_G> Jaguar In Control Apps: https://www.jaguar.com/jaguar-range/f-type/features-options/in-control-apps.html
Adam: iHeart and Pandora aren't present but progressing. Paul or I will try to get more people from BG involved and we'll meet with TV Controller API CG later
<Paul> http://www.w3.org/community/autowebplatform/wiki/Main_Page/MediaTunerTaskForce
Adam: also we want to get more
activity around LBS this week and potentially start a draft
spec in BG like we did with the vehicle signal spec to later
hand over to the WG
... I see Alibaba and PSA leading that but obviously welcome
others interested
... Philippe Colliot(PSA) started looking over Qing An's use
cases
... and have a native implementation to potentially map
onto
Qing An: for LBS should we do this in BG or WG?
Adam: BG for now
Ted: Harman is in the BG, not very active at present but has been active in Genivi LBS. I found some people there to follow up with by email to see if we can engage them
<yingying> http://projects.genivi.org/ivi-navigation/
Ted: also from my notes on Genivi
LBS I see Continental (also a BG participant but not very
active in BG lately) as another to reach out too
... Volvo and Tomtom would be good to reach out to
... and in general if there are engineer for this (lbs) or
other topics you know at other organizations who you feel would
be beneficial in advancing this spec work, please introduce
them to the chairs, Kaz or I
Kaz: I attended TU Automotive in
Tokyo last week
... main topics included telematics and autonomous
driving
... several W3C member companies were present
... I spoke with a number of people from Alibaba, Harman,
Continential, Visteon etc
... trying to re-engage some of them as they were more active
before
<Kev_G> http://www.forbes.com/2008/02/28/oldest-work-clock-oped-time08-cx_po_0229salisbury.html
Ann: what does TU stand for?
Kaz: telematics update
Adam: they do many events
Paul: they just had Telematics West (competing for attendees to this and Genivi)
Adam: they cover many of the topics we do but at higher and business levels
<kaz> TU Automotive
Ann: I'm here not from Boeing perspective but on my own. I am wondering if this activity should be broader to some of the many other types of vehicles
Paul: you tried to ask me that question last year
Kevin: very different uses,
needs, data and driver states with eg construction
equipment
... but certainly things to learn from aerospace
Paul: there are some companies working in a very different part of the stack than we are sending large amounts of telematics data to manufacturer cloud space
Kevin: @@k
Paul: IVI reminds me of the screens in the back of the plane seat, information and entertainment
Ted: although this group is very focused on Web runtime and HMI level we discussed other W3C group work EXI in particular that is being used and useful to automotive, military
Paul: aerospace...
Ann: yes we contributed some use cases to that
Ted: but to your point we would
like to have some people from this group get involved with
other transportation industries in finding common needs/use
cases for EXI and other big data telematics
... there is also a Big Data Europe - transportation Community
Group who unfortunately is not at TPAC
Paul: I reached out to their chair Simon
Ann on autonomous vehicles of different types interacting in the future
Kevin: we are starting to see
this in certain controlled environments, tests for less
controlled environments
... the less controlled environments in complex environments
are going to need much more training (learning system) and
scenarios to reach to
... there may be some tough (life and death) decisions these
systems will need to face
DaveR: need for lots of alarms
and ability to shout look out/communicate to specific at risk
entities
... there are scenarios where vehicle does not have enough
visibility of eg a cyclist
Ann: that is similar to the factory scenario we touched on earlier, interested to hear from more countries and what they are seeing regionally
Qing An: we are starting to see more v2x work
Shintaro: we will be giving a demo during breaks and lunch
[lunch break until 2pm]
<kaz> scribenick: kaz
<paul> https://w3c.github.io/sensors/
<paul> https://w3c.github.io/sensors/
tobie: working on Generic Sensor API
-> https://w3c.github.io/sensors/ Generic Sensor API draft
tobie: explains the draft
... use cases have come up
... e.g., augmented reality
... need for higher interface
... event lister for sensors
... lastly extensibility section
... consistency across specs
... for different types of sensors
adam: we wanted to have that kind of capability for multiple vendors
tobie: would go into the
detail
... low-level sensors and high-level sensors
... high-level sensor is interesting
... e.g., high-level sensor exposes high-level device
orientation
... go down for example 3
... on geolocation sensor
... the sensor listens to geolocation changes
let sensor = new GeolocationSensor({ accuracy: "high" });
sensor.onchange = function(event) {
var coords = [event.data.latitude, event.data.longitude];
updateMap(null, coords, event.data.accuracy);
};
sensor.onerror = function(error) {
updateMap(error);
};
tobie: other examples
... geolocating the user
GeolocationSensor.requestData({ accuracy: "high" })
.then(reading => { displayCoords(reading.coords); })
.catch(err => console.log(err));
tobie: EXAMPLE 5: tire pressure sensor
DirectTirePressureSensor.requestData({ position: "rear", side: "left" })
.then(reading => { display(reading.pressure); })
.catch(err => console.log(err));
tobie: a lot of features at
risks
... e.g., 4.1 Enumerating Sensors
... access to lower level
... this is the FPWD
... next, some specific purpose
... and "6. Security and privacy"
... "7. Extensivility"
... ProximitySensor
... example WebIDL at https://w3c.github.io/sensors/#example-webidl
... would love to hear if there are problems
kevin: hacking?
ted: professor from KIST
... sensors for vehicles, medical devices
... need to define scope of values, etc.
... trust by verify
tobie: exposing sensors on mobile
devices is the current use cases
... doesn't mean it would not a problem
kevin: driving system need to verify the values
<ted> [they are able to impersonate sensors and spoof data and do things like point laser pointers, send ultra-sonic frequencies etc to give existing sensors erroneous data]
<ted> [need to have both hardware level encryption and data sampling to ensure your verified devices are not being tampered with]
[ that was part of the discussion during the BG meeting as well, I think ]
Dave: recognize this is very high-level
<ted> DaveR: to ted's point the fcc said the biggest threat to wot is data manipulation
Dave: the interface is just like
as KNX
... might be an issue for Web API
... another issue is permission for APIs
tobie: open issue on that
... permission for API is to check if the user can access
sensors
... when create a sensor instance, how that ask the users
... getting permission is possible
... you can wait until permission is obtained
... ideally would have permissions for specific sensors
DaveR: dictionary to describe
that
... the current API doesn't seem to be scalable
... types, ranges, etc.
tobie: this work is work done to
be a hook for sensors
... agree the fact permission is complicated
... e.g., what if we have 50 sensors and would access 25 of
them
... permissions API checks the origin
... not for requesting
junichi: class of sensors?
tobie: wouldn't make sense for
all use cases though would make sense for some of them
... possible to have sub class of sensors
... using the URL
junichi: you have to define all
kinds of sensors if you use this approach
... how to handle new sensors?
adam: using the extensibility?
tobie: the goal here is easy
extensibility
... you could have a class of sensors
... e.g., you could create a remote server-based sensor
paul: we don't care about where
the data came from
... good to read this spec in detail
... looks similar to what we've done
... similar to what our company do for telematics
tobie: a lot work for
Node.js
... node bot
... a framework called Jonny 5
... a very logical way for JS to access the data
... how to access different kind of sensors
... one thing still struggling is
... some of the sensors return data periodically
... some of them just return data at some time
paul: subscribe the data for that purpose?
kevin: grouping of sensors
... guide way for the interface?
... what if you have 40 sensors
tobie: could have a sensor
hub
... this draft specifies high-level specification
... e.g., not a GPS but a gelocation sensor
kevin: issues with
interaction?
... need to decide/authorize if we get the data
tobie: the OS is in charge of the
security
... not the API itself
... not cared by the current draft
... JS doesn't really give you a method to guarantee trust
kevin: what about using some token?
tobie: could use https connection for secure connection with sensors
<ted> Extending vehicle data spec
tobie: one use case in mind
... GPIO kind of sensors
... JS file to test the sensors on devices
... expose sensors on the device
... the question is how can we make those devices
discoverable
... difficult problem
... difficult to fingerprint the devices
... across origins
<ted> ted: our main interest in generic sensors api is ability for a given manufacturer extend our spec and provide a more robust vehicle object based on sensors available to them. the oem may want to have their sensor vendors (or a middleware component) expose through this generic sensor api. it would make for easy intergration
tobie: discovery API is challenging
ted: we discussed before that
device discovery explores
... related to not only auto but wot
tobie: thinking about layers of sensors
<ted> [dap, now das (device and sensor), is putting on hold device discovery and want to seek use cases from auto, wot and others. sensor api is somewhat of a prerequisite]
ted: there are people extremely
interested in device discovery
... discussion tomorrow and Wednesday
tobie: ad-hoc meeting tomorrow afternoon
paul: is that the breakout session?
tobie: no, another one
-> https://www.w3.org/wiki/TPAC/2015/ad-hoc-meetings#Generic_Sensor_API ad-hoc meeting on generic sensor api
tobie: 3-6pm@room 201
... and a breakout session on Wednesday
(time/room to be decided on Wednesday)
<paul> https://www.w3.org/wiki/TPAC/2015/ad-hoc-meetings#Generic_Sensor_API
tobie: APIs not tied to
implementations
... communicate with sensors very easily
... questions?
(no questions)
[ 10-min break till 15:20 ]
<Adam_Abramski> Hashimoto-san presenting Automotive Security and Privacy TF
<scribe> scribenick: ted
Security Summary at BG meeting last week
<ted> [[mission:
<ted> Provide envisioned incident studies.
<ted> Clarify requirements of web technologies based on the above studies.
<ted> Propose technical description to be added as specifications of "Vehicle Information Access API" and "Vehicle Data" ]]
junichi: procedures steps (3) need to be iterated repeatedly: list use cases, review in detail identifying attacks vectors, derive requirements
<ted> [policy slide]
junichi: my basic
policy for this tf is that we make the car more convient, not
increase risk and not leak private information
... we met with genivi last week to find common interests and area
for collaboration. while genivi is mentioned in this slide this
would be a useful exercise with similar organizations, oems and
tier ones
... we should also think about inter-application interaction
<ted> [target model slide]
<ted> [basic model of stack - web apps, runtime, os and native app layers...]
<ted> [model comparison]
junichi: these two
models are based on discussion with genivi
... webview vs browser
... runtime as a component (webview) allows more for an app market
of singed packages
... in the runtime as the platform (browser) the browser vendor
defines web app interactions, in the webview os maintainer. genivi
prefers the webview model
<scribe> scribenick: kaz
junichi: should start discussion
on the (possible) vehicle api v2
... would separate the step for it
kevin: tx
... need for validated app store using some specific
server?
... potentially
ted: we have a runtime
evaluated
... for trusted open market
... much more free
... interaction with web apps
... more rigid structure
kevin: but in practice, difficult
to have this model
... some interaction with OEMs
ted: you don't have to investigate it
DaveR: OS level security, e.g., Android
<ted> ted: you can do both. have the more open with limited, less sensitive information available and inter-web-app interactions to be free take place. a second web runtime can have the more structured and secure interactions with more sensitive data
kevin: if you control everything using the model on the left side
<ted> [advantage to doing both is you can have a more open marketplace that you would still review but not assume as much risk]
jet: would be useful for more
consistent user experience?
... policy for entire system or not
kevin: even the right side approach might not be enough for use distraction in some cases
DaveR: using the right-side model, could have some robustness
kevin: good point
paul: could be another way
... you can flip Apps and Browser
kevin: possibly a mixture
peter: would be a native app
DaveR: they could also use virtualization - (run on separate virtual machines)
junichi: personally prefer left
approach
... Firefox OS is something like this
... many OEMs don't seem to use the the left model
currently
... so would suggest we start with the right model
wonsuk: the right side shows a hybrid application?
junichi: right
wonsuk: all the apps are
packaged
... install and use it
... that is a native app-like style
... but HTML5 apps could be just a URI
... the app accesses some service on the Web
... in case of the right side, you only think about packaged
apps
... which include all the resources inside the package?
junichi: at least the exec code
should be inside
... content data could be from outside, though
wonsuk: both web apps and hybrid apps get actual content from the web
junichi: however, regarding the
lifecycle model
... OEMs check the apps before releasing them
DaveR: there is a challenge
... you can only say something about the app
... there is a malicious part
kevin: you can check where from the data provided
DaveR: this model assume calling
some server and verify the data
... the right model has access restriction
kevin: you could have multiple
browsers to use multiple processes
... in practice limited access would be useful
DaveR: on your (=Junichi) slide, you mentioned attack vectors & type of threat
(some discussion of privacy issues)
jet: more interesting to use the
Web technology for more than rendering
... behavior of scaling is different
kevin: you might need visit the
server beforehand
... and declare I'd use Facebook
<paul> http://www.autosec.org/publications.html
kaz: mentions EME work which is originally developed to protect content right
DaveR: that is related to local-side threat
junichi: would move forward
kaz: so do we want to think about the both models?
hira: we should clarify the pros and cons of the both models
kevin: JRL implement both the
models
... and use a secure channel
... don't think we need to dismiss one of them
adamC: agree
kevin: the point is how secure
the Web sandbox is
... authenticate the user, authenticate the vehicle
... in practice, the left-side model may be more secure
... but the both models must be secure
sakamoto: which layer is the
target?
... the user app can access the vehicle ECU?
... web view also uses HTTP connection
... so there is no difference from the viewpoint of web
connection
kevin: it's not for a safety
critical system
... we don't need to make a choice between the two models
ted: you (junichi) are right, architecture choices like this doesn't belong in the spec. we might want to produce best practices and guidelines outlining the differences and possible desire to have both
kevin: having two interfaces,
w3c-based standard interface and proprietary interface
... would be easier to test if we have w3c-based standard
interface
junichi: have another idea
different from these
... having a node server who handles all the requests
wonsuk: think it's already
implemented based on existing standards
... web apps can request for geolocation server
junichi: we can define an actual
URL for that purpose
... for a vehicle information server
... not sure if we should handle that model here, though
... in the both cases, the blue boxes have interface
sakamoto: vehicle APIs are used by the Apps and access the Base OS?
hira: the web view part need to have all the APIs in the right model
ted: do you have any more slides?
junichi: yes
ted: you've identified issues and next steps for the security&privacy tf
junichi: would summarize the TF's
work so far
... categorized all the 60 use cases
(protection against intrusion and attack)
junichi: explains the
legend
... green circle: feasible and scope of the current spec
... yellow triangle: beyond our scope
... red arrows: future scope of need further discussion
... we have less use cases for this category
('set' API)
junichi: not positive for 'set'
APIs
... not recommended but have to understand the need
DaveR: safety lock, window, etc.?
ted: we don't have clear separation of which of these we will even be interacting with. jlr+genivi rvi for example will not go through web runtime but their own protocol and not boot the whole ivi when the car is off.
paul: everywhere HMI type of user interaction exists
junichi: a use case asking the runtime to allow only one feature at once
(API accessibility)
junichi: requires more
discussion
... certification is impossible from my viewpoint
... introducing OS support would be feasible
... automaker provides API via https instead of direct
APIs
... remote access should need future discussion for the
spec
(Communication)
junichi: secure/trusted
communication between devices
... secure access to outside storages
(User's rights for their personal data)
<ted> -> @@link_slides Junichi's latest version of slides
junichi: "Do Not Track"
feature
... Generalization of data for protection of privacy
... Emergency cases
... Monitoring
... we have 'GetHistory' capability within the current spec
ted: IVI is not available after
crash
... maybe we could have some secondary responses in that kind
of difficult cases
<ted> [for a secondary response. there was agreement there may be plausible use cases when the ivi is still running it can be an actor in such a situation]
(some more discussion on emergency cases)
paul: would be good to identify
what is IVI and what is not
... you has to have personal information
<Karen> [Dutch firefighter reference to Bart van Leeuwen, Netage]
paul: is it part of this API?
ted: it doesn't apply to the API itself
paul: nice to have a criteria
ted: which security concern is
related to which level?
... OS level, wrapper level, etc.
kevin: should share the concern on security with other groups as well
<paul> https://www.w3.org/WoT/IG/wiki/Security,_Privacy_and_Resilience
kevin: security and
responsibility
... if security should be handled by OS level
... we don't need to think about that for the Web layer
ted: we had useful
discussions
... there threats on the OS level and the browser level
... would be better to best practice or guideline document
(Multi Drivers/Passengers/Users)
junichi: for mobile phones, there
is only one user
... so we don't have to the possibility of multi users
... but there is a possibility for cars to have multiple
drivers
... user identification, environment switch, payment
wonsuk: generally we should
synchronize on how to handle devices
... APIs to handle various devices
... DeviceAPIs WG has done battery API and vibration API
... but we don't have a security model for the generic
web
... API to read data and write data
... a bit curious about our having both get and set within a
spec
... we might want to try get APIs first
... and then set APIs next
... should start with a safer APIs
ted: would have a middle
layer?
... it's out of scope of our API but we can use the OS level
mechanism as well
<ted> [the critical high concern will need to be handled at os level, basically not an option in web runtime]
wonsuk: even OS level APIs have
security issues
... OS handles physical devices
junichi: we've discussed models
for packaged web applications
... can we reconsider packaged web apps?
... not sure what we can do without other group's support
wonsuk: need to make something as
the first step
... and then think about the next step
<ted> [medium will be permitted by the more trusted webview model. low (read only) permitted for intra-webapp processes. we can define these basic levels and how to structure acls in web runtime]
wonsuk: W3C has experience of huge specs, e.g., HTML5
kaz: are you thinking about some possible mapping between the web layer and the native layer?
paul: we have to have a roadmap
wonsuk: we got the draft spec
from the BG
... for the current spec, we could just think which part should
be the v1 spec
ted: we can have some different
tiers
... including a read-only/no-set layer
... HVAC should belong to a OK-to-access layer
kevin: if a user can't be allowed
to access some data
... need to repeat to access the data?
ted: for our spec, come up with
access control
... next step should be gathering best practices
... web-based IVI opens up issues on security&privacy
kaz: when we think about best practices, maybe we should think about which part of the model is responsible to which part of the issues
kevin: what if different
implementations handle different errors?
... every OEM uses proprietary error codes
paul: we need a breakout to discuss what to do
(checking people's availability)
paul: tomorrow would be
better
... might be helpful if people could write down their ideas by
email, etc.
... and have a breakout meeting tomorrow
... send to the public list?
ted: yes
paul: ok
... what you want for the current spec from the security
viewpoint
... and expected roadmap
... everyone is encouraged to send your ideas to the
public-automotive list
<ted> mailto:public-automotive@w3.org
paul: should wrap-up now
... tomorrow we'll have joint meetings with Web Payments
(9am@206), Geolocation (10am@108), Web&TV (current plan
1pm@mid hall b), WoT (2pm@108), Generic Sensor (3pm@201)
DaveR: there is the security
group within W3C
... breakout on Wednesday
-> https://www.w3.org/wiki/TPAC/2015/SessionIdeas#Web_Authentication_and_Security Breakout proposal
paul: good discussion today
<ted> Liaison minutes with Web Payments
<ted> [Introductions]
<inserted> scribenick: kaz
(round table; circulating the sign-up sheet)
paul: Adam Crofts will give the summary
(starting the webex terminal)
adamC: two specs: Vehicle
information access API and Data API
... startin with the Vehicle spec
-> http://rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html vehicle information access api
giri: question on in-car location information
adamC: front, middle, center and
layers
... shoes the "7. zone Interface"
kevin: top and bottom are the basic two layers
tobie: sounds reasonable
kevin: cameras could be located front or rear
tobie: had same discussion for generic sensor api
adamC: shows section 11 and
12
... VehicleConfigurationInterface Interface
... can specify time span to get data
... shows "EXAMPLE 3" right above "14. Data Availability"
... and "14. Data Availability"
... check if each data is available
giri: what is the expectation for this API?
adamC: HTML5 sends data from car to user, and communication with outside service
paul: data coming all time from the car
giri: application get the data via one-shot api?
adamC: maybe 10ms example was a bad example :)
paul: don't have previous any use
cases on how to get data using this spec
... would see high-level business use cases
giri: others from Qualcomm are involved in Genivi
paul: a business group has been
created
... worked with Genivi, Webinos, QNX, etc.
... concept of extensibility considered
adam: we have same problems as the generic api guys
adamC: shows "16. Use
Cases"
... and come back to "EXAMPLE 1" right above "2.
Conformance"
var vehicle = navigator.vehicle;
vehicle.vehicleSpeed.get().then(function (vehicleSpeed) {
console.log("Vehicle speed: " + vehicleSpeed.speed);
},
function (error) {
console.log("There was an error");
});
var vehicleSpeedSub = vehicle.vehicleSpeed.subscribe(function (vehicleSpeed) {
console.log("Vehicle speed changed to: " + vehicleSpeed.speed);
vehicle.vehicleSpeed.unsubscribe(vehicleSpeedSub);
});
var zone = new Zone;
var zones = vehicle.climateControl.zones;
for (var i = 0, zone; zone = zones[i]; i++) {
if (i.equals(zone.driver)) {
var value = {};
value["acStatus"] = true;
vehicle.climateControl.set(value, zone.driver).then(function () {
console.log("Successfully set acStatus");
},
function (error) {
console.log("There was an error");
});
}
}
adamC: walkthrough the
example
... "4. Security and privacy considerations"
giri: vehicle environments don't
necessarily expose all the data
... should mention that
adamC: OEMs make decision
giri: this is
Navigator.Vehicle
... could be exposed using some client-server model
paul: conceived based on the
discussions with Genivi, etc.
... various vehicle networks
... running within a car is an assumption
giri: the spec is written
... but you could have a client-server model
... e.g., HTTP connection
paul: still don't know how the
runtime gets the data
... how auto makers would use this spec?
... extending the web runtime is the key discussion, e.g.,
within Genivi
... typically using WebSocket
... would love to hear opinions
kevin: could choose how to apply
this, e.g., inter-vehicle model
... whatever technology would make sense
... secure access to vehicle internal data
tobie: distinction between
different kind of servers?
... locking and unfor locking, etc.
kevin: identification and
authentication for vehicles
... on whose behalf the APIs work
... complex safety issues
... if we are sitting in the vehicle and use the API
... you can safely use the capability
... but not so if you use it remotely using a mobile
... because of safety
giri: every single query is accessible from outside?
adam: no
... optional
paul: similar to generic sensors
tobie: across different implementations
giri: fingerprinting?
... what's available within a vehicle
... to identify who is using
paul: if you can get a license number
tobie: not to expose (more than)
enough information is problematic
... would cause big privacy issues
kevin: have to be careful, e.g.,
to anonymize the data
... minimizing your footprint
giri: we minimize user data
... need to see if the data is really needed
paul: is this useful?
tobie: user should be aware
... the user browse web pages
... when/how the data should be exposed?
kevin: we're launching some opensource project, @@@
tobie: this is more like a web-based OS than a web browser
kevin: in order to protect
customer's security/privacy
... there are apps we control
... completely different from browsers which user themselves
use
tobie: not read the spec itself
yet
... but think it should mention what the expected security
model is
adam: valuable feedback
... don't want the spec to say "this is the box you need to
use"
tobie: the Web has a distributed
model
... so should mention the expected security model
giri: agree
peter: HTML5 apps are real third-party apps
tobie: but should be something automakers can trust
peter: probably you need some limitation
tobie: if your security model is
clear, that's fine
... there could be a possibility of using regular Web for 20%
of the system
adam: moving forward
adamC: data spec
-> http://rawgit.com/w3c/automotive/master/vehicle_data/data_spec.html data spec
adamC: "6. Running Status Interface"
giri: relathionship with
DeviceOrientation
... assumption to get data from mobile devices?
paul: this is vehicle
information
... but communication with GPS, etc.
... Hirabayashi-san had some discussion with you, Geolocation
WG
... communication to get data
... deadreckoning module use communication?
giri: we're not sure how to get the position object
paul: for geolocation information
we'd use geolocation api
... have discussion on location-based services
... people might want to choose which data should be
exposed
giri: maybe we should cooperate with the Generic Sensor APIs guys
kevin: we just think about apis
for vehicle
... vehicle could consume apis for mobile
... there is trust issues, though
... in an easiest case, you might want to use a mobile as a
sensor
adamC: "6. Running Status
Interface"
... "6.2 Vehicle Speed"
giri: just saw a different case of battery status by DAP
-> http://rawgit.com/w3c/automotive/master/vehicle_data/data_spec.html#batterystatus-interface batterystatus
tobie: very car-specific
environment
... who do you expect as the developers?
... car people or web people?
adam: what we should expose is the key
tobie: think there is duplicate
stuff with other web specs
... may be a nightmare to have multiple similar specs...
adam: we do have interest in
collaboration
... we've been working on a set of APIs which is interesting to
OEMs
tobie: I'm just pointing out the fact there are some duplicates
giri: the battery api by DAP doesn't fit this purpose
paul: we need some domain-specific knowledge for automotive purposes
kevin: driving cars safely
... who is driving the car
... might have higher level of drive instructions for ADAS
cars
... how involved the driver is
peter: difference between the driver's seat and the rear seat
kevin: this data definition is a right set
paul: during the joint meeting
with the payment group
... discussion on not tying to some specific vendor
tobie: just wondering what is the target developer for this api
paul: agree doesn't make sense to
reinvent specs
... have been discussion with OEMS and tier1s within the BG
tobie: similar questions on TV discussion
kaz: right, so we should see what's happening within the TV world, e.g., we could join the breakout session on TV browser testing tomorrow
kevin: careful discussion on security
paul: some automakers use HTML5
for their IVI systems
... using high-level abstraction
kevin: there are 70 signals
... but can't expose half of them
... don't have the signals yet
... there is a lot of work for mapping
... security as well
... the other issue is what "vehicle speed" means
... could use GPS information
tobie: generic sensor discussion has similar issues
paul: how much data is exposed depends on each automaker
kaz: tobie, you're not denying this spec itself, but would suggest we work with related groups even harder?
tobie: right
... clarifying the expected security model as well
kevin: it would be helpful to
hear some concrete description on security framework
... would be difficult to cover whole the vehicle
security
... that's a challenge
... need to implement secure vehicle
... would get some particular security scenario
giri: @@g
tobie: is it sufficiently low-level solution?
paul: would take a homework to look into battery, geolocation, sensor specs
tobie: geolocation could be
rewritten using the generic sensor api
... you have a more specific case
... there could be two different kind of data for speed, e.g.,
car-based speed and GPS-based speed
... if you show up for the generic sensor ad-hoc meeting
(3pm-)
... would talk about what generic sensor is like
junichi: technically low-level
approach works
... but users don't know how GPS works
... how to identify that kind of different need
tobie: how the detail is handled should be decided by the implementers
junichi: generic sensor api
doesn't handle high-level security like user's preference
... by using generic sensor api, maybe users can turn on/off
devices
... but the user may have specific preference for security
tobie: generic api doesn't handle
permission based on user's preference
... the user agent decides that
junichi: OEMs and/or implementers should handle that?
tobie: yes
junichi: in that case, users need to understand the mechanism?
tobie: no
... application implementers and/or OEMs handle privacy
issues
-> http://wiki.projects.genivi.org/index.php/IVI_NavigationW3CUseCasesAndGENIVIAPIs wiki page
qing_an: walkthroughs
giri: you don't need to add specific apis to handle maps
qing_an: there are media tuner
capabilities as well
... POI (point of interest)
... there is no generic api for this purpose
giri: if you don't expose data to
outside (different from usual web apps)
... this would make sense
... for example, I have relationship with a map server
... but that depend on broadband connection with the
server
... if the assumption is automotive uses may be ok
... but for generic web use, it's not allowed
paul: there is Genivi's position
giri: there was some discussion
on geocoding
... but it didn't go into the standard
paul: this automotive group has several map guys
giri: for automotive services, an OEM might want to use one specific map
kefin: could use different map services
giri: the developer don't have to
know about the detail
... that's the case for geolocation api as well
adam: developers can develop apps regardless of which map system is used
tobie: ok. you should do this within this automotive group
giri: now understood it makes sense
qing_an: if anybody is interested in this work, please join
adam: it would be great if we could somebody from Qualcomm
paul: mentions who are participating now
giri: can I get address features those already handled by the geolocation api?
qing_an: ok
... there is "Geocoding" features as well
... and "System Interface"
... TTS capability
giri: should refer to touch event api
kaz: and speech API for TTS
paul: we met speech api guys in Santa Clara before
qing_an: anything missing?
giri: we're defining geofencing
within the Geolocation WG
... usually associated with POI
... bound here could be tied with geofence
... the draft is FPWD status
... would suggest see that
qing_an: would talk about the
detail during the ad-hoc session later
... and breakouts tomorrow
giri: thought sent slides to you
<gmandyam> Geolocation API Style presentation: https://www.w3.org/2008/geolocation/wiki/images/b/b0/TPAC-2015-Geolocation-API-Style.pdf
<inserted> giri: Geolocation API
giri: first device API by
W3C
... asynchronicity required
... interoperability has been an issue
... DeviceOrientation
... almost called "gyro"
... longstanding issue on absolute orientation vs relative
orientation
... Geofencing
... newest spec
... based on service workers
... data minimization was incorporated into breach events
... Some things to consider
... enumerate all the security/privacy requirements
... carefully consider API definition that calls for specific
hardware implementation requirements
... similar to Web&TV as well
... defining APIs for new objects
all: thanks!
<inserted> scribenick: ted
kaz: the web & tv ig has spun
off tv controller api cg
... we met with chairs and team contact of the former over
lunch since the latter are no longer here
<scribe> scribenick: ted
-> https://drive.google.com/open?id=1nYs8_xMktQCynLEOYRjLFxatFuQkamrvfpQ3sAMC10s TV Control API CG update
kaz: there is currently a draft spec coming out of the cg. they drafted a note since it doesn't have the weight of a spec from a wg
adam: looking at the time line it looks like we might be late to add further contributions
kaz: they are planning on future versions of this spec and form a wg
Joerg: we started this activity
because of all the interest around internet of things
... there have been studies about how much can be gained,
homes, offices, transportation, cities
... there are many technical standards for the lower levels of
IoT but there was a gap for the upper layer
... our vision is basically to build web applications across
these things
... we came up with general ways to describe these things
... basic metadata. we came up with an interaction model = what
kinds of properties, actions and events
... of course you also need to describe what the data payload
is
... we thought of a scripting api and protocol mapping
... in various interactions things act as either clients or
servers
... in auto case we want to treat vehicle as another
thing
... when we say "web thing" it is the online representation of
a physical device
[wot building blocks, slide 5]
Joerg: we can come up with three
kinds of apis. server, client and physical apis
... physical layer can be wifi, bluetooth etc
... things are meant to interact with one another or the
web
... besides scripting and protocol we have a task force on
discovering things
... when they come into proximity allow them to discover what
is availabe from other iot platforms
[6 categories
-finding around me - nfc, uribeacon
-finding things on my network, mdns, multicast coap
-searching in directories (when network is too large or distributed) core resource directory, xmpp iot discovery
-searching via p2p
-accessing thing metadata (core link format, hateoas)
-semantic based discover - mostly research at present
]
Joerg: not sure how much of this is relevant since cars are already predefined but you also do bring in external devices
[WoT BB - Security & Privacy]
Joerg: security and privacy
requirements derived from use cases collected
... we compiled a landscape list of s&p means
<yingying> https://www.w3.org/WoT/IG/wiki/Security%26Privacy_Requirements
[work on technical landscape]
Joerg: discuss domains, set of
atomic use cases. doing a landscape study, we are looking at
multitude of IoT being developed
... for mapping and scripting api you are abstracted away from
the specific protocols
... we are looking for a very basic common denominator for
thing description
... we are interested in what sort of apis you have into
vehicles
... we have 4 implementations already trying to understand this
space
Kaz: we would like stronger collaboration on privacy and security
Joerg: if we can join forces
there that would be good from our side as well
... we would be interested in your use cases in this area as
well
Junichi: any concrete use cases on this servient diagram?
Johannes: a script option might
take data off the web (eg weather) and device act on it
... we want to abstract the api from the protocol as it is not
always a web protocol
... for your application you are staying high level
<kaz> WoT APIs&Protocols TF (working on protocol mapping)
Junichi: for a car navigation
system in ivi would the one on the left make sense?
... we only allow predefined applications in one model and
others that they can pull things down from the web
Johannes: you could restrict to what an application programmer can use. it can only be enforced by a well defined api
<inserted> Junichi: which part is a web runtime?
Johannes: we do not say the type of runtime, it is not necessarily a web runtime as that restricts it to js
Junichi: in a single device you only have one of these modes [on wot servient slide]
Johannes: there is nothing that prohibits you from having several scripts
Dave: script can represent multiple things too at once
Kevin: this is very general given
breadth of things being represented
... are there areas like authentication that you are focusing
on in more detail?
Dave: yes we have a task force
Joerg: it is restricted to
requirements you have a resources available
... we started with generic view and now looking at specific
actors
... we want to make this concrete with specific examples
... so far we have done this for simple thing description,
protocol mappings and we are going further with security and
privacy and scripting model
Kevin: knowing what a thing is a member of like a physical house would be useful
Johannes: we are landscaping what is the market and where it will fit
Kevin: how do you know if the thing is what it claims to be?
Dave: we are looking at establishing credentials
Joerg: majority of the time you do not have access to a given thing so that ties into authorization management
Dave: part of this is through provisioning. how do you configure it and its security properties
Kevin: when you want to tie your car into your home entertainment system, you want to see your internet of things by useful identifiers
Joerg: that is part of the
discovery
... is this part of what you see as about the infotainment in
the car
Paul: depends on who you talk to.
what we are primarily working on is a data access api for the
underlying vehicle
... it is mostly as an IVI on head unit but could be used other
ways
Joerg: are you triggering longer running actions or merely a browser getting and setting values
Kevin: parts of the car can be
web things
... you might want your fridge to let you know you are running
low on milk when you are on your way home
Joerg: besides these kind of getting and setting are you getting into automation
Kevin: yeah it could be
anything
... one set of use cases coming at us is for assisted
driving
... we need to give trust to adas control module in a car and
similarly there needs to be levels of trust between devices
Johannes: we require self contained messages so they are not hijackable. they can be signed and encrypted and not rely on a hidden state
Kevin: I would appreciate references to that
Joerg: we might be interested in looking at automotive as an experimental use case
Paul: most relevant here to wot is v2v and v2x
Junichi: we have several use cases but none addressing running a server from the ivi
[Kevin presents slides]
Kevin: what this use case is talking about as it might pertain to wot in driver assist, it needs to trust the information that is coming from other devices
[slide 7]
Kevin: the adas control in this
model needs to trust sensors and it isn't receiving spoofed
information
... in convoy mode you need to get information from vehicle up
front about eg braking incidents
[slide 8]
[slide 9]
Kevin: you can share information of various sorts with vehicles in proximity
[slide 10] (some wot use cases)
[slide 11] access control
Dave: one challenge is trying to code something across varied versions. regarding resilience we intend to discuss further in the IG what would be predictable behavior and data
Joerg: we can take away one or more of your use cases to draw it out further
Kevin: your notion in wot of atomic is interesting, all events happen or none happen - rollback
[Adam giving tour of spec]
<kaz> Vehicle Data spec
<kaz> [ break ]
<kaz> scribenick: kaz
paul: three messages on the list
Junichi: would keep
momentum
... so would publish the updated draft on schedule
-> https://www.w3.org/auto/wg/wiki/Main_Page#Publication_Schedule publication schedule
<Paul> From Hashimot-San regarding security next steps:
<Paul> * We may have to omit 'set-api' from V1 * V1 spec should rely on OS security framework instead of on-going web solutions because we cannot control these schedule. * Security & privacy consideration doesn't have to be in spec but should be anywhere, e.g., as a BG/WG note. This will be required in the review process.
-> https://lists.w3.org/Archives/Public/public-automotive/2015Oct/0032.html Junichi's message
Junichi: some guideline is needed
paul: agree
Junichi: how to keep the momentum is my point
ted: some work in place now
... and wait for, e.g., next year, to try more?
... for v2, we deal with major security update
adam: keep the current v1 spec asis?
paul: we hear some
considerations
... it's something like that we believe the current API is
fine
(discussion on error codes, etc.)
-> http://rawgit.com/w3c/automotive/master/vehicle_data/vehicle_spec.html#vehicleinterfaceerror-interface Error Interface
-> https://lists.w3.org/Archives/Public/public-automotive/2015Oct/0043.html Kevin's message
-> https://lists.w3.org/Archives/Public/public-automotive/2015Oct/0034.html Ted's proposal
ted: proposals on possible next
steps for security and privacy
... we can do high-level protection
... "Access Control Mechanism"
... "Best Plactices for Web Runtime in IVI"
... what is "Web Runtime"
... review various use cases and attack vectors
... "Entity preference profile"
... define personal, payment, vehicle information, etc.
... like credit card number
... first one and second one for safety
... third one for user profile
-> https://lists.w3.org/Archives/Public/public-automotive/2015Oct/0039.html Kevin's message in response to Ted's message
<inserted> scribenick: ted
[Proxy piece could include:
-sanctioned site list and protect against usual uri games
-check certificates
-strip javascript
-content type check (make sure we are getting back what we're expecting)
-data integrity check - logic to see if received information is in with expected range, for more sensitive information
- others]
<inserted> scribenick: kaz
adam: this is access control for web runtime
<ted> http://www.w3.org/TR/runtime
adam: "Runtime and Security Model for Web Applications" by SysApps WG
Junichi: this approach is huge and am not sure if this could be applied soon
kaz: please note this draft is a WG Note because the work is stopped
adam: this is application level
access control
... this needs to be implemented by runtimes
... you have something like this as the basis of the
discussion
wonsuk: unfortunately, this spec
doesn't really our security expectation
... there was a security expert who stepped down in the
end
... we can't make progress without having a security expert
adam: this covers some of our requirements, doesn't it?
wonsuk: basic input for this
document was made by Google
... based on their experience on Chrome OS
... the concept of "runtime" was that applications are
packaged
... after our starting service worker, service worker-based
approach would be more appropriate
... we can't necessarily use links appropriately using packaged
apps
... for web apps we can simply share the links
... everybody can use the web app at once
adam: not sure that is an appropriate use case for car apps...
wonsuk: we learned that using
hosted web apps is lighter approach than packaged apps
... we can choose either way (online or packaged)
... firefox os, chrome os, tizen, etc., are going to that
direction
... this runtime security approach is also a basic mechanism
regarding manifest, though
... defines a basic mechanism for tizen, etc.
kevin: what is the benefit?
adam: the guys from the security team have expertise
junichi: there are two things
here
... manifest and CSP (content security policy)
... maybe we can utilize the idea included in this draft
wonsuk: manifest spec is going now
-> http://www.w3.org/TR/CSP/ CSP
<wonsuk> manifest format spec: http://www.w3.org/TR/appmanifest/
paul: how could we get
adapted?
... you want to layout all the issues
... getting security consideration as a section
... but what should be done for the concrete security
description?
... we've been going around and around
... what would be a discrete action item?
... Kevin set an issue on GitHub
junichi: would handle access control
paul: error, access control, set, ...
ted: woT is doing some stuff
paul: entity preference?
ted: besides data coming from
CAN-bus
... personal data like location, address, etc.
... out of scope of the vehicle spec, though
paul: we need to slice (the action items)
wonsuk: for the horizontal
security model
... the Web Application Security WG is working
... Junichi and the Security TF should investigate their
work
<wonsuk> specifications from web apps sec: http://www.w3.org/TR/#tr_Security_for_Web_Applications
kaz: Natasha from GSMA gave some talk on their work last night during the Developer Meetup
wonsuk: we should investigate
their work first and then add security portions to our
spec
... one of the big ways is that Web vendors would like to use
only HTTPS
... that is a good sign
... basically we need to know what is done
... and what kind of security issues
junichi: it depends on what we can do with this spec
wonsuk: even if we omit the 'set' api, there might be some issues
junichi: currently, history and accident information are the keys
wonsuk: need to see when/what information could be exposed
paul: error, access control, set,
threat model, OS security
... person id, entity
... sensitive data element
hira: these items require further investigation for v2
paul: we need some text for v1 as well
hira: how about handling
emergency exception with DNT?
... we have to talk with the privacy group or DNT group?
paul: what do we need with DNT?
hira: this issue will be covered by v2 or v1?
paul: we should see
... could mention every user don't want to be tracked
junichi: as for web security
specs
... it refers to many specs
... working by myself is difficult
... would work with Kevin
kevin: ok
junichi: would work for credential and permission as well
-> http://www.w3.org/TR/#tr_Security_for_Web_Applications Security for Web Applications
-> https://www.w3.org/wiki/MMI/Use_Cases MMI Use Cases
-> http://www.w3.org/2013/10/mmi-charter.html#mmi-ecosystem MMI Charter
-> http://www.w3.org/TR/emma20/#s4.1.10 EMMA 2.0 geolocation example
-> mailto:www-multimodal@w3.org MMI public list
<kaz_> [ taking group photos ]
<kaz_> [ meeting adjourned ]