Privacy Protection of Automated and Self-Driving Vehicles

A common belief is that privacy comes at a cost, and hence, a tension exists between achieving full privacy and full “performance”. This tension can be seen as finding the acceptable trade-off between privacy and the considered value/criteria. Let us consider the case of an automated vehicle driving in a city. To ensure road safety, an automated vehicle needs to detect pedestrians with high accuracy. Moreover, for accurate prediction and planning, the vehicle should be able to differentiate between different types of pedestrian, e.g., children, adult, impaired users. Indeed, depending on the user type, the motion model used by the behaviour prediction algorithm is adjusted. However, a privacy goal is to minimize those attributes. Therefore, a privacy-enhancing technology could only allow to output the coarse object “pedestrian”, thus conflicting with the “required” granularity.

In order to comprehensively discuss the privacy tensions, the working group identified the lack of a common methodology. The objective of the group was then to propose a methodology.

The objective of the methodology is twofold. First, to capture and rate the privacy tensions (positive or negative). Second, because identifying the privacy tensions is an iterative process, it is useful to understand the current coverage of the analysis. So the methodology should also output a coverage/completion value.

The proposed methodology follows an 5-steps approach. Note that this is a work-in-progress and will be refined in a future publication.

1. 1.

   Specify use case: describe the scenario, its objective(s).

2. 2.

   Identify stakeholders: list direct and indirect user/actors.

3. 3.

   For each stakeholder, list respective assets, privacy needs and performance objectives.

4. 4.

   Rate impact of dimension on privacy.

5. 5.

   Assess current coverage/completion of the analysis for each dimension.

Creating a methodology to analyze privacy tensions (or synergies) is paramount to capture each dimensions (e.g., security, ethics, efficiency) and identify the technology readiness level of appropriate PETs. In a forthcoming publication, we will refine the methodology and validate it by applying it to case studies such as automated delivery service.

In this working group, we identify and discuss six questions that address some of the major aspects of privacy engineering in the automotive domain.

1. Q1.

   What tools and frameworks are there to help commercial entities comply with regulations and embed privacy?

   Our goal here is to identify privacy tools that have already been applied to automotive, in addition to identifying and investigating the applicability of general privacy engineering tools to automotive.

   We begin by pointing out that privacy in automotive is distinctive due to several factors such as the limited storage and processing power, specific protocols related to vehicle connectivity and communication (e. g, CAN bus), and the direct interaction with human safety among other trade-offs. In addition, automotive scenarios often rely on certain sensitive data and information such as location data and driving behaviour requiring privacy protection. We refer the reader to [2] for additional information about automotive data. A noteworthy point to consider here is that the entire automotive ecosystem is very complex. Modern architecture of automotive systems include vehicles, mobile devices, communications, and third-party connected services such as infotainment services. Furthermore, vehicles come with a complex supply chain consisting of multiple layers, for which privacy must be considered with different responsibility, accountability, and liability. To illustrate this, we consider an ASIL-like certification program made for privacy. It is yet unclear whether such a program would be available at different levels, OEM-level, Tier-1, Tier-2 (Privacy Certificate for suppliers) or it would be for OEMs only.

   In the privacy engineering landscape, there exist various tools and frameworks that have the potential to be used in the automotive domain. Examples of such include LINDDUN [13] as a privacy threat modelling framework, privacy design strategies, privacy patterns [4], and various privacy-enhancing technologies. Conducting a threat assessment and risk assessment (TARA) in the automotive domain may require considering different scopes of OEMs and suppliers along with the need to have a hierarchical analysis with a privacy impact assessment (PIA) on vehicle level supported by PIAs on component levels. This could also lead to a split of responsibility and tasks. For example, on a vehicle-level there needs to be a data strategy while on a component-level the task is more focused on implementing a PET.

   One source of inspiration for the automotive privacy engineering community to consider are adjacent domains such as IT, mobile systems, and e-health. Ideas may be inspired by investigating the privacy engineering challenges of those domains and investigate if the solutions addressed the challenges in those domains can be transferred.

   In the next questions, we will dig deeper into certain tools and frameworks of privacy engineering and investigate how to adapt and tailor them towards the automotive industry.
   

