See also: IRC log
<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 ]
<yuwei_> rrsagents, make mintutes
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" })
]]
tobie: EXAMPLE 5: tire pressure sensor
[[
DirectTirePressureSensor.requestData({ position: "rear", side: "left" })
]]
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
<ted> Use Cases
<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" ]]
<ted> junichi: procedures steps (3) need to be iterated repeatedly: list use cases, review in detail identifying attacks vectors, derive requirements
<ted> [policy slide]
<ted> junichi: my basic policy for this tf is that we make the car more convient, not increase risk and not leak private information
<ted> ... 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
<ted> ... 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]
<ted> junichi: these two models are based on discussion with genivi
<ted> ... webview vs browser
<ted> ... runtime as a component (webview) allows more for an app market of singed packages
<scribe> scribenick: kaz
<ted> ... in the runtime as the platform (browser) the browser vendor defines web app interactions, in the webview os maintainer. genivi prefers the webview model
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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/or API/or API with Tobie Langel/ Succeeded: s/@@1/Toshiba/ Succeeded: s/@@2/Fujitsu/ FAILED: s/Resulved/RESOLVED/ Succeeded: s/Resolved/RESOLVED/ Succeeded: s|s/Resulved/RESOLVED/|| Succeeded: s/David_Rogers/David_Rogers(Copper_Horse)/ Succeeded: s/p-robin/p-robin, jlr?/ Succeeded: s/@@/developing a browser based on WebKit but not using Qt/ Succeeded: s/(no longer swearing) // Succeeded: s/communicte/communicate/ Succeeded: s/cy/cy"/ Succeeded: s/class/class of sensors/ Succeeded: s/extension/extensibility/ Succeeded: s/@@@/class of sensors?/ Succeeded: s/similar/looks similar/ Succeeded: s/trusty/trust/ Succeeded: s/topic:/tobie:/ Succeeded: s/they would virtualize apps/they could also use virtualization - (run on separate virtual machines)/ Succeeded: s/left/the left/ Succeeded: s/vectors/vectors & type of threat/ Succeeded: s/malcias(?)/malicious/ Succeeded: s/would be useful to see the spec and think about guidelines/you (junicho) 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/ Succeeded: s/junicho/junichi/ Succeeded: s/we don't have clear separation of what is ok and what is not/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./ Succeeded: s/Web/Web layer/ Succeeded: s/a get API/get APIs/ Succeeded: s/108)/108), Generic Sensor (3pm@201)/ Found ScribeNick: ted Found ScribeNick: kaz Found ScribeNick: kaz Inferring Scribes: ted, kaz Scribes: ted, kaz ScribeNicks: ted, kaz WARNING: Replacing previous Present list. (Old list: Shinjiro_Urata, Junichi_Hashimoto, Tatsuhiko_Hirabayashi, Kaz_Ashimura, Adam_Abramski, Paul_Boyes, Yinying_Chen, Qing_An, Kevin_Gavigan, Adam_Crofts, Peter_Winzell, Ted_Guild, Wonsuk_Lee, Daisuke_Ajitomi, Hidenobu_Ito, Kosuke_Nagano, Toru_Kawaguchi, Mikio_Sasaki, Jet_Villegas, Hiroto_Inoshita, J_Alan_Bird, Junichi_Sakamoto, Hirotaka_Kajita, Shintaro_Uchida) Use 'Present+ ... ' if you meant to add people without replacing the list, such as: <dbooth> Present+ Shinjiro_Urata(ACCESS), Junichi_Hashimoto(KDDI), Tatsuhiko_Hirabayashi(KDDI), Kaz_Ashimura(W3C), Adam_Abramski(Intel), Paul_Boyes(OpenCar), Yinying_Chen(W3C), Qing_An(Alibaba), Kevin_Gavigan(JLR), Adam_Crofts(JLR), Peter_Winzell(MELCO), Ted_Guild(W3C), Wonsuk_Lee(ETRI), Shintaro_Uchida(AptPod), Hirotaka_Kajita_(AptPod), Junichi_Sakamoto(AptPod), Daisuke_Ajitomi(Toshiba), Hyejin_Lee(HTML5_Convergence_Forum), Hidenobu_Ito(Fujitsu), Kosuke_Nagano(ACCESS) Present: Shinjiro_Urata(ACCESS) Junichi_Hashimoto(KDDI) Tatsuhiko_Hirabayashi(KDDI) Kaz_Ashimura(W3C) Adam_Abramski(Intel) Paul_Boyes(OpenCar) Yinying_Chen(W3C) Qing_An(Alibaba) Kevin_Gavigan(JLR) Adam_Crofts(JLR) Peter_Winzell(MELCO) Ted_Guild(W3C) Wonsuk_Lee(ETRI) Shintaro_Uchida(AptPod) Hirotaka_Kajita_(AptPod) Junichi_Sakamoto(AptPod) Daisuke_Ajitomi(Toshiba) Hyejin_Lee(HTML5_Convergence_Forum) Hidenobu_Ito(Fujitsu) Kosuke_Nagano(ACCESS) Toru_Kawaguchi(Panasonic) Mikio_Sasaki(Mitsubishi_Electric) Jet_Villegas(Mozilla) Hiroto_Inoshita(Keio_Univ.) J_Alan_Bird(W3C) Cheon_Kwan_Ho(HTML5_Convergence_Forum) YooJoo_Yeol(HTML5_Convergence_Forum) David_Singer(Apple) David_Rogers(Copper_Horse) Rigo_Wenning(W3C) Ann_Bassetti(Boeing) Ann_Bassetti(freeagent) Kenji_Kouno(Kyocera) Tobie_Langel(IE) Jeff_Jaffe(W3C) Marie-Claire_Forgue(W3C) Karen_Myers(W3C) Got date from IRC log name: 26 Oct 2015 Guessing minutes URL: http://www.w3.org/2015/10/26-auto-minutes.html People with action items:[End of scribe.perl diagnostic output]