Trip data for delivery robots

[schnuerle]

As part of the MDS 2.0 Modes draft review #801, @Aileen1Zhong raised some questions about some trip data fields around privacy and trade secrets for delivery robots. Specifically:

1. Provider /trips: trip_duration, trip_distance, start_location, end_location, route
2. Provider /vehicles: battery_pct, current_location

For /trips, the concern is regular habits of customers or companies may be discerned, or operator trade secrets could be gleaned.

For /vehicles, the concern is operator trade secrets could be gleaned. Note these fields are available in public GBFS feeds currently with lat, lon, and current_fuel_percent.

Some of these concerns were discussed over the last year in public Working Group meetings, roundtables, webinars, and OMF Member Networks with Kiwibot, San Jose, Blue Systems, Populus, Pittsburgh, Detroit, Miami-Dade, Detroit, SANDAG, Portland, DC, and SFMTA, so we'd like them to chime in as well.

These concerns exist for MDS for micromobility as well. So far these have been addressed by:

1. Cities are receiving the data, not the public, and cities should handle it like other sensitive data. Trade secret data and personal data is typically required to be redacted by law or policy with any open records requests.
2. Cities follow guidelines in the OMF Privacy Guide for Cities
3. Cities have clear use cases (see database) for needing the data by law, for permits, safety, allowing council adoption, for fees/operations, complaints, data auditing, infrastructure planning, etc.
4. Cities may only ask for any of these fields if they are following local and state laws and policies
5. Cities can choose to not receive any of these fields after talking with operators, and use Policy Requirements to make this clear. E.g., not receiving start and end points and/or route or trip information. All MDS fields are optional using this.
6. Cities could use Geography Driven Events in MDS to not obtain precise location and instead only get location through larger pre-defined geographic areas

Please leave your thoughts around how these ideas apply to delivery robots, and what else could be done to resolve privacy and trade secret concerns.

[agiacchetti]

I agree that many of these issues have been addressed in prior iterations of MDS and supporting guidance (i.e. the OMF Privacy Guide for Cities).

One topic we should consider for further discussion is trip data, specifically end location. This is where delivery as a use case (and delivery bots specifically) may have a slightly different set of considerations in that most deliveries are going to end at residences or businesses. It seems fair to assume that single the most common consumer behavior is an individual ordering goods from a business to be delivered to the recipient's residence. In contrast, other modes (micromobility, passenger services) address a wider array of consumer behavior and are used in a variety of urban environments. I would love to understand city use cases a little bit better, and evaluate the spec and supporting guidance accordingly.

[pierre-bouffort]

I agree with both your comments. The concerns related to the information mentioned have indeed been tackled by the MDS previous works around micromobility, at least from our perspective. If we were to remove all the following fields trip_duration, trip_distance, start_location, end_location, route, battery_pct, current_location, we would lose most of the added value of these data to the cities, and I'm afraid the monitoring wouldn't be useful anymore.

Now, to the point about the end_location, it is indeed fair to assume the end locations will be residences/businesses is a fair point. Maybe we can edge this risk by making the required number of decimals in the coordinates for end_trip locations less constrained? (thus rounding it up to acceptable precisions)
This way bot operators who wish to operators can send this information with full precision, but aren't constrained to do so.

[schnuerle]

If we go the route of truncating decimals of lat/lons in some fields, I think this should be defined in and be located in the Policy Requirements file, which will make it clear which fields are needed and what the precision should be. This then could apply to any field in MDS, and work with any mode!

Technically, I'm thinking of something like a precision array that gets to Spec -> API -> endpoint -> field -> precision (e.g., a '3' integer to show how many decimal places in a coordinate are required). This would only work with geolocation fields like start_location, end_location, telemetry point on a trip, etc.

[pierre-bouffort]

Sounds like a good way to define precision to me. We are fine with this method on our end.

[schnuerle]

I've created pull request #812 that adds precision to Policy Requirements to address most of the location concerns listed here. Please review, leave comments in general or inline, and you can see the object defined here and an example here.

[schnuerle]

Per the discussion with the steering committee today and the comment below, I'm inclined to hold off on this new feature since it adds complexity to MDS when there are already existing solutions (disallowed fields in Requirements, Geography Driven Events). Instead we could see how cities and operators use these existing privacy solutions for delivery robots, and from those real-world examples and use cases update MDS in some way in 2.1 or beyond.

[pierre-bouffort]

After the discussions we have had on the Working Group and in the Steering Committee, I start to believe actually that the precision field would bring unnecessary extra complexity. The reality of the devices today is that we are already struggling with GPS hardware imprecision, that will vary depending on the devices/operators from 5 to 50 meters.

I am not sure that adding this precision field would add any extra safety on the data privacy, since this hardware limitation already is doing that. Also, in my experience, cities have always been able to bilaterally discuss with their operators to figure out if some of the data wasn't required for them to send etc... So maybe let's not over-complicate things in the MDS here.

From our perspective, I believe we could stand by the initial plan without that extra precision field.

[agiacchetti]

Agree - after discussing and thinking about this more, I believe the existing privacy features can adequately address trip data concerns for delivery robots:

Geography-Driven Events (MDS 1.1): Provides an optional, alternative way to manage providers’ compliance (both real-time and historical) without precise location data. Vehicles emit events whenever they change geographic areas defined by a city. Instead of sharing the exact vehicle location, these events simply return an identifier that indicates which geographic region a vehicle entered and left.

Policy Requirements (MDS 1.2): Makes MDS even more flexible by letting agencies tailor the data they get to their specific use cases, and it increases privacy by allowing agencies to ask for only the data they need.

[schnuerle]

Reading the discussion here, the consensus is that MDS already has good guidance and existing tools to limit data fields when needed for any reason. Those built-in MDS tool are:

1. Policy Requirements - using this, any or all fields mentioned in the comment can be left out of MDS data feeds if the city and provider agree, e.g. Provider /trips trip_duration, trip_distance, start_location, end_location, route and/or Provider /vehicles battery_pct, current_location. MDS 2.0 will include the ability to tie any data requests to defined use cases.
2. Geography Driven Events - Instead of returning GPS location of each trip's start and end location and route, it is possible for locations to be rolled up into larger geographic areas, e.g. census blocks, neighborhoods, a grid across a city, or any defined areas.

As work on MDS 2.0 is now being finalized, we will hold off on adding any other larger or complex changes for now. But we may continue the discussion if needed and think about MDS updates in future releases.