2. Q2.

   How to tailor privacy patterns to automotive industry, including what privacy patterns are there for automotive and leveraging architecture patterns?

   In this question, we want to particularly investigate whether current privacy strategies and privacy patterns [4] are directly applicable to the automotive domain.

   In order to address this question thoroughly, we recommend the community to identify a set of automotive use cases and assess the applicability of existing patterns and define how to adapt such applicable patterns. We note that it may also be necessary to develop new patterns specific to vehicles, taking into account vehicle architectural patterns and the privacy challenges in future use cases, e. g., for automated driving and shared robo-taxis.

   In this working group, we aim to provide an initial assessment of the applicability of patterns in the automotive domain. We randomly choose three privacy patterns from the pattern repository [4] and, on a high-level, investigate their applicability to certain automotive scenarios.

   Awareness Feed

   This pattern states the importance of providing information to the end user concerning their privacy. However, in the automotive scenarios and particularly, the direct applicability of such a pattern in the vehicle to inform the user is challenging as this may divert the driver’s attention and thus may lead to an unsafe situation in cases of not fully automated driving scenarios.

   To this end, it is important to identify when it is a good time to show the drivers certain privacy information in a way that does not interrupt their attention on driving. This may include innovative and unorthodox methods of informing end users, such as vibrating the steering wheel, or usage of audio channels.

   Applying this pattern is also challenging if we consider informing other users, such as passengers of a car/taxi/bus. How to ensure such users are aware, are able to give consent, or select certain privacy preferences remain unsolved. The topic is even more complex for other road users, which can be communicated with even harder.

   Informed Secure Passwords

   This pattern requests to ensure end users select strong and long passwords with various characters for different services and applications. However, given that the UIs available in cars nowadays do not match those of mobile phones and keyboards, it is very challenging and critical to apply this pattern directly in the vehicle. It is generally hard to type passwords in current vehicle interfaces. This opens the door to different solutions to enter passwords in vehicles, or even to question the usability of passwords as authentication method in vehicles. The automotive privacy community needs to investigate other forms of authentication such as physical authentication tokens (e. g. Yubikeys), or bio-metric information, and assess whether these are better fit to the automotive use cases. Other challenges include identity management and having different profiles/roles for a certain identity, e. g., a business and a private profile.

   Location Granularity

   This pattern deals with location data and states that precise locations should be used with less granularity, e. g., street, ZIP code or city name, if precise location is not needed. On a first glance, we foresee a direct applicability for automotive scenarios, but we point out that the applicability is context-dependent, i. e., what level of granularity is needed for the context and thereafter it needs to be set. One example is a difference in the granularity requirements for finding a nearby restaurant in comparison to ordering a taxi for pickup. In the first example, the rough area is sufficient to receive information from a service about restaurants. The latter requires a more specific rendezvous point to make sure passenger and taxi can meet.

3. Q3.

   How can privacy engineering be embedded into the product or software development life cycle (SDLC) including threat modelling and verification of implementation?

   The privacy engineering process defined by Hoepman [11] should be applied and integrated into the SDLC. Furthermore, extended SDLC models for privacy such as the W-model [18] and the $\sigma$-model [19] should be applied. Such models extend classical SDLC used in automotive industry like the V-model to include privacy-by-design phases. Another more challenging problem is the integration of privacy-enhancing technologies into agile environments [20, 21], since PETs are hard to compose. There seems to be a lack of privacy methodologies in the right-hand side of the V-model, i. e., the testing phases. We note that formulating testing and evaluation is challenging for privacy aspects, but not only in the automotive domain. Often, there is no external data available at the time of testing a certain privacy objective, and this heavily depends on the context and on the runtime environment [10].
   

