Best practices for handling the rotating vehicle_id

[benwedge]

What is the issue and why is it an issue?

This is a bit of an academic discussion, but ideally it will inform some best practices for handling the vehicle_id. The spec states:

Identifier of a vehicle. The vehicle_id identifier MUST be rotated to a random string after each trip to protect user privacy (as of v2.0). Use of persistent vehicle IDs poses a threat to user privacy. The vehicle_id identifier SHOULD only be rotated once per trip.

It seems, in my examination of a variety of feeds, that most providers are using a UUID here and are rotating it after each trip. All good so far. If you dig a layer deeper, some providers use some sort of URL redirection service that takes the URL shared in the feeds and converts it to an app deeplink containing a persistent identifier for a vehicle (e.g. the QR Code, license plate, etc.) that a potential user can match to the vehicle.

My concern is that the above raises a privacy issue, as a malicious user could just call every URL in the feed to find the persistent identifier without needing to have the company's app and take manual steps to cross-reference the data.

I think that this concern is valid, but happy to hear if the concern is misplaced.

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

1. Encourage feed providers to only expose the rotating UUID until the vehicle is displayed inside of their app
2. Encourage feed providers to enact a rate limit to reduce the number of comparisons that can be made between a vehicle in the GBFS feed and a persistent vehicle identifier
3. Encourage feed providers to use the rotating vehicle ID even within their apps (I don't think this is provides a good user experience)

Is your potential solution a breaking change?

• Yes
• [x ] No
• Unsure

[josee-sabourin]

Thanks for raising this! We have attempted to address this in #247 in v3.0-RC, do you think this solution will be appropriate or are there other approaches to take (like the ones you have already included)?

[benwedge]

Yes, I followed that discussion @josee-sabourin, and raised this as I feel the specifics of implementation still raise the possibility of an issue. Hence this being more of a discussion to improve guidance.

[mplsmitch]

Hey @benwedge, the good folks at Tier have put a lot of thought into this issue and published their findings here:
https://tier.engineering/How-we-anonymize-user-trips-on-public-APIs
Very much worth reading

[benwedge]

That's a great discussion, @mplsmitch, however it's not related to the problem I described. There are feed providers who take the rotating ID, then do the transformation to the real ID, then pass that in a URL that a malicious user can view without needing to open the rental apps.

I would be in favour of including a link to Tier's discussion as part of how to make a rotating ID.

[richfab]

Thank you @benwedge for raising this issue. I'd like to make sure I understand the problem you're describing. Are you suggesting that we publish best practices on how providers should implement rotating IDs in their deep links?

Please note that providers MUST rotate identifiers within deep links only since v3.0-RC (it was optional before).

[benwedge]

Yes, that's right @richfab, if we can align on some best practices that can inform your work on the implementation guides

[mobilitydataio]

This discussion has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.

[mobilitydataio]

This discussion has been closed due to inactivity. Discussions can always be reopened after they have been closed.