Required rotation of deeplinks vehicle identifier

[heidiguenin]

A stable vehicle identifier in a deeplink poses the same issue as a stable bike_id, and we missed including this in the initial addition of deeplinks.

[stale]

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

[heidiguenin]

I hereby call a vote on this proposal. Voting will be open for 10 full calendar days until 11:59PM UTC on December 9th, 2021.

Please vote for or against the proposal, and include the organization for which you are voting in your comment.

Please note if you can commit to implementing the proposal.

[cmonagle]

+1 from Transit

[kanagy]

+1 from Google Maps, we use whatever links are present in the feed.

[viestat]

-1 from Dott, as discussed in the GBFS Developers' Workshop that took place on Tuesday, October 19. I feel that this is not an actual fix to the underlying concern of traceability.
The rationale given then was that any public GBFS feed could be stored periodically by any actor, allowing for different kinds of backtracking analysis which could lead to multiple ways of getting the kind of insights this proposal is meant to prevent.

An example could be the creation of a mapping of a vehicle's id (and vehicle identifier in this proposal) across time (without a massive effort), potentially rendering the rotation useless.

Furthermore, this increases the complexity of the implementation for a little gain and might be a deterrent to have open feeds.

[testower]

Entur supports this proposal

[nbdh]

+1 from nextbike

[mplsmitch]

@viestat Given that we now have 4 votes in favor of this change, I wonder if you might consider changing your position or abstaining from this vote. The governance states that a single vote against kills the proposal so currently it won't pass.

The privacy issue posed by the deep link vehicle id has been well documented (see #146 ) and should have been fixed when bike_id was changed to require rotation in v2.0. To not make this changes would be to go against the privacy by design principles of the specification. While there may be additional ways of determining trip origin and destination, none have been identified at this point. The example you give of creating a mapping of vehicle ids across time is exactly what this proposal is trying to prevent. Research on this topic has so far confirmed that the rotation of vehicle ids has been successful in obscuring OD pairs as a way to protect traveler privacy.

Since bike_id already requires rotation after each trip, I don't see any reason why the same id couldn't be used in deep links. This should lessen concerns around implementation complexity. The consuming applications are ready to work with the rotated ids. Finally, what we've heard most often from operators that are reluctant to publish public feeds is that they are concerned about potential privacy issues. It's very hard to make the case for public feeds when we have a known privacy issue that we haven't taken steps to fix.

[heidiguenin]

Voting on this PR closes in 2 calendar days. Please vote for or against the proposal, and include the organization for which you are voting in your comment. Please note if you can commit to implementing the proposal.

[ncancelliere]

-1 Spin is NO on this proposal. I agree with @viestat in that it doesn't really fix the problem and just unnecessarily complicates implementations.

[testower]

Votes against a proposal can stop a proposal from passing if they provide a specific reason for voting against and contain actionable feedback.

Just a reminder that it was an oversight when bike_id rotation was made required, to not include the deeplinks. It should have been done there. That PR was passed by 7 votes for, 0 against:

#147

Consumers (5): RideReport, Google Maps, Ito World, Stae, Transit
Producers (2): Uber/JUMP, Bird

[ncancelliere]

So I wasn't aware we were doing this for bike_ids. However I am still not entirely sure what this is intending on protecting. If you're trying to make it hard to understand a trip (start / end location) I can see how rotation helps - maybe? If you're trying to protect user privacy I do not see how this helps.

But to be consistent with the bike_id which is now rotating, then I think it would make sense to do so - although I still maintain it's an high burden compared to benefit in terms of privacy gained.

+1

[heidiguenin]

@ncancelliere It is indeed intended to make it more difficult to pinpoint start/end of a trip. That decision was made after a community member was able to identify particularly sensitive trips (including from a high school to a reproductive health care provider).

My understanding is that before the rotation of bike_id, most deeplink implementations were using bike_id within the link, and that after rotation, most deeplink implementations would continue using the bike_id that was rotated.

[viestat]

I am ok to unblock so that it is also consistent with bike_id so here I change my vote.

However Dott will not be implementing this anytime soon.

+1.

[heidiguenin]

This vote has now closed, and it passes!

Votes in favor:
Transit (consumer)
Google Maps (consumer)
Entur (consumer)
nextbike (producer)
Spin (producer)
Dott (producer)


In the end, there were no votes against.

Thank you to everyone for spending the time on this one - I know it was a challenging one to pass, especially with folks coming into the conversation after last year’s id rotation was already decided. We hope that this finally addresses the concerns raised in 2019 and we can keep moving forward!

We will tag and merge this into v3.0-RC2 in the coming weeks.