KATRETTER: Balancing Life-Saving Speed with "Privacy by Design" in Disaster Response

TL;DR

In emergency response, every second counts. While spatial crowdsourcing—dispatching volunteers based on their GPS location—can save lives before ambulances arrive, it creates a massive privacy risk. This paper presents KATRETTER, a production-ready system developed with the Berlin Fire Department that uses "Privacy by Design" to protect volunteers while ensuring they can still be effectively dispatched to nearby emergencies.

The Core Dilemma: Utility vs. Privacy

In disaster management, the system needs to know where you are to tell you if you are the closest person to a heart attack victim. However, continuous GPS tracking is a hard "no" for many potential volunteers. The authors found that 54% of surveyed volunteers are against signing up with personal information, and 15% are critical of automatic location collection.

If volunteers don't trust the system, the crowd "talent" remains untapped, and response times stagnate.

Methodology: Privacy by Design

The authors don't treat privacy as a checkbox. They integrate it into the architecture across three planes: Operator, Core, and Worker.

1. Redefining Location Sensitivity

Instead of constant tracking, KATRETTER uses Location Obfuscation. The mobile app shifts the GPS center point according to a privacy preference $\lambda$.

Fig 1: The framework defines tasks based on worker count, area, and self-incentivized models.

2. The Isochrone Query Mechanism

One of the most innovative aspects is the Two-Step Assignment. When an incident occurs:

1. The server calculates an isochrone (a map area representing, say, a 3-minute walking distance).
2. It adds a "privacy buffer" to this area and identifies workers whose obfuscated locations might be inside.
3. Only these specific workers are then queried for a precise location to confirm if they can truly reach the scene in time.

Fig 2: KATRETTER Component Overview showing the separation between the Profile Endpoint and the Notification Manager.

3. Identity Protection

Workers use randomly generated pseudonyms. For "Aid" tasks requiring medical certification, authentication happens via a Trusted Third Party (TPP). The main system only knows "User X has a CPR certificate," not "John Doe is a doctor."

Experiments and Deployment

The system was tested using real-world scenarios from the Berlin Fire Department. By using iterative assignment for Aid tasks, the system ensures that exactly the right number of workers (constant $c$) are dispatched—enough to help, but not so many they interfere with professional paramedics.

Fig 3: Example of the isochrone-based inquiry (orange dots moving, green dots standing) to finalize task assignment.

Critical Insight: Why This Matters

The technical brilliance of KATRETTER lies in its obfuscation logic. By using the formula: $\lambda =\frac{max(r_{meas},r_{min})}{r_{meas}^2}-1$ the system acknowledges that GPS data is naturally "noisy." It leverages this noise as a feature for privacy, rather than a bug to be fixed.

Limitations and Future Work

The authors honestly point out that the current design is still centralized. If the "Core" plane is hacked, pseudonomyzed patterns could potentially be de-anonymized. They propose moving toward Mobile Edge Computing (MEC) in the future, where location data is processed locally on network edges rather than a central server.

Conclusion

KATRETTER proves that we don't have to choose between saving lives and protecting personal data. By building privacy into the very "math" of location services, we can create resilient, trust-based communities ready to respond when disaster strikes.