UX Design · Study deck
Location Privacy: Boundaries and Patterns
This first route follows location data through its boundaries and applies privacy-preserving design and consent controls.
UX Uma is your guide for this deck.
After studying this chapter
Learning objectives
You will be able to:
- Assess Privacy Risks: Evaluate the sensitivity of location data and potential for re-identification
- Apply Privacy-Preserving Patterns: Implement tiered disclosure, anonymous aggregation, and on-device geofencing
- Explain E911 Requirements: Describe regulatory mandates for emergency location services and accuracy thresholds
- Design Ethically: Justify design decisions that balance safety, functionality, and user autonomy in location-aware IoT systems
Major section
Start Simple
The family needs a useful arrival alert.
- They do not need a permanent map of every child and driver.
- The service designer should begin with the job.
- The result should protect people even when the day does not go to plan.
- It should state the job, people, place detail, start time, stop time, saved copies, and help route.
Major section
Start Simple (continued)
A new team member can then see why each fact exists.
- If no one can explain a field, remove it from the plan.
- At the end of the saved period, verify that old records are gone from the main service and its planned copies.
- The bus alert needs a route area.
- It may need the next stop.
Major section
Location Privacy Boundaries
A design that stores a continuous coordinate trail for all four questions has crossed the product boundary.
- Privacy-preserving location design makes the boundary visible.
- Users should know when tracking is off, paused, active, coarse, precise, emergency-only, or shared with another person.
- That boundary should be stated in product language before the team chooses a sensor.
Major section
Location Privacy Boundaries (continued)
The interface should also show what happens when operating-system permission changes, such as Android approximate location, iOS Precise Location being disabled, background location being denied, or Bluetooth scanning permission being revoked.
- The final: Fix Decision reduces detail, retention, or collection frequency, carrying the chapter's purpose and control principles into an auditable privacy choice.
- A family safety app might need "arrived at school" and "SOS location now," not a minute-by-minute route.
- A workplace comfort system might need "zone occupied" and "zone recently empty," not a named employee trail.
- The user experience should also reveal uncertainty.
Major section
Location Privacy Boundaries (continued)
Children, guests, employees, delivery drivers, patients, bystanders, and nearby device owners can appear in location-derived data.
- A fleet system might need "stop confirmed," "break mode active," and "emergency assistance requested," not every off-route errand.
- The privacy design is stronger when the feature can still be explained without showing a raw map.
- Without that record, later analytics, support tooling, or partner integrations can turn a narrow feature into broader surveillance.
Major section
Data Flow Before Maps
A phone can evaluate a geofence locally through Android Geofencing API, Google Fused Location Provider, Apple Core Location region monitoring, or the browser Geolocation API.
- A wearable can convert GNSS, BLE proximity, UWB room state, or Wi-Fi BSSID observations into a zone event before upload.
- A building system can store occupancy counts from PIR, CO2, or mmWave presence sensors without naming individuals.
- The server should receive the least precise event that still runs the feature.
Major section
Data Flow Before Maps (continued)
A privacy review should include screenshots or test notes for each denied, approximate, paused, and restored state.
- For many automations, that means "entered home geofence," "asset near dock 3," "room occupied," or "driver arrived at stop 17" rather than raw latitude/longitude.
- When precise location is justified, such as SOS, fall detection, E911-like emergency escalation, or turn-by-turn navigation, shorten retention and mark the event with the reason precision was used.
- Dispatchers, caregivers, supervisors, support agents, and analytics users rarely need identical views.
Major section
Minimize Before Persisting
Location systems need minimization at the edge, in transit, and at rest.
- In transit, use TLS and avoid query-string coordinates.
- Bluetooth LE identifiers, Wi-Fi BSSID lists, device ids, advertising ids, installation ids, and repeated timestamps can re-identify a person even when a name is removed.
- Implementation should treat privacy as data-plane behavior.
Major section
Minimize Before Persisting (continued)
Security controls should match the sensitivity of location history.
- Aggregation needs suppression thresholds or differential privacy noise when outputs are shared beyond the immediate operational team.
- Access boundary: separate user view, caregiver view, dispatcher view, support view, and analytics view so one role does not inherit every location detail.
- Automated tests can keep the contract honest.
Major section
Minimize Before Persisting (continued)
Failure mode: when permission is denied, sensors disagree, or the event is stale, explain the degraded behavior without pushing users into unnecessary tracking.
- A mobile client can keep raw latitude and longitude in memory long enough to evaluate a geofence, then upload only a signed zone transition with a monotonic event id.
- A gateway can translate room-level UWB or BLE observations into an occupancy topic before publishing to MQTT.
- An API can reject coordinate fields on endpoints that accept only zone events.
- A database can place precise emergency records in a short-retention table instead of the same table used for routine analytics.
Major section
Minimize Before Persisting (continued)
If the product supports export or deletion, keep enough indexing to find all records for the user without joining through a raw coordinate trail.
- Enforce authorization on both live and historical reads, protect admin dashboards with least-privilege roles, log access to precise or emergency events, and alert on bulk exports or unusual support lookups.
- Encrypting a coordinate column is helpful, but it does not solve purpose creep if analytics jobs, feature stores, or partner webhooks receive the same precise data.
- The safer pattern is to minimize first, then encrypt, audit, and expire the records that remain.
Major section
Privacy-Preserving Design Patterns
Bad (invasive):: Track "John's phone is in Conference Room A".
- On zone transition, sends trigger: "Entered zone 'Home'" (no coordinates).
- Server never sees GPS coordinates, only zone events.
- Preserves general patterns while preventing individual tracking.
Major section
Checkpoint: Privacy Patterns
Emergency systems are different because regulation can require precise, timely location under constrained conditions.
- You now know why anonymous aggregation, on-device geofencing, and differential privacy reduce both risk and stored data.
- You now know how consent change reviews catch precision, timing, audience, control, and retention changes before release.
- The design patterns reduce routine collection.
Major section
For Beginners: Why E911 Matters for IoT
The Problem:: When you call 911 from a landline, emergency responders know exactly where you are—the phone is physically connected to your address.
- This drove massive investment in mobile location technology, making GPS and network-based positioning standard features in every phone—technology that IoT devices now use for tracking, geofencing, and safety applications.
Major section
For Beginners: Why E911 Matters for IoT (continued)
In Figure: Comparison of E911 accuracy requirements for handset-based and, retain: METHOD beside 150 m so e911 handset vs network tiers remains explicit.
- IoT Design Implication:: When specifying location accuracy for safety-critical IoT applications, use the 95% threshold (worst-case) rather than typical accuracy.
- Indoor limitations:: E911 accuracy requirements were designed for outdoor mobile calls.
- Vertical location gap:: Traditional E911 provides horizontal position only.
Major section
Checkpoint: Emergency Accuracy
You now know how E911 separates typical and worst-case accuracy expectations.
- You now know why horizontal, vertical, indoor, and rural conditions need different technology choices.
- You now know when emergency use justifies precision that routine automation should avoid.
- Emergency rules show when precision is justified.
Deck summary
Key takeaways
The family needs a useful arrival alert.
- A new team member can then see why each fact exists.
- A design that stores a continuous coordinate trail for all four questions has crossed the product boundary.
- The interface should also show what happens when operating-system permission changes, such as Android approximate location, iOS Precise Location being disabled, background location being denied, or Bluetooth scanning permission being revoked.
- Children, guests, employees, delivery drivers, patients, bystanders, and nearby device owners can appear in location-derived data.
Retrieval practice
Recall check
UX Uma says: answer from memory, then check your reasoning.
Q1A smart home app wants to trigger 'preheat house' when the user is approaching home. Which privacy-preserving approach achieves this without creating a location trail?
Show answer
Answer: B On-device geofencing processes GPS data locally on the phone, only transmitting a zone-enter event when the user approaches home, avoiding any location trail on external servers.
Print reference
Answers
Answer key.
- B · On-device geofencing processes GPS data locally on the phone, only transmitting a zone-enter event when the user approaches home, avoiding any location trail on external servers.