Best Practices

From Automotive and Web Platform Business Group

In-Vehicle Application Best Practices

Organizing space for best practices for in-vehicle services VISS version 2, potentially the Vehicle Service Catalog (RPC interface under development with COVESA). Applicable to OEM specific in-vehicle APIs.

The intention is to take these notes and publish a formal document either within W3C or COVESA Security Expert Group.

Problem statement

The purpose in creating an in-vehicle application best practice document would be to facilitate conversations with prospective partners and application creators, defining reasonable behavior and clearly providing enforceable parameters of what is reasonable and permitted.

Standard and proprietary APIs exist for allowing application to reside and operate in the vehicle, accessing and potentially setting various underlying signals and calling functions. These API act as an enabler for interoperability but even with security and privacy considerations as part of their design, do not sufficiently address the range of concerns raised by various stakeholders. Nor do these APIs define constraints beyond interactions with it directly. As such expectations are not properly set, adequate protections not provided nor are underlying computing resources appropriately regulated.

We hope to define practices that take into account the perspectives of different stakeholders in connected vehicle space. We feel many of the concerns from these sometimes opposing sides can be addressed, enabling tremendous innovation and interoperability opportunities.

W3C+GENIVI Common Vehicle Interface Initiative (CVII) activity includes a common data model and standard API that resides on vehicles. Where possible these Best Practices are generalized and not specific to this standard so these conventions can be used more broadly. This data model and API can be used multiple ways and is but a component in a wider telematics ecosystem. This document will address some concerns for this larger landscape. Where appropriate. Certain topics that are already well covered by other initiatives, will be referenced and drawn from.

This document is expected to evolve as the conversation continues. Feedback welcome @@link to github issue.

State of Practice

Vehicles have evolved into networks of miniature control units many with embedded logic, sending and receiving signals information. Since at least the mid 1990s with General Motors' OnStar, that information has been leaving the vehicle and sent to internet servers. Today most automotive manufacturers have their vehicles connected, bringing data to the cloud. Aftermarket devices are also widely deployed, installed in vehicles and sending information directly to telematics data service providers instead of to servers managed by automotive manufacturers.

How the information is used varies.

Some share limited data with their suppliers and partners. Some are making aggregate data available since raw, individual vehicle data is too sensitive. Attempts to remove any private personal information are problematic as various, seemingly innocuous data points could provide fingerprinting capability.

With General Data Protection Regulation (GDPR), California Consumer Privacy Act (CCPA), Right to Repair, Electronic Logging Devices (ELD) and Remote Fleet Management System (rFMS) for commercial vehicles and numerous other existing or emerging legislation in different parts of the world, the legal nuances of using information is complicated. Diametrically opposed stakeholders are lobbying to protect or enable sharing of various information.

Many telematics data providers, automotive manufacturer or independent, are managing ongoing owner consent through interfaces on the vehicle or through a paired application or website. Some address data rights in sales agreements, employment contracts, insurance policy opt ins and others are perhaps too permissive in their interpretation of data rights.

Not surprising given the political and legal challenges, much of the information is under or even unused.

Besides deliberate, intended telematics data use sent over virtual private network (VPN) protected cellular data connections, vehicle emit data.

Unlike laptops, smartphones and other connected devices, vehicles are heavily regulated. They generally must be registered with a publicly visible unique identifier in the form of a license plate. In many parts of the world vehicles must be routinely inspected for safety issues and insured since they are capable of causing property or bodily damage.

It is possible to fingerprint a vehicle from the collective radio frequencies signature (Bluetooth, WiFi, NFC, RFID, Tire Pressure Monitors) of its components. This is actively being utilized in lieu of or in addition to utilizing automated license plate readers (LPR). While some of the efforts by law enforcement to utilize LPR have been met with civil liberties challenges, license plates are regularly recorded by cameras at toll booths, security cameras and automated traffic light and speed enforcement to name a few. There are no restrictions for private use of LPR. Make, manufacturer, color and other characteristics are visibly observable external to the vehicle including occupants and their appearance.