4. Q4.

   Can PETs achieve system’s functionality without blocking a certain functionality and at what cost can PETs be implemented in a company or a product?

   Different PETs have been proposed in the literature, to name a few:

   Multi-Party Computation (MPC):

   Several parties in a system collaboratively compute an agreed upon function where respective inputs are secret.

   (Fully) Homomorphic Encryption ((F)HE):

   FHE supports the computation on encrypted data without the need to decrypt it.

   Differential Privacy (DP):

   By adding noise into the analysis output, it formalizes and measures how much privacy is brought relative to losing utility.

   K-anonymity:

   Masking data such that every record is indistinguishable from $k-1$ other records in a dataset.

   Trusted Execution Environments (TEEs):

   Areas in processing units with secure interaction with the rest of the system where data is encrypted outside but decrypted inside this environment.

   Attribute-Based Credentials (ABC):

   Credentials, based on attributes instead of identities, allowing anonymous credentials for role-based access control (RBAC) or attribute-based access control (ABAC). Selective disclosure of attributes forms a key to achieving anonymous authentication.

   Zero-Knowledge Proofs (ZKPs):

   Proving whether a statement is correct or not without leaking more information.

   We note that this is only a subset of PETs, further PETs that might be used in automotive scenarios are listed by Garrido et al. [7] [Tab. II, p. 3; Tab. III,p. 4]. Garrido et al. discuss PETs in automotive use cases and conclude that there is still the need for a deep understanding of the use cases and the proposed PETs. A noteworthy remark is that in some cases, more than one PET needs to be applied to achieve an overarching privacy goal.

   It is ultimately necessary to investigate whether PETs can be used generally in automotive scenarios without reducing functionality. More particularly, without impacting trust, safety, and other distinctive aspects of the automotive domain.

   Let’s consider another possible scenario: cooperative intersection management using mobile edge computers. In this scenario, the edge, ideally, needs to know who you are, where you want to go, and your current position. In this scenario, the vehicle’s position is needed but not a link to the driver’s identity. HE may be used to compute the positions and directions in an encrypted fashion, but as a time-critical application, this may greatly impact the flow of traffic and the safety of road users. Considering that multiple vehicles are present in the vicinity with a known function to calculate, MPC might be useful.

   Another solution to this scenario could be based on ABC, or privacy-preserving signature schemes, while using the minimal set of data needed in cleartext, e.g., the current location, velocity, steering angles, vehicle size category (e.g., car, bus, or truck with trailer), and the desired direction at the intersection (i.e., left, straight, right, or u-turn). This data could be used anonymously, i.e., without the vehicle, driver, and passenger identities. It would only be required to verify that the data truly originates from a valid vehicle, e.g., through the use of attribute-based credentials, or privacy-preserving signature schemes. However, it is worth noting that repetitive usage of accurate vehicle’s data such as the vehicle’s exact dimensions and direction of movement over a long period of time may increase the possibility of re-identification of that vehicle and/or driver [8].

   To sum up, it is challenging to determine whether PETs may or may not be directly applicable in automotive scenarios and which one to use [7, 9]. Applying a PET in an application or a scenario requires clearly defining functionality requirements, privacy requirements, threat models, the bigger context of the systems and protocols involved in automotive scenarios.
   

