Removing bike_id from GBFS

[heidiguenin]

What is the issue and why is it an issue?

Rotating bike_id was proposed in April of 2019 and was voted into GBFS in January 2020 after community input at the first annual GBFS Developers’ Workshop and in the GitHub repo. (See issue #346 for more background on why bike_id came to be rotated.) At the time, there was discussion of removing bike_id from the free_bike_status file altogether, but the community decided to delay that change in case critical use cases for bike_id had not been identified during the initial conversations. In general, though, there was support for eventually removing bike_id altogether in public GBFS datasets.

Because deeplinks take a traveler to the operator's app where a stable id can be shown safely, it appears that there are no traveler-facing reasons to continue to publish an id via GBFS.

Please describe some potential solutions you have considered (even if they aren’t related to GBFS).

The requirement to rotate bike_id did help mitigate some of the concerns around recreating trips. However, we occasionally still see providers publishing stable ids in a public feed.

We have discussed the possibility of keeping bike_id (or vehicle_id in v3.0 with community support #354 ) only in authenticated GBFS datasets and providing guidance with respect to that change. However, in early discussions with consumers who request stable ids in private datasets, we have learned that most are not using that information or plan to stop using and requesting it in the future in favor of MDS /vehicles or other compliance options.

Is your potential solution a breaking change?

• [ x] Yes
• No
• Unsure

[davidlewis-ito]

Presumably even if bike_id is removed, in order to provide deep links to the individual vehicle, the identification of the bike will be included within the rental_uris. So the problem is not really resolved.

[sven4all]

I am against this change. First it's a little bit strange that we remove a field from the standard because operators fail to properly implement the standard. Second when processing the data it's very usable to have an id, in this way you can easily understand if I vehicle is removed from public space or is only moved. Third, deeplinking could also work with dynamic id's, the backend systems of operators should only be adapted to work with those dynamic id's and make a translation the static id's.

[testower]

I'm also against this change for the exact same reasons as listed by @sven4all .

Edit: to elaborate a bit: One reason for us this is a bad idea is that we use the ID as an identifier when building a cache of all vehicles. If we loose the ID we basically have to rebuild the whole cache every time we update the feed.

Either way as was pointed out, deeplinking for require some sort of identifier anyway, so "hiding" it by removing bike_id while keeping it in the deeplink merely constitutes security by obscurity.

It should be the responsibility of the data provdider to make sure that the ID is rotated and therefore does not pose a privacy issue.

[skinkie]

Discussed in a private discussion with Mobility Data already. Against this change.

[GerdC]

A provider that always rotates the ID forced me to create a new annotation each time which triggers the recalculation of clusters which has unwanted visual effects with each update. Against this change.