Cellular carriers providing internet connectivity to vehicles can infer considerable information in addition to location without accessing the data that flows through it.


Benefits

@@uses, benefits of data to individuals and humans in aggregate

inhibiting @@landing or similar@@ revenue potential use/misuse of data


Some of the areas this vehicle information can innovate:

  • System monitoring and fuel optimization
  • In-vehicle infotainment
  • Predictive maintenance
  • Route and trip planning
  • Road and infrastructure condition monitoring
  • Passenger and Public safety
  • Traffic management and smart cities
  • Ride sharing and multi-modal mobility
  • Fleet management
  • Data-driven insurance


License Plate Reader

Constraint Areas

Areas where constraints (information, system, connectivity) can be clearly defined and in most cases enforced by underlying systems. Deviation deems an application suspect of being compromised and part of criteria for disabling, incident reporting app to marketplace security administrators.

Hardware

Topic editors: Primarily leverage and point to external resources


Hardened enclave apps run on, see Ben's doc@@

Host OS

Topic editors: Primarily leverage and point to external resources

These should be covered elsewhere but worth stressing some and linking to good security hygiene practices.

Ensure libraries are current wrt security updates

Do not permit applications to maintain their own dependencies, eg perhaps don't allow Docker/DLL model although some argue in favor of containerization. #TG to talk to NYU researcher

Signal Access

Topic editors: Isaac, Ulf

Permitting an application to reside on a vehicle should not allow it to read much less write arbitrary signals, and even less so if it is residing off the vehicle, in the cloud or on a nomadic device. The reasons to restrict access range from operational safety to personal privacy and may include business decisions or legal concerns of the auto manufacturer. A rogue application should not be able to deploy airbags for instance when a vehicle is in motion. Having the set of signals a given application would be allowed to read, and which if any can be written, should be clearly established in advance before installation, reviewed and approved by the automotive manufacturer or provider operating on its behalf. The reason to have granular access control for individual signal read and write is a trade off between efficient signal accessibility and the mentioned reasons for safety, privacy, and cybersecurity perspectives.

Polling Frequency

Topic editors: Ted, Ulf

The frequency information is accessed on a vehicle or sampled and made available from the cloud can have privacy, safety, reliability and efficiency ramifications.

An application residing in-vehicle permitted to request specific signals should not necessarily be permitted to do so whenever it wants. Requesting signals too frequently, incessantly may overtax and interfere with the operation of the underlying control units involved, inhibiting their ability to perform their primary designated tasks. This is particularly concerning when critical operating functionality is at stake. It may also result in premature unit failure and subsequent warranty issue. The second version of VISS API specification, the service residing in the vehicle, makes clear the service may limit frequency of information availability to prevent these issues. VISS also has a number of mechanisms for subscribing to information streams based on time interval, delta differences and so forth**. Application developers should take a minimalist approach and be clear in their needs and expectations. Configuration can accompany an application governing the rate it is permitted to access signals in addition to the service following any internal policies governing rate information is made available.

As with many of the considerations in this best practices document, deviation from expected and expressed behavior should be detectable by monitors and factored into basis of a decision whether or not to suspend the application, flagging it as having a potential bug or perhaps being manipulated maliciously as part of an attack.

Lower degree of precision of specific data points, frequency or timeliness can affect the sensitivity of the information as well. Location information for example can be less sensitive if providing general vicinity, province or country instead of actual location. Delayed or lower number of data points can reduce or eliminate real-time tracking.

@@fingerprinting explained

Sampling and off-boarding data at fixed intervals can be inefficient, needlessly sending the same or similar information that has not changed meaningfully enough for a given use case. More intelligent sampling for given purposes reduces bandwidth consumption, local and cloud storage needs and associated costs.

Underlying CAN signal limitations

