💻 computer science

Safe2Hail: A Forensic-Driven Post-Trip Tracking Framework for Ride-Hailing Safety in Africa

Safe2Hail is a forensic-driven framework designed to enhance ride-hailing safety in Africa by implementing a secure, lightweight post-trip tracking mechanism that logs proximal data between passengers and drivers after a ride ends, addressing the critical safety gap left by current in-trip-only measures.

Original authors: Alvina Minja, Robert Maina, Mahmud Oloyede, Jema Ndibwile

Published 2026-07-09

📖 5 min read🧠 Deep dive

CC BY 4.0

Original authors: Alvina Minja, Robert Maina, Mahmud Oloyede, Jema Ndibwile

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are taking a ride-share in a busy city like Nairobi or Dar es-Salaam. You get in the car, the app tracks your journey, and you feel safe because you know where you are. But what happens the moment the ride ends? Or worse, what if the driver cancels the ride halfway through, or you are dropped off in the wrong place?

According to the paper, current safety apps are like security guards who clock out the second you step out of the car. Once the trip is officially "over" in the app, the safety features (like live location sharing or SOS buttons) stop working. If something bad happens right after the ride ends, or if the ride was cut short suspiciously, there is no digital record left to help investigators figure out what happened.

Safe2Hail is a new idea designed to fix this "blind spot." Think of it as a digital "shadow" that stays with you for a little while after the ride ends, just in case.

Here is how the paper explains it, using simple analogies:

1. The Problem: The "Off-Switch" Gap

Currently, ride-hailing apps are like a movie that stops playing the moment the credits roll. If a crime happens during the credits, the movie doesn't record it. The researchers found that many dangerous situations—like robberies, harassment, or kidnappings—happen right after a trip is canceled or ends early. The apps don't track these moments, leaving a "forensic gap" (a missing piece of evidence).

2. The Solution: The "Post-Trip Shadow"

Safe2Hail is a framework that acts like a temporary security camera that keeps rolling for a few minutes after the ride is supposed to be over.

How it works: If the system detects something weird (like a ride ending suddenly in a bad neighborhood, or the driver taking a strange detour), it doesn't just stop. Instead, it switches into a "Post-Track" mode.
The "Proximity Sync": Imagine the passenger's phone and the driver's phone are holding hands digitally. Even after the ride is canceled, these two phones keep whispering to the Safe2Hail server every 30 seconds, saying, "I'm still here," and "I'm still here."
The Distance Check: The system uses math (called the Haversine formula, which is just a fancy way to measure the distance between two points on a globe) to calculate how far apart the driver and passenger are.
- If they stay close (within 10 meters) for a while, the system logs it as a "close proximity event." This is crucial evidence. It proves that even though the app said the ride was over, the passenger was still physically near the driver.
- If they drift apart (more than 50 meters), the system stops logging and marks them as "separated."

3. The "Risk Score" Dashboard

The researchers built a dashboard that looks like a traffic light system for danger.

They created a "Risk Matrix" (a scoring chart) that looks at different factors: Is it late at night? Is the area known for crime? Does the driver have a bad history?
If a trip has a high "Risk Score" (like a red light), the system pays extra attention. It treats the trip as suspicious and triggers the "Post-Track Shadow" immediately.
The dashboard shows a graph of the distance between the driver and passenger over time, helping investigators see exactly what happened after the ride ended.

4. What They Actually Tested

The paper describes a simulation (a test run), not a real-world deployment on actual Uber or Bolt users yet.

They built a "fake" ride-hailing app using computer code.
They created scenarios where rides ended early or went off-route.
The Result: The system worked. It successfully kept tracking the distance between the "fake" driver and passenger after the ride ended. It correctly identified when they were close together and when they separated. It logged this data securely and privately.

5. The Limitations (What the paper admits)

The authors are honest about the current limits:

It needs cooperation: The system only works if both the driver and passenger keep their phones on and GPS active. If a bad actor turns off their phone or GPS, the "shadow" disappears.
GPS isn't perfect: In very crowded cities with tall buildings, GPS signals can be fuzzy. The system uses a "buffer zone" (10 to 25 meters) to account for this fuzziness, but it's not as precise as a high-tech sensor.
It's a prototype: This is a "beta test" version. It hasn't been rolled out to millions of real users yet, so we don't know how it handles real-world chaos like bad internet connections or people trying to hack the system.

Summary

In short, Safe2Hail is a proposal to stop ride-hailing apps from "forgetting" you the second the trip ends. It adds a safety net that keeps a temporary, private, and encrypted record of whether a passenger and driver stayed close together after a ride was canceled or ended early. This gives police and investigators a "digital trail" to solve crimes that currently go unsolved because the app stopped watching too soon.

Technical Summary: Safe2Hail – A Forensic-Driven Post-Trip Tracking Framework

1. Problem Statement

Ride-hailing services in East Africa (specifically Kenya and Tanzania) have expanded rapidly, yet they face persistent safety challenges that current platform measures fail to address. While existing safety features—such as SOS alerts, live location sharing, and GPS monitoring—are effective during a trip, they cease operation immediately upon trip cancellation or premature termination. This creates a critical "forensic gap" where safety threats, including robbery, abduction, and harassment, can occur after the official trip endpoint without any digital trace.

