Privacy Disclosure for the Provider API

[noonhub]

Open Letter from the JUMP Team to the Los Angeles Department of Transportation

Thank you for the opportunity to discuss the the guidelines surrounding data sharing. We have appreciated engaging in a dialogue with you on these important and ever-developing topics.

As you know, the Los Angeles Department of Transportation (LADOT) is requiring implementation of the Provider API of Mobility Data Specification (MDS) for the Dockless On-Demand Personal Mobility Conditional Use Permit (CUP). The MDS requires production of certain categories of location data that may unintentionally endanger rider privacy without specifying how that data will be secured, stored, and used by LADOT.

Rider location data, including precise GPS, timestamp, and route information (collectively, “Trip Data”), may create significant re-identification risk when combined with other publicly available information unless it is properly obfuscated. With very little analysis needed, patterns emerge that can reveal a user’s home, work, and travel, putting their privacy at risk. California’s recently passed Consumer Privacy Act addressed this issue directly by adopting a definition of Personal Data that almost certainly includes Trip Data.

Uber is prepared to implement the Provider API in compliance with the MDS. However, we are concerned that, to date, we do not yet have a formal policy from LADOT explaining how Trip Data will be secured, used, and stored. Given the speed at which the MDS is being implemented, it will be critical to resolve these issues in the short term to protect the privacy of our riders. While we are in full support of standardization across cities, there is a wide range of actions that all cities must pursue to fully protect this data from bad actors, including hiring staff and setting up adequate processes, policies, and safeguards.

In the coming months, Uber is ready to work with the LADOT and others to examine the MDS in more detail and find opportunities to better protect trip-related data while promoting wide standardization and establish industry best practices for data collected by bikes and scooters. In the interim, we trust that as a responsible data steward, LADOT will abide by the following data protection principles.

1. Security of Trip Data must be maintained by LADOT

Any government authority requiring production of Trip Data through the Provider API should secure Trip Data in accordance with standards applicable to Personal Information. To do this, the recipient must implement administrative, physical, and technical safeguards that are no less rigorous than accepted industry practices related to the protection of Personal Information, and shall ensure that all such safeguards, including the manner in which Trip Data is collected, accessed, used, stored, processed, disposed of, and disclosed, comply with applicable data protection and privacy laws. In addition, we trust that LADOT will restrict access to Trip Data to specific individuals within the city’s internal teams who have been granted the appropriate authorization and access rights.

2. Uses of Trip Data should be limited and communicated to riders

In light of the potential for abuse, the receiving government authority should limit its use of Trip Data to clearly specified objectives that are in line with its mission and statutory authority. For example, LADOT has stated that it intends to use the data for permit enforcement, communication of events, parking restrictions, and city planning. These are all sensible uses of Trip Data. However, Trip Data data may be easily combined with other government data sets for uses the public may find less acceptable. By committing to a set of objectives or data use guidelines beforehand, the government authority can demonstrate that it intends to be a responsible steward of this information. To ensure transparency, Uber may notify riders that their Trip Data will be shared with LADOT.

3. Trip Data should be obfuscated when stored at rest

The receiving government authority should commit to obfuscate user Trip Data when stored at rest in its network. In practice, this is the act of masking or scrambling personally-identifiable or sensitive data in order to control how the data appears in the output of a database query. This simple but powerful step would significantly diminish the risk of user re-identification if Trip Data is ever publicly disclosed via a hacking or government records request. More importantly, precise Trip Data is not required for the vast majority of use cases cited by LADOT. City planning uses cases, for example, are actually better served with data that has been aggregated to uncover behavior patterns.

4. Additional data sharing must be restricted

Data privacy is in the cultural spotlight, and users are afraid they have lost control of their personal data. Yet, in the discussion on github regarding authentication, it has already been suggested that cities will be able to clone auth tokens to share with other agencies and vendors.

We would like to reaffirm that the receiving government authority will resist sharing any data shared by the Provider API to any other public or private bodies in the absence of a formal agreement. Without understanding the safety measures or commitments of these third parties, Uber cannot measure and mitigate the safety risks associated with sharing data outside of this agreement.

Last, we recognize that LADOT is required to comply with the California Public Records Act (CPRA). We request that LADOT propose a plan to ensure that the CPRA is not used to share unmasked Trip Data with the the general public.

In the coming weeks, Uber looks forward to working with LADOT and others on an industry standard for sharing bike and scooter data that will be acceptable to all parties. With participation from all, we are confident in our ability to develop a forward-thinking standard that meets the needs of cities while safeguarding the privacy of riders.

Regards,

JUMP Team

[LADOTBikeshare]

LADOT has reviewed the comment and we have include our a link to the guidelines for handling the data in the README. ref #154