SAE J3005-1 section 3.3 - on point to frequency of data polling in CAN Bus...The recommended general sampling frequency per PID, if not otherwise stated, is 2 Hz for dynamic data, which means oversampling and static information should only be requested once per operation cycle. Data which will not change rapidly (e.g., barometric pressure, ambient air temperature) can be requested at lower frequency. Rapidly changing data can be sampled at higher sampling frequency, depending on the use case, but the sampling period can not be guaranteed. The reason for the low sampling frequency is that the in-vehicle data bus should not be overloaded, but also to ensure that the device gets data at fixed points (fixed sample rate). The theoretical maximum sampling frequency is 20 Hz for single frame messages based on P2 timing = 50 ms; for segmented messages, the sampling rate is lower and fixed sampling time can’t be guaranteed.

Computing Resources

Topic editors: Ted

Computing resources (CPU, memory, storage) available within the vehicle is confined. There will be interest in OEM and partners to run applications within this shared computing space. Applications can and should be benchmarked in the computing environments they will operate on in order to be able to observe resources used and define limits for what they can consume. In turn this will provide approximations on number and size of applications that can run concurrently and prevent creating too much load which would bog down the system and adversely affect other applications. In Linux and UNIX operating systems for example this can be achieved with ulimits and other mechanisms.

@@multiple business model, example[s] different stakeholders willing to cover costs or even pay vehicle owner for collecting data

@@OEM moving away from Sirius XM model, at least partially, for connectivity costs but embedding in sales price since they want data themselves and means to do SOTA. They may still sell services or limit bandwidth unless a higher subscription model exists.

@@rework or strike following paragraph

This best practices document focuses on the technical issues and steers clear of political, financial and business topics. That said, there are third parties trying to insist on being permitted to run applications in vehicles at no cost when there are obvious capital investment, opportunity costs that translate to potential lost revenue and incremental operational costs.

The computing resources themselves are capital investments OEMs need to make in the production of their vehicles. Allowing third party applications to run in this environment presents an opportunity cost for the OEM of being able to run their own applications. While outside the scope of this best practices document, following a cloud computing business model charging reasonable and non-discriminatory operational fees would help not only recoup the investment cost but potentially provide revenue incentive for permitting third party applications to operate.

Architecturally, the in-vehicle service exposing signals should reside on a separate virtual or physical host than the applications. The service as well will want to govern the number and which signals an application can sample and frequency utilizing access control and rate limiting as is widely employed by servers on the web. A separate, paired device such as a smartphone may be permitted to connect to the vehicle service can manage its own computing resources but still needs to be aware of service resource consumption.

System Resources

@@fold in Host OS into this topic

Is an application allowed to use memcache or local filesystem storage. What system libraries can be called or any local system files accessed.

  • other interactions within the host system
  • how to instruct underlying systems to subscribe to specific signals and sampling requirements at boot for eg maintenance apps

feel free to add to list and/or take one and expand on it below

Discourage code porting of applications and libraries or at least architecture reconsideration, removing unneeded functionality.

@@libraries should be configured to compile with only the features desired to be exposed and not kitchen sink as those added but unused features provide misuse opportunities.

should be "Automotive Grade" applications

@@reiterate application behavior monitoring for bugs and abuse, probably needs its own chapter.

Network Connectivity

Topic editors: Ted, others

Allowing an application to make a connection to the outside world presents a potential attack vector and information being sent off potential personal privacy and data usage concerns.

If an application is allowed to make internet connection at all should be established in advance. When it is, to who should be known explicitly. This can be used by firewalls or other system restrictions. DNS zone files or advanced caching local name servers can be used to not only avoid the lookup overhead but prevent various related attacks and provide IP addresses for firewall rules.

All network connections should be encrypted via TLS or stronger encryption. Defer to @@@ Another optimization similar to having predefined DNS zone files for external parties' servers would be to have locally installed public key certificates. This would again prevent various common and emerging attacks and negate need for external certificate authority verification, saving time and minor reduction in network traffic. It would be worthwhile to do network based verification to ensure host isn't compromised and eg /etc/hosts isn't modified.

(see if people agree with any of these example ideas or have alternatives)

    • make environments unique, not just certs per vehicle, checksums, mac addresses of other components can be used as seeds

Push vs Pull

Scope considering likely out of scope initially, can steer towards gh issues