5. Q5.

   What are people’s privacy behaviours and expectations: how can vehicle users be educated about vehicle data usage and its implication? What about the privacy of extravehicular entities (pedestrians, etc.)?

   In order to foster widespread adoption of privacy-friendly automotive features and scenarios, creating a demand from customers is crucial. This requires understanding the current people’s perception of privacy when it comes to the automotive domain. Consequently, it is necessary to raise the awareness of privacy among customers to create the needed demand that will foster the deployment of privacy technologies into automotive scenarios.

   The automotive privacy community needs to take into account the differences in people’s perception of privacy that could stem from, e.g., cultural aspects based on regions or countries, which may impact how privacy options and controls can be designed and aligned with users’ expectations. Therefore, we recommend conducting user studies on privacy expectations and actions specifically in the automotive space while taking into account cultural differences.

   Additionally, we discussed the uniqueness of the automotive space over other domains such as mobile phones. This uniqueness may include further privacy-related factors such as driving behaviours and (in-cabin) cameras. Such additional factors would necessitate creating awareness of what data is collected, what PII is, and what seemingly is not PII, but can still be used to identify individuals or their driving patterns. The latter may be used to determine insurance rates or for re-identification of individuals using different vehicles in order to create and observe movement patterns. Thus, user awareness is essential in a transparent manner. When considering autonomous driving, different perceptions to the ones we discussed so far could be based on the level of autonomy. For example, at levels 4 and 5 there may not be any human driving pattern. However, privacy can be still an issue in new ways, such as user profiling in the car including, e.g., eye gazes, looking out the window, touching the steering wheel, etc.

   Also, we need a comprehensive understanding of people’s privacy perceptions under different use cases, that could be when users use their own car or using a shared car. The case of passengers’ privacy needs also to be addressed adequately, that is, how passengers’ privacy can be protected. To this end, this would require novel approaches of HMI considering the specific and uniqueness of the automotive domain. Enhancing customer awareness may take various forms and approaches. For example, the Vehicle Privacy Report website [12], provides privacy car facts for free by searching your VIN. It is necessary to study the best ways to increase user awareness and provide them with tools to learn about, understand, and adjust their privacy settings. One possibility is the “app” used for the scenario of shared car service. Another example that may be helpful to develop and use is the standardized privacy labels analogous to the energy-efficiency rating of consumer products, such as TV, fridge, etc. This links to the idea of a privacy score [15].

   In fact, it is the tendency to collect data by default at any time when a new technology or service is deployed. Service providers will collect any and all data until they are told otherwise, for example, by regulators. On the other hand, regulating privacy can be very difficult. Even with privacy by default, providers will find a way around the regulation. Also, demands from the people themselves are needed to lead regulators to take action, bringing non-functional requirements like privacy as close to functional requirements and regulations.

   We figure out the criteria for a user-friendly website, which includes “Easy to use”, “intuitive”, and “non-deception” (i. e., dark patterns [5, 6]). We need to tailor and apply such criteria to the automotive space, e. g. [14].

   In summary, we consider that just relying on traditional privacy techniques may not be sufficient for automotive use cases. We encounter new challenges and need new creative ways for HMI, consent, informing, setting regulations, and preventing unwanted capture. Ultimately, we want people to drive knowing what’s allowed without being deceived or tricked. Privacy labels and scores might be helpful to consider in this case.
   