The specific problem addressed is the lack of accountability and traceability when a trip is ended prematurely (e.g., driver or passenger cancels mid-route, unauthorized destination changes, or GPS spoofing). In these scenarios, passengers are often left stranded in unsafe locations, and investigators lack the data necessary to reconstruct events or verify proximity between the driver and passenger post-incident.

2. Methodology

The authors propose Safe2Hail, a modular, forensic-aware framework designed to extend monitoring beyond the official trip duration. The methodology involves three core components:

A. System Architecture

The system is implemented as a lightweight middleware platform consisting of:

Trip Data Simulator: Generates trip telemetry and triggers anomaly detection.
Post-Track Engine: The core forensic component that initiates a "Proximity Sync" sequence upon detecting a trip anomaly (specifically premature endings).
Dashboard: A web-based interface for visualizing trip data and post-track logs.

The backend utilizes Python (Flask) for the API server, SQLite with SQLAlchemy for data persistence, and Chart.js/Leaflet.js for visualization.

B. Anomaly Detection and Risk Scoring

The system identifies 13 specific trip anomalies, including premature trip endings, significant route deviations, and GPS anomalies. To prioritize these, the authors developed a Contextual Risk Matrix using a multiplicative scoring model:

Risk Score ( $R$ ): Calculated as $R = C \times R_h \times T_d$ , where $C$ is the crime-level score (based on location), $R_h$ is the rating-history multiplier, and $T_d$ is the time-of-day multiplier.
Event Scoring: Anomalies are scored based on Likelihood (1–5) and Impact (1–5). For instance, "SOS Triggers" and "Premature Trip Endings" received the highest scores (25 and 20, respectively), prioritizing them for the post-track engine.

C. Post-Track Proximity Sync Logic

When a trip ends prematurely and the endpoint is more than 50 meters from the intended destination, the system initiates a temporary synchronization:

Mechanism: The driver and passenger devices exchange GPS coordinates every 30 seconds via an encrypted channel for a retention period (e.g., 5 minutes).
Distance Calculation: The system uses the Haversine formula to calculate the real-time distance between the two devices.
Thresholds:
- 10 meters: Indicates the passenger is likely still inside or physically close to the vehicle.
- 25 meters: Approximates separation scenarios, accounting for GPS accuracy variance in urban environments.
- 50 meters: The threshold for terminating the sync and marking the status as "separated."
Data Handling: All logs are anonymized, encrypted, and stored in a relational database to ensure forensic traceability without compromising user privacy.

3. Key Contributions

The paper outlines three primary contributions:

Post-Track Mechanism: A lightweight module that temporarily extends monitoring after trip anomalies to preserve verifiable digital trails while maintaining privacy.
Contextual Risk Mapping: A systematic risk matrix that classifies and ranks trip anomalies specific to the contexts of Tanzania and Kenya.
Dynamic Risk Multipliers: A scoring system that adjusts anomaly severity based on contextual factors such as local crime rates, driver rating history, and time of day.

4. Results and Evaluation

The authors developed a working prototype and conducted beta testing using simulated environments (Flutter app simulators for drivers and passengers).

Simulation Scenarios: The system was tested against scenarios including premature endings, cancellations, route deviations, and disabled GPS.
Performance: The prototype demonstrated high accuracy in classifying post-trip proximity outcomes:
- Premature End: 95% accuracy.
- Route Deviation: 92% accuracy.
- Cancellation: 90% accuracy.
- GPS Disabled: 89% accuracy (noted as "Trace lost" in some instances due to the reliance on GPS).
Visualization: The dashboard successfully visualized the temporal evolution of proximity distance, clearly distinguishing between "proximity maintained" and "separation" events against the defined thresholds (10m and 25m).

5. Significance and Claims

The paper claims that Safe2Hail addresses a specific, unmitigated gap in ride-hailing security: the lack of forensic traceability after a trip is terminated.

Forensic Continuity: Unlike traditional apps that stop monitoring at the trip endpoint, Safe2Hail provides a continuous digital trail to help investigators determine if a passenger remained in the vehicle after an abrupt termination.
Privacy-Preserving: The system is designed to store only anonymized identifiers and distance data, avoiding the capture of personal information.
Scalability and Integration: Built on a lightweight Flask/SQLite architecture, the framework is designed to be easily integrated into existing ride-hailing infrastructures without significant overhead.
Limitations Acknowledged: The authors modestly note that the current prototype relies on cooperative device behavior (GPS must be active) and lacks Bluetooth Low Energy (BLE) or NFC verification, which limits its ability to confirm "same-vehicle" presence if GPS is disabled or signal is poor. The evaluation is based on modeling and simulation, not large-scale real-world deployment.

In conclusion, Safe2Hail proposes a scalable, forensic-driven approach to enhance accountability and safety in ride-hailing ecosystems by extending the monitoring window beyond the official trip duration.