Current industry and better practices, contrast benefits

  • SMS wake-up
  • Open port on vehicle an attack vector
  • Port firewalling or VPN increases cellular cost
  • Cellular provider setup compromise exposes full connected fleet
  • Workarounds for full duplex communication
  • Reduce polling of offline vehicles

Bandwidth

"Every Byte Counts"

Vehicles have sporadic connectivity due to cellular reception coverage. Bandwidth has incremental operational costs based on usage. Similar to computing resources there is again the opportunity cost of trying to transmit other data and expect parties involved to be able to negotiate reasonable terms for cost recovery or even generate moderate revenue based on prioritizing data transmission, based on timeliness, volume etc.

The W3C Automotive Working Group is discussing and will evaluate various serialization, compression, sampling methodologies and other means to make data transmission more efficient.

Leverage previous presentations to group and seek specific contributors

May need multiple strategies and scale down based on connectivity, dropping data points less relevant when stale or if not needed realtime to batch for when connectivity is improved or connected to office/mechanic/home wifi.

Serialization & Compression

  • Protobuf from VSS
  • Ulf's mapping
  • EXI
  • Larger datasets can compress considerably better if sending batches

Privacy

Privacy is a prevailing topic throughout, worth making some high level statements as well as having internal anchors to privacy subtopics addressed elsewhere

Consent

While the debate continues in the automotive industry about data ownership, we are focused on data rights.

Whoever is deemed authoritative through property law, regulations, contractual agreements to be able to @@@

Location & Geofencing

see also RPC Geofencing use cases

Location is potentially the most personally sensitive information a vehicle may have either standalone or in conjunction with other data points. Unless explicitly needed for further off-board processing, it should not leave the vehicle. On-boarding assessments, analysis that takes place within the vehicle, can convey for example a vehicle was speeding in a residential zone without revealing the actual location.

Geofences (zones) are used to explicitly define where certain vehicle data or capabilities are exposed or omitted. Data may only be collected in certain areas in addition to time of day, explicit user consent and other parameters. We recommend allowing users and data owners to define geofences for including or excluding data collection along with additional governing parameters and to keep geofence definitions simple, geometric shapes.

The W3C Auto group asked the Spatial Data on the Web group (a coordination activity with Open Geospatial Consortium) whether they had standards to recommend defining geofences. While some work is taking place, we learned of increasingly complex ways to define these zones and were encouraged to keep it simple. We have subsequently learned how at least a couple group participants (BMW and Geotab) both currently use geofencing in their service offerings, how it is kept to geometric shapes (polygons and circles) and leverage existing software libraries. Action Ted to learn more about what libraries are used and how fences are represented so we may be able to point to explicit conventions if not standards.

Off-boarding Data

Topic editors: Ulf, Ted plus subtopic editors

Consent Management

Move or reiterate and elaborate on consent from 'state of practice' section. State of art and what can be done with consent and revokation@@@ on IVI, Android Automotive has localization, voice interaction etc.

Some jurisdictions (eg China) will not provide consent management

Profiles

consent tied to profile of operator (passengers only when we move to AV)

anonymous profile - esp for passengers


In addition to privacy considerations, there are other legitimate reasons for restricting what data can be off-boarded. What can be sent off may be a subset of what an application can evaluate within the vehicle. Sometimes assessments have more meaning and value. Data can be both an asset and liability for OEM and independent parties collecting it.

Vehicle internal networks typically have a safety critical domain that is separated from other parts with a single gateway for passing data between the domains. A Web Application Firewall for example could be employed to inspect and ensure what data is being sent off the vehicle.

Securing backend, once off the vehicle in the cloud how to prevent data breaches

Providing data to 3rd parties

Topic editors: Glenn, Ashish, Isaac

The area of data usage and privacy is of broader concern than just automotive. For a best practices document we will want to leverage, reference or defer to other resources such as the W3C Spatial Data on the Web Responsible Use of Location Data, regulations in EU, NA (such as GDPR and CCPA) and elsewhere and make some broad suggestions, encouraging capturing explicit consent on what data can be shared with which parties for what purposes.