6. Q6.

   How can privacy controls (options) be designed in a way that maximizes transparency and avoids dark patterns in the UI?

   Given the specifics in the automotive context we discussed previously, we understand that providing information with long text should be avoided, instead, informative videos could be used. We need to consider providing alternatives to match different users, as some people prefer text, while others may prefer pictures or videos.

   Informing the user versus legally binding may be two different things. Does it need to be text to be legally binding? Should the legal agreement be done at the same time when the user is informed about data handling? As of today, it seems to be the practice that information and legally binding consent are handled together. Thus, these texts are often written by lawyers and are hard to understand for the users. If those two actions are split, who would write the “understandable” text or create the video? Still Lawyers? Or, the Marketing team or Independent parties? Eventually, this leads to lots of questions about this process.

   It was also unclear when would be the best time to inform the users respectively get their consent. When the car is purchased? Every time the door is opened? When setting up the car and occasionally repeated as a reminder? When there are updates? In general, users get tired of seeing the same notices and warnings and eventually start to ignore them, as we are currently observing with the cookie banners on web pages. How would the passengers be informed or give their consent?

   Clearly, we need an independent authority to define some kind of privacy metrics and scores. Ideally, manufacturers (and customers) should respond to these metrics and define their privacy controls accordingly.

   Lengthy and detailed information may not be available at the moment the personal data is being used. Also, people may not understand how the data is being processed and what can be derived from it, even if detailed explanations are provided. (Will transparency still apply here?)

   Which data is really needed for a service? Given the current usage of “Legitimate interest”, where service providers claim the need for all kinds of data for service improvement, marketing, and other analyses, it would be interesting to measure and identify the “bare minimum” of data needed: Given a certain scenario, based on the current state of the art what would be the minimum of data needed to provide a specific service?

   4.3.2 Conclusion

   Our working group sought to identify existing or needed tools and frameworks to help commercial entities comply with regulations by embedding privacy into their products, and how the available tools can be adapted and tailored toward the automotive industry.

   We explored six questions that address some of the major aspects of privacy engineering in the automotive domain, including identifying available tools and frameworks, tailoring privacy patterns, embedding privacy engineering in the SDLC, applying PETs to achieve needed functionality, learning about user privacy behaviour and expectation, and maximising transparency and avoiding dark patterns.

   Throughout our discussion, we identified various action items that we believe are necessary to be addressed by the automotive privacy research and engineering community:

   1. (a)

      There is a need to confirm, adapt, reject existing privacy strategies and patterns. (cf. Question 2) in terms of their applicability to the automotive domain.

      1. i.

         It is necessary to identify appropriate privacy strategies (i.e., Minimize, Hide, Separate, Abstract, Inform, Control, Enforce, Demonstrate) and confirm that the existing eight strategies are appropriate and complete in the automotive space.

      2. ii.

         Within this context, it is necessary to determine which existing privacy patterns are valid and usable in the automotive context, which ones have to be adapted, and which ones are missing and need to be added.

      3. iii.

         Once the strategies and patterns are properly adapted to automotive context, then there is a need to map the privacy patterns to the steps of the development or product life cycle. (cf. Question 3)

   2. (b)

      Identify a set of automotive scenarios, including connected cars and autonomous driving scenarios, and analyze which data is the bare minimum needed for the functionality of the service, including the use of PETs. Additionally, identify and derive upper and lower bounds where possible. (cf. Question 4 and Question 6)

   3. (c)

      Investigate the possibility to test and evaluate implementations and adjust configuration of PETs in a way that fulfils their purposes. In other words, define methodologies that address the verification and the validation of privacy enhancing technologies in the automotive context. (cf. Question 3)

   4. (d)

      Investigate the necessary knowledge and skills for all stakeholders involved in the software and product development life cycle. (cf. Question 3)

   5. (e)

      Conduct user studies on privacy expectations and behaviours specifically in the automotive space, taking into account cultural differences. (cf. Question 5)

   6. (f)

      Utilize HMI in vehicles for information and awareness on data processing and consent requests with regard to the specific situation of the driver (and passengers) in the vehicle. This may need new ideas for HMI. (cf. Question 5 and Question 6)

Trust and trustworthiness will play an increasingly important role as we shift towards higher levels of automation, because we need to rely on external data to facilitate partially automated or fully automated driving functions. In this context, the integrity and trustworthiness of external data sources, such as external sensor information, maps, and positioning data, becomes paramount. If the integrity of this data is compromised or not provided with the expected quality, the building blocks of the automated operation functions will use incorrect data to control the vehicle. There is a broad set of security attacks that have consequences on the trustworthiness of the data and data sources. The dependability and resilience of CCAM systems can be seriously affected by these attacks at run-time. Furthermore, there are many sources and reasons that can negatively impact dependability and safety that are not related to security. Properties like reliability, accuracy, and robustness are critical for providing consistent and dependable performance, while a property like resilience is essential for adaptability to various real-world scenarios, fostering user trust.

The issue of trust in CCAM extends beyond the realm of data and data sources. ETSI introduced the term Multi-access Edge Computing (MEC) [4] with the goal to bring processing power near the vehicle to meet ultra-low-latency requirements, and to reduce network traffic towards a centralized data-center. However, it is essential to acknowledge that such Edge Computing environments possess inherent characteristics of a complex and highly heterogeneous ecosystem due to the involvement of multiple vendors, suppliers, and stakeholders. In this context, several entities that belong to different trust domains must interact with each other to exchange privacy-sensitive data in order to enable safety-critical collaborative services. However, if these interactions are not properly managed, it can be the cause of privacy leaks. 5GAA published a report recently describing an in-depth analysis of the trust related threats of MEC in the automotive context [5].

