Lime Bike-Share Feed May Let Observers Reconstruct Rider Trips

A researcher says Lime’s public GBFS data does not consistently rotate vehicle IDs, a safeguard the open standard requires. Lime has not commented.

A security researcher says Lime may not be rotating vehicle identifiers in its public General Bikeshare Feed Specification (GBFS) data, which would let anyone with an internet connection infer where individual bike and scooter rentals begin and end. Gadget Review first reported the claim. Lime did not respond to its request for comment, and the findings have not been independently verified.

How the trip inference works

Lime publishes the location, battery level and status of every available vehicle in a public feed that requires no authentication. When a rider unlocks a vehicle, it drops out of the feed. When the trip ends, it reappears at its new parking spot.

If the vehicle ID stays the same across those two events, an observer polling the feed at regular intervals can match the disappearance to the reappearance. The first location is the trip’s origin and the second is its destination. The method needs no access to Lime’s backend, rider accounts or payment systems. Everything it uses is already public.

Timing sets the precision. GBFS feeds publish a time-to-live (TTL) value telling consumers how often to refresh. With a 60-second TTL, an observer can timestamp each event to within about a minute, which is enough to place a start or end point on a specific street for urban trips that typically last 10 to 25 minutes.

A paper presented at the 2026 Privacy Enhancing Technologies Symposium (PETS) tested this disappearance-and-reappearance approach. Its authors reported reconstructing more than 80 percent of trips in two cities, including in systems that had some baseline privacy protections.

What the GBFS standard requires

GBFS is a JSON-based open standard maintained by the nonprofit MobilityData and first developed in 2015. Operators use it to publish feeds covering docking stations, station availability, free-floating vehicles (free_bike_status, called vehicle_status in newer versions), service alerts and geofencing zones. Trip-planning apps such as Citymapper, Transit and Google Maps read these feeds to show riders nearby vehicles.

The specification includes two privacy rules. Vehicle identifiers in public feeds must be replaced with a new random string after each completed trip, and vehicles in an active rental must not appear in any public feed. Under rotation, a scooter listed as LIME-4827 before a trip would reappear as something like LIME-9153 afterward, and an observer would have no way to link the two.

Where Lime’s implementation may fall short

A 2022 peer-reviewed study in an urban informatics journal found that Lime moved from static to rotating vehicle IDs at some point after September 2019. Whether rotation is applied in every city, for every vehicle type and in every regional deployment has not been verified.

The reporting points to several possible causes, none of them confirmed:

• Older hardware may report a fixed identifier that must be remapped on the server before publication. If that layer is missing in one regional instance, the raw ID reaches the feed.
• Operators often run separate backends in different regions for data-residency reasons, such as GDPR in Europe, LGPD in Brazil and PDPA in Singapore. Rotation logic has to be built and tested in each one.
• Some city agreements require vehicle-level data for maintenance or parking enforcement, which can push an operator toward stable identifiers.
• A content delivery network can serve a cached response that still carries the pre-rotation ID for a short window after the origin database has changed.

Why vehicle data can become personal data

The feed contains no names, email addresses, phone numbers or payment details, so it does not hold personal data in the usual sense. Location researchers have long argued that the line blurs once data is collected over time.

A single origin and destination reveals little. Repeated pairs at consistent times reveal more: a weekday departure from one residential street, an arrival near a commercial district half an hour later, an occasional stop near a medical facility. An observer could read those as a probable home, workplace and healthcare provider, then confirm the match using property records, social media geotags or employer directories.

The underlying math is well established. A 2013 study by de Montjoye and colleagues, published in Scientific Reports, found that four spatiotemporal points were enough to uniquely identify 95 percent of people in a mobile-phone dataset. Each inferred trip supplies two points, so a few weeks of observation can pass that threshold.

Regulatory and municipal pressure

Lime operates in more than 200 cities across over 20 countries. Many of its operating permits require it to publish GBFS feeds, so taking the feed offline could breach a municipal agreement and put market access at risk. The feed can stay public while the privacy controls are fixed.

Data protection authorities may take an interest. In the EU and UK, regulators could examine the exposure under the data-protection-by-design requirement in GDPR Article 25 and the re-identification language in Recital 78, even though the feed publishes no directly personal data. The US Federal Trade Commission has pursued data brokers over precise geolocation data, and the European Data Protection Board has warned that location trajectories can reveal sensitive information such as health, political or religious activity.

Mitigations

The GBFS specification and location-privacy research point to several fixes:

• Rotate each vehicle’s ID to a cryptographically random value, such as a UUIDv4, after every trip, and purge the old ID from feed-facing caches at the same time. This is the control the standard mandates and the most effective one.
• Truncate published coordinates to three decimal places, about 111 meters, instead of six. Trip-planning apps work at block-level precision and would not notice.
• Delay a vehicle’s reappearance in the feed by 60 to 180 seconds so observers cannot timestamp it precisely.
• Apply per-IP rate limiting and anomaly detection. A client polling every 10 seconds from one address looks different from a trip-planning app polling every 90 seconds across distributed infrastructure.
• Add calibrated noise to published coordinates, using techniques from differential privacy.
• Give regulators and contracted partners an authenticated feed with stable identifiers, and keep the public feed on rotated ones.

What remains unconfirmed

• Whether rotation fails across all of Lime’s markets or only in certain regions, vehicle classes or backend deployments.
• Whether the researcher reported the issue to Lime through a disclosure channel, and what Lime said if so.
• Whether any city agreement requires a feed configuration that conflicts with GBFS privacy rules.
• Whether Lime has published a statement, advisory or engineering post on the matter.

Because GBFS feeds are public, other researchers can poll Lime’s endpoints in any city and check whether IDs change across trip boundaries. MobilityData may also issue guidance on enforcing the rotation requirement.

What this means for riders

The feed does not expose a rider’s name, account or payment information, and a single rental does not produce an identifying record. People who make the same trip regularly, such as home to work or home to school, create the repeated patterns that are easiest to infer.

Account settings, data-deletion requests and marketing opt-outs have no effect on the feed, which runs independently of user accounts. The practical protections are technical and regulatory: consistent GBFS compliance, independent audits of feed implementations, and permit language that requires privacy-preserving feed configurations.

Lime has not said whether the behavior the researcher describes reflects its current systems.