Either from vehicle directly or give directive to telematics provider in the cloud

See also @@LPL discussions from past.


Explicit use cases:

  • EV2grid
  • independent garages
  • insured driver evaluation
  • data access edge cases
    • data provider and/or trust authority needs to provide access for subpoena
    • user may be open to defining some criteria and conditions for sharing information, enough for trust authority to make decisions instead of specific requests (onerous for user)
    • need for realtime data sharing with no-store policy - eg report road warning

Proposals

Differential Privacy

https://en.wikipedia.org/wiki/Differential_privacy

@@Ashish influenced by a recent article he read on Google Differential Policy library.

The open-source Google's differential-privacy library can be found at: https://github.com/google/differential-privacy

Differential privacy can help quantify privacy by measuring how much privacy is provided and how much utility is lost (more noise in data = reduced utility).

Sticky Policy

Topic editors: Ashish

User data flows across organizational boundaries, service providers (SPs), third parties, etc. It is important to ensure that the privacy rights and preferences of a User/Data Subject are maintained even when the data is shared with other third parties, especially since the implementation of GDPR in Europe and other such laws around the world. To do this effectively, having a machine-readable policy that can stick to data at all times can be a good practice to follow. The sticky policy defines allowed usage and obligations as it travels across multiple parties, enabling the user to improve control over their personal information [1].

A sticky policy could be used to specify the following:

(a) proposed use of data

(b) obligations and prohibitions

(c) blocked service providers

(d) Trusted Authorities (TAs)

Note: A trusted authority is an organization that provides assurance to the "Data Subject" by keeping track of promises that involved parties make to access data, along with controlling access to such data. [2]

Data security

Need for encrypting data in transmission or directly including how it will be stored in the cloud and redistributed. PRE is one way of doing so to expand as a potential solution.

Proxy Re-encryption

Topic editors: Isaac

Proxy Re-encryption (PRE)

Materials Isaac shared on PRE

minutes 2021-01-11 minutes 2021-01-12 minutes 2021-01-25


Some feel PRE may be 'overkill' in protecting sensitive information, however at present they tend to be the soul holders of the data and tend to not make raw data available to third parties. PRE provides the data provider considerable protection again compromises and exfiltration of personal, sensitive information which is a financial and reputation risk, notable GDPR fines have been imposed for inadequate protection. PRE also provides the data owner (vehicle owner, fleet operator, etc) with ability to share data with designated third parties, securely after it is collected. Clear consent and ability to impose policies with technical mechanisms will facilitate establishing marketplaces and uses of otherwise encumbered data.

PRE Use cases
  • share data with owner's insurance company
  • share data with owner's mechanic
    • allow mechanic to subcontract or seek consultation necessitating resharing data
    • allow re-sharing data with vehicle manufacturer
  • share data with servicing company (annual test of vehicle safety, roadworthiness aspects and emissions)
  • share data with vehicle manufacturer

Commercial vehicle

  • share data with third party company using the fleet?

Data Verification

Topic editors: Arman

How reliable is the data and why it matters? If we take the case of post-incident forensics, the reconciliation of various data inputs, and the verification of the data integrity (that it has not been manipulated afterwards) is the most costly and time consuming. So having a single version of the truth, with an independently verifiable data set, can offer a tremendous cost efficient value.

The data coming out of the vehicle can only bring value if it is reliable. Unfortunately, key management makes it very difficult and costly to encrypt all the data, and does not prevent false data injection. A zero trust approach means that any one should be able to independently verify the data, without compromising the privacy of that data. A keyless signature allows a hash to be created and added to a blockchain, providing a cryptographic integrity verification that would guarantee the authenticity and immutability of that data. This would allow anyone to validate the reliability of the data without releasing its content.