EU Project CONNECT [2] addresses the above challenges by building a trust assessment framework for CCAM, which can measure and manage levels of trust under uncertainty, based on incomplete and/or subjective information provided by potentially untrustworthy sources. Furthermore, this framework can accommodate dynamically changing trust relationships due to the high level of mobility exhibited during the operational time of the systems at run-time.

Ethics-based properties are of paramount importance when considering trustworthiness due to their direct impact on public perception and societal implications. For example, the trustworthiness property of accountability emphasizes the importance of data controllers and processors taking responsibility for their actions in managing personal data. This aligns with the ethical principle of accountability, which is key in building trust as it shows that an organization is willing to be answerable for its data practices. Similarly, privacy principles require organizations to be transparent about their data practices, including data collection, processing, and sharing. When individuals can easily understand and access information about how their data is used, it fosters trust in the organization’s integrity. Explainability ensures that system actions are interpretable to users and regulators, addressing concerns about the “black-box” nature of AI (or components based on AI-based technologies).

In summary, adhering to privacy and data protection principles helps organizations demonstrate ethical behavior in their data handling practices, ultimately leading to increased trust from individuals and stakeholders. By upholding strong ethical principles, CCAM systems can build a foundation of trust with users and society, promoting widespread adoption and contributing to the safe and responsible advancement of autonomous mobility technologies.

When discussing the notion of trust in CCAM, we cannot ignore the dimension of human trust from the side of the passenger that will eventually make use of the AV. In that respect, trust of people to the technology is a factor directly affecting the acceptance and adoption of AVs. Research has already demonstrated that the level of trust influences the acceptance of AVs [6].

One compelling interpretation of trust revolves around the sense of vulnerability experienced by individuals inside a vehicle due to the loss of control. In that sense, trust is defined as “the extent to which drivers willingly become vulnerable when using an AV” [7]. Another interpretation of trust is from the perspective of the existence of functionality, i.e. the degree of confidence drivers and passengers have in the predictability and functionality of the vehicle [8].

In order to better understand the human aspect of trust, Kenesei et al. [9] break down trust into three categories as follows: i) trust in the performance of the AV, ii) trust in the manufacturers of the AV, and iii) trust in the institutions responsible for regulating AVs. These dimensions of trust have been elaborated in previous research as well. Eiser et al. [10] point out that people might reject an innovation even if the technology is trustworthy, simply because the organisations behind the technology are not themselves considered as trustworthy. Liu et al. [11] adds another aspect to this dimension, raising the aspect of trust in jurisdiction. Hence, the concept of competence goes beyond mere ability, as it also includes the element of trust in governmental bodies tasked with formulating and implementing laws and regulations that assess the proficiency of these companies. These regulatory authorities grant certificates to brands that exhibit consistent adherence to the specified regulations. For instance, individuals can readily determine the extent to which different businesses adhere to the GDPR, highlighting the importance of proficiency and adherence to regulations as crucial factors in establishing confidence in the domain of data protection and adoption of technology.

Kenesei et al. [9] also explore the intricate interplay between trust and perceived risk. Indeed, when using an AV, the user should have sufficient trust that reduces the perceived risk of potential failure and misuse. More specifically, the authors examine two dimensions of risk: i) the perceived risk of the performance and hence security of the AV, and ii) the risk of misuse of the personal data that is exposed during use, which intersects with privacy protection considerations. Interestingly, their results indicate that privacy risk is influenced by trust in OEMs: trust in the manufacturer decreases the perceived risk of incorrect data handling.

In this light, it becomes evident that the policies governing how OEMs manage and process the collected data, should be considered. At the same time, the societal dimension, intricately linked to user acceptance, assumes a pivotal role in shaping trust perceptions. It becomes apparent though that the policy-making and the societal factors are intertwined, characterized by strong interdependencies that warrant thorough investigation. It is imperative to comprehend how these intertwined factors can influence users’ perceived trust, and consequently, their acceptance of emerging technologies.