JUMP additional fields

[johntmyers]

Hi,

I have been exploring the live GBFS data and after reading through #147 I wanted to ask a question specifically regarding the JUMP data set. It appears the feeds for JUMP are adding some additional fields, specifically:

• jump_ebike_battery_level
• jump_vehicle_type
• jump_vehicle_name

The intent behind #147, if I am understanding this correctly, is to not allow specific rides to be re-constructed, which is easy to do when GPS locations of a particular bike ID move over some non-trivial distance. However it currently seems like the jump_vehicle_name value has a 1:1 correlation with the bike_id field currently. The one major difference is that the jump_vehicle_name data is actually accessible to anyone with the Uber app as the this value shows up when you use the app to browse available scooters.

From a privacy perspective, this feels categorically worse than the bike_id since one could actually visibly observe someone else getting a scooter and use the jump_vehicle_name to re-construct a ride.

Here is an example of a free scooter in Baltimore:

Now using the vehicle name, you can re-construct the rides of that particular scooter. In this example I'm using a geodesic distance to filter on non-trivial differences between reported GPS locations.

Are there currently any plans to have this field removed and only support the rotating bike_id?

[gcamp]

This seems more a question for Jump rather than something that is in the spec discussion, but maybe somebody from Jump can respond here.

[charlesjump]

Hey Team -- Charles here from JUMP. You hit the privacy implications on the head here. The original plan was to wait for GBFS v2 to be officially released to support the rotating Bike IDs #147

I'm going to put a change out today that will remove the JUMP vehicle name from all feeds and scramble the bike_id.

[johntmyers]

@gcamp determining whether extra fields should be allowed is a pretty standard schema type of discussion, is that already covered in the spec?

[johntmyers]

@charlesjump awesome! Also FWIW, the battery level field is a string (that contains the "%") character, I'm not sure how useful that is for analysis compared to using an int.

[Empty2k12]

@johntmyers @charlesjump #136 adds a formal battery percentage field together with vehicle types which seems to be the exact use case the current jump_ebike_battery_level and jump_vehicle_type fields are trying to do. Maybe JUMP can vote in favor of this proposal and commit to implementing the spec so every consumer can display battery percentages and vehicle types of all the feeds implementing the proposal, including JUMP?

[jcn]

determining whether extra fields should be allowed is a pretty standard schema type of discussion, is that already covered in the spec?

@johntmyers Non-standard extensions are explicitly allowed by the spec, if that's what you're asking about more broadly: https://github.com/NABSA/gbfs/blob/master/README.md#extensions-outside-of-the-specification

[morganherlocker]

From a privacy perspective, this feels categorically worse than the bike_id since one could actually visibly observe someone else getting a scooter and use the jump_vehicle_name to re-construct a ride.

For what it's worth, this issue also exists with non-rotated bike_id. This is another way to get at trip reconstruction.