This cryptographic integrity can be augmented with an additional layer of security: provenance and compliance. If each component or software providing data is signed as well (digital twin), and if the component or software is compliant, then both provenance and compliance can be included in the data hash. If you define policies, these can potentially be checked in real-time and become cryptographically enforced. For exemple, if an “unsigned” equipment is installed during a repair, the owner would be notified about the implication of using a third-party equipment that can’t be verified (with the risks that it implies). This would also prevent the owner from unwillingly installing a “counterfeit” part.

Using such a dynamic attestation of compliance could potentially reduce the time to detect issues, decrease drastically the operational costs (fleet owners or car manufacturers can narrow down the vehicles at risk), and provide accountability with auditable compliance. A cost efficient risk management that would not be possible without a verifiable data reliability.

IoT interactions

Topic editors: defer initially, reach out to WoT, BMW others at later document stage


Question arose in call if IoT should be in scope for BP document? If so, worth coordinating with Adnan and/or Daniel plus perhaps Sebastian Seimens / WoT chair. Probably worth checking out if they are including any constraints in addition to enabling interaction beyond mere authentication/authorization.

Whether and how a vehicle could/should interact with other IoT devices.

In-vehicle aftermarket devices

Topic editors: Ted to try to enlist eg RJ from US DOT and/or someone from Geotab, external resources

Will largely reference and defer to external resources but need some high level framing on topic.

This is likely a political issue, OEM may not want to allow for replacement and additional parts to be able to produce signals that can be aggregated and exposed for in-vehicle or off-board purposes via VSS/VISS although the architecture should be able to accommodate. There are clearly advantages to using same structure and mechanism for exposing additional data alongside VSS.

Example TPMS with microphone in addition to pressure sensor. Considerable road safety, fuel efficiency advantages (detect alignment, balance etc issues), preventive maintenance can be achieved if tire manufacturers were able to access existing signals in VSS (eg assess tires after hard braking event or major bump registered via shock absorbers above certain speed threshold) if permitted to run logic in vehicles.

  • dashcams
  • tpms
  • other sensors - road/weather conditions

Application Certification

Topic editors: Isaac?, Ted, Arman?


@@cybersecurity and manufacturer liability angles cf Deborah, Christos and Danny

Given the serious security ramifications and corresponding safety implications, we would like to see independent application evaluation and certification including code inspection.

Ted to talk to US DOT on RATES and related projects, maybe enlist RJ to contribute directly**

One of the advantages to a standards based solution is that applications will be written to a common API instead of manufacturer proprietary ones. With the potential to run applications across multiple brands of vehicles, those applications will be subject to wider review. In addition to automotive manufacturers' cybersecurity teams evaluating applications being considered to run on their, it is advisable to seek independent review. With explicit and evolving evaluation criteria, independent reviewers can assert compliance of applications handling known concerns. Certification of this compliance provides automotive manufacturers and the application marketplace operators if outsourced, provides assurances to augment their own cybersecurity evaluations, will prompt reevaluation and ongoing compliance as additional concerns are identified and added to the certification process. Certification costs would likely be offset by lower cybersecurity insurance premium discounts. Application runtime environments can be similarly audited, reviewed and certified.

Independent entities can be entrusted under NDA to view code being run in addition to penetration testing. Application developers could receive reports, advice on rectifying issues and given the opportunity to address and submit for reevaluation.

Accessibility (A11y)

Topic editors: Ted to enlist expert contributions from WAI, researchers, etc

Collaborating with the W3C Web Accessibility Initiative (WAI) Accessible Platform Architectures (APA) to help determine scope, will have a breakout session at TPAC 2021.

Received some input from wheelmap.org participants in the Linked Data for Accessibility Community Group and interest in future coordination.

The In-vehicle Application Best Practices document should seek to promote overall awareness of accessibility needs and use cases for data, applications and after market devices. We strongly encourage independent a11y testing of any application if it has any direct human interaction be it on the head unit (IVI system), smartphone, web or other. Specifically we should seek concrete suggestions on existing standards, guidelines and other resources to draw from and point to.

While autonomous vehicles have tremendous potential for increasing individual mobility, accessibility needs seem to be often overlooked.

