Copyright © 2024 W3C® (MIT, ERCIM, Keio, Beihang). W3C liability, trademark and permissive document license rules apply.
Hit 't' to change languages.
この文書はW3C Vehicle APIs (Vehicle Information Access API, Vehicle Data Specification, Vehicle Information Service Specification) を実装・運用するにあたって留意すべきセキュリティーとプライバシーについて述べたものである。 この文書ではVehivle APIを備えたIVI (In-Vehicle Infotainment system) を想定して、典型的な構成、参照すべき勧告、プライバシー保護について示し、 またAPIの利用を特定のコンテンツ提供者に制限するためのベストプラクティスについて述べる。
This document describes security and privacy consideration for implementing and utilizing the Vehicle APIs (Vehicle Information Access API, Vehicle Data Specification, and Vehicle Information Service Specification). This document supposes an IVI (In-Vehicle Infotainment system), and presents a typical architecture, recommendation to be referred and privacy protection. It also describes best practices for restricting API use to specific developers or application
なお、本項は網羅的なリスク評価を行うものではないことに留意する。 その代わり、特に注意が必要な点について議論する。
This document does not provide a comprehensive risk assessment for IVI with Vehicle APIs. Instead of that, this document discusses points that required special attention.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
This document was published by the Automotive Working Group as a .
Comments regarding this document are welcome. Please send them to public-auto-privacy-security@w3.org (archives).
Publication as a does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 1 March 2019 W3C Process Document.
Automotive WG は乗用車の IVI (In-Vehicle Infotainment System) への実装を想定して、 Vehicle Access API, Vehicle Data Specification, Vehicle Information Service Specification を策定した。 これらのAPIは車に直接アクセスするインターフェースではないが、表現がくどい 間接的にセンサーデーターを取得したり 制御のリクエストを行ったりする方法を規定している。 PC向けではないこれらのAPIに特有の課題を調査・検討するために Security & Privacy タスクフォースが 設置された。 この文書はそのタスクフォースの成果をまとめたものである。
For the use on passenger car's IVI (In-Vehicle Infotainment System), Automotive WG published three specifications: Vehicle Access API, Vehicle Data Specification, and Vehicle Information Service Specification. These APIs are not a direct interface that accesses car system but an indirect interface that obtains sensor data or changing values by sending requests. In ordered to investigate domain specific issues that may be caused by these non PC-oriented APIs, Security and Privacy Task Force was formed under the working group and business group. This document reports the result of the task force's study.
車にとって最も大切なことは利用者の安全であり、Vehicle APIsやそれが実装されたIVIが この安全性を損ねるものであってはならない。 そのため、この文書はAPIの実装にかぎらず、IVIの構成自体にも言及することになった。 2節ではタスクフォースが収集したAPIのユースケースと懸念点を列挙する。 3節ではIVIの構成や、置かれる環境、Webランタイムとアプリケーションの関係についてモデルを示す。 4節では標準的に利用されていて、車向けのIVIにも導入すべき基礎的なWebのセキュリティー技術について述べる。 5節では最初に抽出した課題への対処方針を示す。 6節にはwebと車、セキュリティとプライバシーに関連して現在取り組まれている活動を紹介する。
Primary concern of automakers is the safety of passengers. Vehicle APIs or IVI that implements the APIs should not compromise safety. Hence, this document focuses on not only API implementation but also IVI design. Document structure is as follows: Section 2 lists up API use cases and concerns that the task force has collected. Before discussing each concern, section 3 provides a model architecture of IVI, IVI environment and composition of the web runtime and applications. And section 4 introduces fundamental web security technologies which are commonly supported on today's browser and should be supported on IVI as well. Then section 5 extracts requirements from the use cases and shows strategies to tackle them. Finally, section 6 gives an overview of on-going activities that are taken for web, automotive, security and privacy.
この文章は、セキュリティーとプライバシー上の懸念について取り扱い、解決の方向を提示する。 一方でリスクの評価を提供したり、この文書に従うことで問題が解決することを保証したりするものではない。 詳細なリスクの評価は実装者に委ねられており、不明な場合は安全な側に倒すことを推奨する。 また、IVIのハードウェア要件や、全体の設計を提供することも行わない。 そういった観点では、以下に示す規格を参照することを勧める。
This document focuses on security and privacy concerns and provides strategies to tackle them. It does not provide a certain risk assessment or endorses that conformance to this document solves thease concerns. Implementer should perform a precise risk assessment and must err on the side of caution. Also this document does not provide hardware requirements nor an entire design of IVI. For these purpose, we recommend to refer more general specifications:
Conformance requirements are expressed with a combination of descriptive assertions and [RFC2119] terminology. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and " OPTIONAL" in the normative parts of this document are to be interpreted as described in [RFC2119] However, for readability, these words do not appear in all uppercase letters in this specification.
All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]
Automotive WGではVehicle APIsの策定の仮定で、将来的な拡張を含めどのようなユースケースが想定され、 また懸念される事項が何であるか調査を行った。下記はそのリストである。
On the process of Vehicle APIs formulation, Automotive WG has investigated use cases and concerns that would be brought by current APIs or the future revisions. Following is the summarized item list.
これらのアイテムはコネクティッドカーに対する自由な期待に基づくものであり 規格としての要求事項を定めるものではない。 また API 規格が各項目の実現性を保証するものでもないことに注意する。
Note that the items come from free expectation for connected car and does not define requirements. Also API specifications does not guarantee that each item is feasible.
以上の様に Vehicle APIs への期待は IVI への期待であり、 寄せられた懸念に対してはユーザーエージェントのみならず、 IVIのシステム全体として対策を検討する必要があることがわかった。 以下ではまず、議論の前提として想定するモデルアーキテクチャを定め、 セキュアなWebサービスを構成するために標準的に利用されている他のW3C勧告について概観する。 Requirementsという言葉、５章の位置づけに触れる。 その上で、ユースケースを整理して得られた課題について対処方針を検討する。
As described above, the expectations are not limited to Web APIs and the concerns should be treated in IVI system rather than API implementation. In the rest of this document, we provide a model architecture of IVI first and introduce fundamental W3C recommendations that supports web securities. Then we discuss issues that are derived from above list.
この節ではAPIが想定する抽象的なアーキテクチャを示す。 より詳細なモデルは例えば[GENIVI]や[AGL]が提供している。AGLの方のモデル図
This section provides a model architecture that Vehicle APIs expect. The readers could refer [GENIVI] or [AGL] for more precise architecture.
まず、IVIは図1のように、 インターネットとCAN(Car Area Network）の双方にアクセス可能な環境に置かれる。 通常、アプリケーションはインターネットから得られ、IVI上で実行される。 アプリケーションはVehicle APIsを通して車両の情報を取得する。 アプリケーションはこれ以外の方法で車両の情報にアクセスすることはできない。
Fig. 1 shows that an IVI is located where it has access to both the internet and CAN (car area network). Typically, a web application is downloaded from the internet and executed on the IVI. The application obtains car information via Vehicle APIs and it does not have any other way to access car information.
IVIは、ベースとなるOSとその上でWebアプリケーションを動作させるWebランタイムからなる。 Service specの実装では更にローカルサーバーが置かれる。 この文書ではhtml/js/cssの記述に基づいてUIを提供し、プラットフォームに リクエストを送るモジュールをWebランタイムと呼ぶ。
An IVI consists of an operating system and a web runtime that executes web applications. Vehicle Information Service specification requires a local server as well. Web runtime in this document stands for a module that provides UI and sends requests to OS according to a given html/js/css description.
アプリケーションには図2のような幾つかの形態が考えられる。
Fig. 2 shows possible application types.
Webviewベースのアプリケーションは、 APIを利用するコードが予めデータとして一つのパッケージに収められている点に特色がある。 Webviewベースの場合、マーケット（アプリケーション配布のシステム）での審査などを活用し、 APIの悪意ある利用をある程度防ぐことができる。 コードが全てアセットとされているわけではないので修正が必要
Webview type applications could have web contents that utilize Vehicle APIs in its package as a part of asset data. For this type of application, the market operator (i.e., the application distributer) could review application and reject them if they contain malicious codes.
Vehicle APIs は車の情報を提供する２つのインターフェースを提供する。 DOM API である Vehicle Information Access API は Normal content と Webview base 形式のアプリケーションに車両情報へのアクセスを提供する。
Vehicle APIs provide car information in two ways. Vehicle Information Access API, a DOM API, provides an interface for Normal Content and Webview type applications.
実装者が Webruntime だけでなく、IVI そのものも開発する場合、 ネイティブアプリケーションにも同様の車両情報を提供したいと考えるかもしれない。 その場合はVehicle Service Specを実装することが望ましい。
If one is web runtime implementer and develops IVI as well, he/she hopes to provide car information in the same manner for all types of application. In this case, Vehicle Service Specification is preferable to be implemented.
以下に挙げるセキュリティー関連勧告は開発者がセキュリティーを検討する上で核となる技術であり、 Vehicle APIsを実装するユーザーエージェントはこれらも必ず実装をしなくてはならない。
Followings are fundamental W3C recommendation for considering web security. User-Agent which implements Vehicle APIs must implement them as well.
開発者は上記を有効に利用するとともに、一般的なサーバーサイドのセキュリティー技術も取り入れることで、 悪意のあるコードがIVIにもたらされないよう留意する。 そのような技術には下記のものがある。
Service provider should utilize above recommendations efficiently and incorporate general techniques of web security so that malicious code cannot be executed in IVI. Example techniques are as follows.
2節であげたユースケースと課題は多岐にわたり、レベルも様々である。 その中で共通して見えてくる車に特有の課題は、システムとデータの健全性をどのように確保するか、 APIの利用を誰が、どのように制限するべきか、データの所有者の権利をどのように守るか といったものである。 この節ではこれらの課題に絞って、その対策方法を検討する。 5.1の中身を少し移動する。
Use cases and concerns listed up on section 2 are vary in both domain and level. We derive three common requirements from them; (1)how to keep health of system and data, (2)how and who restricts API usage and (3)what is the standard policy to protect data owner's right. This section focuses on these topics and discuss strategies for them.
前章で標準的なWebのセキュリティー技術を概観したが、 その正しさはベースとなるプラットフォームに依存する。 この章ではWebランタイムの周辺に目を向け、必要なセキュリティー対策について検討する。
The previous section introduced basic web security technologies. The technologies relies on the integrity of the base platform. This section focuses on the environment where web runtime runs and discusses its security requirements.
外部のネットワークに接続するIVIには外部からの不正アクセスや、意図しないマルウェアの混入など、 PCと同等の脅威が存在する。 これらの脅威に対しては事前の対策とアップデートが重要である。 proactiveが今ひとつ
IVI is connected to networks and there are the same kinds of threats that exist on PCs such as unauthorized accesses or malware intrusions. To protect system from these threats, proactive protection and system update are effective.
事前の対策としては IVIの諸機能を独立したセグメントとして設計し、 不必要なアクセス経路を物理的・論理的に遮断すべきである。 Vehicle Information Service Specification のように、 リクエストを処理するステップを複数に階層分けすることも攻撃を困難にする。 不十分
As for proactive protection, IVI system should be designed as a set of independent modules to prohibit unnecessary accesses in both of physical and logical ways. Vehicle Information Service Specification has a model architecture where a request is passed from application to car through several modules. This multi step architecture makes it harder for a malicious code.
システムの健全性を保つためにアップデートは不可欠である。 セキュリティーホールが見つかった際に速やかなアップデートを行うべきである。 [CVE] は幅広くWebruntimeあるいはOSに脆弱性を報告している。 IVIの開発者はそれらの情報をもとに、 OSを含めたアップデート方法を予め検討しておくべきである。 脆弱性の深刻度を定量化するには [CVSS] を利用してもよい。
System update is critically important to keep system safe from attacks. Once a security hole is found, system should be updated as soon as possible. [CVE] continuously announces vulnerabilities of various OS and web browsers. In several layers such as web runtime, libraries or OS, IVI should be designed to be promptly updatable. The more serious vulnerabilities should be given priority to be fixed. [CVSS] helps to quantify vulnerability impact.
ファームウェア・ソフトウェアのアップデートはシステムの健全性を維持する上で不可欠であるが、 アップデート機構そのものが脆弱性となるケースもしばしば見られる。 ISOは特に車載ソフトウェアのアップデートに関してプロトコルを規定しており、 これを参照して定期的なアップデートを行うべきである。
The process of system update itself often has vulnerabilities and has been attacked. ISO will define an update protocol (x.itsec-1) for software that works on car soon. The protocol could be utilized for system update for IVI as well.
ハードウェアによるセキュリティー向上も利用できる。 [TPM]]はプログラムの署名を改竄が困難な形で実現するもので、 システムの健全性をチェックするために利用することができる。
To check system health is not easy because the checker itself might be tampered. Dedicated hardware helps to do it securely. [TPM] realizes highly anti-tampered electric sign and improves integrity of report that a car would send to a cloud server.
Webアプリケーションは、ローカルのファイルにアクセス出来ないなど、ネイティブアプリケーションに 比べて強い制限を受けており、システムへの攻撃が比較的困難である。 一方でWeb runtime自体が大きく複雑なため、API実装やプラグイン・モジュールにメモリ破壊などの問題が しばしばあり、それらの脆弱性をついたウイルス感染などがあった。
Generally, the capability of web application is restricted; for instance it does not have access to local files. It is difficult for a web application to attack a system compared to a native application. On the other hand, web runtime itself is a huge and complicated software and it has had vulnerabilities such as implementation bugs or memory corruption on its plug-in.
問題のあるアプリケーションを取得しないようにするためには アプリの入手元を信頼の置けるサイトに限定することが考えられれる。 例えば[SafeBrowsing]はブラックリスト方式で マルウェアを配布したり、フィッシング目的のサイトのURLへアクセスを試みると警告を出す。
To prevent downloading a malicious application, system could filter URL from where code is provided. For instance, [SafeBrowsing] provides a blacklist filter that covers hosts that distribute malwares or that are suspected as phishing sites.
URLをフィルタするだけでなく、問題のあるコードを除去することも必要であれば、 ローカルにProxyサーバを置いてサニタイズ処理を行わせることもできる。 Proxyサーバを利用することのメリットはWebランタイムには変更を加える必要がない点である。
Removing malicious code at client side will be a solution if the public filter does not know yet that a site is a malicious one. A local proxy server can be used for such sanitizing task. Because the local server is independent from other applications or modules, the server can be updated without changing web runtime.
車に対しては直接的な不正アクセスの事例も幾つか報告されている。 これらの事例では車に備え付けの無線LANアクセスポイントへの不正ログイン、 偽装された基地局への誘導、 クラウドサーバーへの不正なログインなどが行われている。 IVIのセキュリティはそれらへの依存が少ない形で構成されることが必要である。
There are several security researches that successfully attack car systems from remote. In these studies, vulnerabilities of modules around IVI become first step of the attacks. These modules include wireless access points equipped on car, faked cellular station and cloud servers that authentication have a problem. IVI security should be designed to have less dependency on these modules.
不正アクセスに対する防衛策としては不必要にサービスを開示しないことが基本である。 例えば Vehicle Information Service Specification は Web サーバとして振る舞うが、 IVIの外からのアクセスを想定しないのであれば、受け付けるリクエストをIVI内部からのものに 限定すべきである。 Vehicle Information Service Specification の場合は、Webサーバに適用されるセキュリティー対策を 利用すべきである。アクセストークンの利用などがその一例であり、詳細は同Specのセキュリティー Consideration を参照のこと。上とまとめるか
To prevent unauthorized access, system should expose services only if they are necessary. E.g., Vehicle Information Service Specification defines a local web server but only clients on the same machine need to have access to the server. Therefor the firewall of IVI should reject packets that come from outside. For the VIS implementation, other server side security technologies can be applied as well, The specification describes details.
フィルタを通過し、不正なコードが内部に混入した場合に備え、IVIは下記の機能を持つことを検討すべきである。
In case that a malicious code comes into inside of IVI by passing those filters and executed, IVI should have a functionality that detects abnormal behaviors of application and terminates it.
車から得られる情報は、例えば保険の参考にするなど金銭的な価値を生む可能性がある。 そのようなケースでは悪意を持ったコードが外部から混入しなくとも、 ユーザーがデータがデータを偽装しようとするインセンティブが働く。 あるいは、車から得られる情報が道路の混雑状況などの公共目的に利用されるようになった場合、 いたずら目的のデータがアップロードされる可能性もある。
Data integrity is necessary for some kind of services. ADAS works appropriately based on correct data. An insurance company may make better offer for safer drivers. Public traffic information should not broadcast misinformation. There are incentives to falsify data for monetary value or mischief on these services.
こういった偽装行為を行うためにはIVIに自由にアクセスできる必要がある。 スマートフォンの例を参考にすれば、そのような行為を完全に防ぐことは困難であるといえる。
The previous section discussed protection against attack from outside. But data might be tampered by a malicious end user as well. In the domain of smart phones, OEM tries to keep user away from core functionalities of a device. However it is very hard to prevent attack from user entirely.
Vehicle APIsはプラットフォームが提供するデータが偽装されるケースに対し現在のところ、解決策を持っていない。 このような課題は他のWeb規格との整合性を保ちつつ、今後検討されることが望まれる。 アプリケーション・サービスの提供者はこのような状況を考慮したうえで、取得したデータの取り扱いを 検討しなくてはならない。
Vehicle APIs currently have no solution for the case that data from platform is possibly tampered. This issues will be focused in the future by having consistency with other W3C recommendations. Service providers should take this possibility into consideration and decides how to treat obtained data.
通常DOM APIは実装者が開示したものを、開発者が使用する形式が標準的である。 デスクトップ向けのブラウザでは現在時刻やユーザーの入力、 ページのスクロールなどを開発者は自由に利用できる。 この様な無制限のAPI利用は利用者に不便をもたらしたり、プライバシー上の懸念があったりすることなどを理由に GPS情報の取得など一部のAPIはユーザーのパーミッションを設けられている。
For most DOM APIs, implementers provide an API implementation and developers utilize it with no limitation. Hence developers have access to current time, user input events and page scroll without any permission. This unlimited use can cause user inconvenience or privacy risk, so some API, such as Geo-location API, requires user's permissions.
この他、近年のブラウザでは頻発するポップアップ表示などが検知された際に、 ユーザーに表示を停止するか否か問い合わせることがある。 頻度の高いAPIリクエストには悪意がある場合とプログラム上のバグの両方の可能性があるが、 いずれにせよこれらを検知してユーザーに確認するか、自動的に停止することが望ましい。
Today, some browser detects abnormal call of API, such as alert popup, and asks user whether to stop subsequent requests. Frequent API call is strongly suspected as malicious behavior but there is a small possibility that it is an intentional behavior.
****
For Vehicle APIs, to ask user about each behavior is distant idea. There are more than hundred data points and most users would feel difficulty to answer the question properly. Therefore implementer should consider API limitation on behalf of users.
Vehicle Data Specificationは多数のデータポイントを定義し、 Vehicle Information Access APIは各データポイントに対し値を変更するset, 現在値を取得するget, 及び値を継続的に取得するsubscribeメソッドを定義している。
Vehicle Data Specification defines data points and Vehicle Information Access API provides 'set' to modify the data, 'get' to obtain current value and 'subscribe' for continuous report.
幾つかのデータポイントについてはsetがそもそも相応しくない。例えば 燃料種別(FuelType)や車の姿勢(Gyro)などは変更できるものではない。 エンジンスピード(EnglineSpeed)や走行距離(distanceSinceTotal)など 安全上、あるいはメンテナンス上変更すべきでないものも存在する。 これらに対するSetの呼び出しはinvalid_operationとして処理されるべきである。
For some data points, 'set' is meaningless. Fuel type or gyro could not be changed in nature. There is another type of data points that the value should not be modifiable because of safety or maintain purpose. Engine speed and distance-since-total name? are categorized into this type. 'Set' for these data points should be failed with 'invalid_operation' error.
Setインターフェースは空調など、いわゆるHVACへの利用を想定して提供されている。 実装者は安全性を検討した上で、これらへのアクセスをinvalid_operationとすることもできる。
'Set' interfaces is mainly expected to be used for non critical data points such as HVAC system. With having safety consideration, implementer may or may not implement 'set' for HVAC.
setをサポートする場合、リソース競合を起こさないよう慎重な設計が求められる。 例えば Vehicle APIを利用するアプリケーションA, Bが同時に動作する場合を考える。 アプリAが温度をあげようとし、アプリBが温度を下げようとすると矛盾が生じる。 また、アプリAが雨を検知し窓とサンルーフを閉じようとした場合に、 アプリBが窓の操作をロックしていると、一貫性のある動作を提供できなくなる。
'Set' implementation needs resource lock mechanism not to cause race conditions. Imagine that two applications A and B work at a time, and app A tries to heat up a room while B tries to cool down. Or imagine, application A senses rain and tries to close window and sunroof. Application A should be given both of control or none of them. Otherwise the consequent result will be unexpected.
WebAPIの利用はオリジン単位で管理され、ユーザーの意思に基づき許諾されてきた。 API実装者はその考え方にしたがって、Vehicle APIsの利用に際してユーザーに何らかの選択肢を与えるべきである。
To have access with some kind of API, each [ORIGIN] need permission which is granted by end user. Implementer should keep this manner for Vehicle APIs as well and provide option that end-user can present their preference.
Vehicle APIは詳細なインターフェースを提供するため、 実装者の視点で開示が望ましくないものも含まれる。 そのようなデータポイントについては、APIの定義にそって提供を行わないこともできる。 更に進んで、ユーザーを保護するという観点から、 特定の組織や、許諾を与えたコンテンツにのみAPIの利用を 認めたい場合が考えられる。そのためのいくつかの選択肢を示す。
Some of data points defined by Vehicle Data Specification might not be preferable to be public from the perspective of implementers. Specification allows implementer not to expose these data points. Also, considering user's benefit, an implementer would like to expose some of data points only to certain 3rd parties or authorized contents. Here is best practices to realize such access control.
Vehicle APIsから取得できる情報は、ドラーバーや車の所有者と容易に関連付けることができ、 そのため"個人情報"に当たると考えられる。それらの情報はプライバシー保護の対象として 扱われるべきであるが、その方法は個人や、その時の状況、その地方の条例によって変わる。
Vehicle data and its location data are considered as "personal data" because a driver or the owner of a vehicle is easily identifiable by correlating with information from other sources. Therefore, these data should be treated as object information for privacy protection. However, the way of privacy protection may differ by individual, by situation, and by local regulation.
サービス提供者は、Vehicle APIsによって得た情報をIVIの外へ送出しようとする場合、 ユーザーのプライバシーを保護しなくてはならない。 具体的には下記の項目について、ユーザーの希望に沿った運用を行わなくてはならない。
Service provider must protect end-user's privacy when they send out location or information from Vehicle APIs. Followings should be proceeded and information has to be treated in complying with user preferences.
ユーザエージェントは、あるサイトから得られたアプリケーションが Vehicle Access Information API***で 車両情報を要求した場合、ユーザーに許諾を求めるべきである。 この許諾結果は保存してもよいが、ユーザーが希望するときには 不許諾に変更するユーザーインターフェースを 持たなくてはならない。
User agent should ask user's permission when an application tries to use Information Access API. The answer could be stored for future API use by the same origin but user agent should provide UI to change the preference.
[DNT] はWeb Applicationに対し自己のトラッキングを行わないように要求するための HTTP ヘッダについての勧告であり、広くサポートされている。 車両では交通事故等、生命・財産の危機に瀕することがあり、 その場合は一時的にDNT機能をOFFにすることを検討すべきである。
The Do Not Track ([DNT]) is the proposed HTTP header field that requests that a web application disables either its tracking or cross-site user tracking of an individual user. In view of peculiarity of automobile, in the event of emergencies to protect the vital interests and property of an individual, temporal deactivation of DNT function may be required.
DNTを含め、緊急時におけるプライバシーの保護の例外は、暗黙裡に認められるものではない。 タスクフォースに提供されたアンケート結果からは、たとえ緊急時であっても 自己のプライバシー情報の開示したくないとする意見が一定数いることがわかっている。 サービス提供者は緊急時のデーターの取り扱いについて明示的にユーザーの許諾を得ておくべきである。
Including DNT, exceptions for privacy protection is not implicitly allowed. A questionnaire performed by a contributer of task force shows that there are non-negligible number of people do not want to provide their privacy information even if they are facing an emergent situation. Service provider should have explicit consent for use of private data in advance.
一台の車には複数の運転者が想定される。それらの運転手は家族であるかもしれないし、職務上の同僚かもしれない。 IVIは、個人向けに設定される情報がある場合には、それら複数の運転者それぞれのプライバシーが守られるよう配慮すべきである。 個人毎に切り替えられるべき情報の例を以下に示す。
A driver would have number of cars and a car would have multi number of drivers. For the latter case, the drivers could be one's family or could be one's collogues. IVI, therefore, should keep their personal data and preference in secret not to be seen from other drivers Personal information includes followings:
上記を実現するためにはIVIがユーザー認証とログイン処理を行う必要がある。 OSレベルで対応することが自然であるが、Webランタイムが対応しても差し支えない。
To use different profiles for different users, IVI has to implement user authentication and login. It is natural that operating system provides this functionality but web runtime also could be the provider. In any implementation, this profile change should be transparent from applications.
一方でサービス提供者は、一台の端末を複数のユーザーが共有することを想定するべきである。 ユーザーの識別にはアカウント・パスワードが用いられてきたが、IVIのUIとしては好ましくない。 [FIDO] のような方法で安全性と利便性の両立をはかるべきだろう。
On the other hand, service provider should take into consideration that an IVI will be shared with multi user. For the purpose of user authentication, "account and password" have been used but that is not friendly for drivers. [FIDO] allows service providers to realize convenient authentication.
同一のユーザーであっても、利用される状況が異なることが考えられる。 家族のドライビングと職務上の移動ではふさわしいコンテンツが異なる可能性がある。 アプリはこのような、状況変化を想定し、個人の趣味嗜好に基づくコンテンツを提示する場合には 利用者の意図を確認するようなUIを提供すべきである。
User would use a service in deferent situation. Appropriate contents for driving with family would be different from moving with collogues. Service provider should consider this possibility and should be careful to display contents based on one's preference.
ドライバーが車の所有者とは限らないケースがある。例えば会社が所有する車であったり、レンタカーとして提供される場合が考えられる。 このようなケースではIVIの管理者権限は所有者に与えられ、運転者が操作できるべきではない。 所有者にのみ認められるべき権限の例を以下に示す。
A driver might be different from the car owner. The car could be owned by a company or could be shared with friends. In these case administrative operation should be permitted to the owner and drivers should be kept away from the operation. Here is faculties which should be allowed only for owners.
原則としてドライバーのプライバシーに関わる情報は、所有者であっても許可無く開示されるべきではない。 ユーザーの利便性を考慮して開示を行う場合には、IVIはドライバーが情報を入力する際にその旨を通告すべきである。
In principle, even the owner should not be able to see other driver's personal data without their consent. If an IVI needs to exposes these data for the purpose of user's benefit, the IVI should ask user in advance.