Potential Areas of scope:

  • User interfaces
    • need specific ADAS, eg assist with cognitive object recognition read out, road conditions vs speed...
    • physical controls - increasingly giving way to touch screen interfaces, often without adequate accessibility considerations (vehicle head units a mix of Android Automotive, QNX, other)
    • individual profile preferences that may alter controls, other preferences recognizing individual from presence of key fob, personal device, stored on vehicle or conveyed through cloud
      • this is intensely sensitive personal information and recognized as such under UN treaty (Article 22?)
      • better to provide desired/required features/requirements for driver interaction and vehicle capabilities than individual needs as a means to somewhat obfuscate
    • aftermarket adaptive/assistive controls - increasing becoming more complex despite right to repair legislation
    • alternate/customized applications running from screen on head unit
    • increase awareness of WCAG2.0, other applicable WAI guidelines, resources for UX designers
    • voice interaction
    • adaptive - eg visual alert when recognizing siren, horn for assisting with hearing impairment
    • paired device capabilities with either OEM provided applications or API that adaptive applications can interact with and provide alternate UI
    • trunk, door opening assistance
    • software or remote human assistance for replacing some ride hailing interactions or even controlling [autonomous] vehicle
  • particular emphasis should be placed on Autonomous Vehicles, ensuring they enable operators with different needs and take those into consideration for puck-up/drop-off locations and conventions
  • Information centric
    • consent capture and revokation needs to be conveyed clearly and concisely, providing alternate means, not impose captcha...
    • Rideshare hailing needs to take into account accessiblity features/preferences
    • beacon - vehicle emit sound or data on its presence and direction. better to mainstream solutions instead of putting responsibility on
    • responsible use of personal assistive needs data
    • Data sources cf Linked data for accessibility that can be brought into vehicle concerning physical characteristics of surroundings - eg curb ramps

https://github.com/schemaorg/schemaorg/issues/254

Policy Language

Consider viability of aligning in-vehicle best practices with a policy language to define machine enforceable details on how an application can behave in a given vehicle. There may be policy variation by manufacturer, computing and bandwidth capabilities and other factors such as party the app is being called by (owner, driver, mechanic).

Deviating behavior outside of the established boundaries of an application's policy would be monitored, reported and result in disabling application until further forensics can take place. Reporting an incident from a single vehicle back to OEM or service providers they utilize can be used to detect potentially compromised applications. This can be used to temporarily disable the application across their entire fleet to prevent widespread vehicle compromises.

An application's policy would be part of its package manifest along with additional configuration for the given vehicle platform, the code itself (no code should not be retrieved imho at run time), content such as images, dependencies, firewall (regular network and Web Application Firewall) rules, rules for SELinux, AppArmor and Smack.

If there were more continuity across manufacturers, simpler configuration files could be utilized instead of somewhat more complex policy language representations. The policy language pertaining to a given application will likely be translated into multiple configuration files or interpreted and directives given to different enforcement systems at install time.

A policy language is not only machine interpretable and therefore enforceable but understandable by humans and even translatable to legally binding contracts between OEMs and third party application providers. This can apply to the data being off-boarded, including limitations to the data's use and redistribution by third parties.

Reading list

Some suggested readings, relevant contributions welcome

Several of these likely to be referenced in our best practices document

Coordination

Groups and individuals to seek input from

  • W3C Spatial Data on the Web group will be producing Responsible Use of Location Data Best Practices
  • University of Memphis, Christos Papadopoulos
  • University of Maine - Nicholas Giudice, Tiffany Rad
  • W3C MiniApps CG
  • US DOT Volpe - Kevin Harnett, Graham Watson, RJ Rittmuller
  • NMFTA - Ben Gardiner
  • UL - RATES project
  • Colorado State University - Jeremy Daily (CyberTruck challenge)
  • University of Passau, Armin Gerl & Ashish Ashutosh
  • NIST
  • Ford - Mike Westra
  • Auto ISAC
  • Thomas Roessler at Google, see if he can connect us to Android Automotive
Retrieved from "https://www.w3.org/community/autowebplatform/wiki/index.php?title=Best_Practices&oldid=750"