- SAP Managed Tags
Recently I conversed with a former colleague about travel plans, particularly how to get about an area with local maps and guides. They suggested to use a global corporation's mobile app, as it's "no extra charge" and ubiquitous. Yes, I countered, but I'd like to keep my privacy as much as possible, including switching off my mobile location data being fed into the global abyss.
Think about the scenario where the boss says "make sure none of our personal information is being saved in XYZ location data fields," and you realize those fitness, navigation, and foody apps have been leaving radioactive bread crumb trails of you and your team's historic plodding. Oops. Poor governance by nation or company XYZ has now introduced unacceptable risk levels. How to comply with the newly evolved privacy rules?
Google maps, the easy not so private approach:
The Three Map Problem; similar to the Four Color Map problem
Way back in my school days, we learned of the traveling sales person route optimization, using simplex method linear programming [ https://www.britannica.com/topic/simplex-method ]. Find the shortest or fastest route to visit one or more locations.
Are we safe keeping location data in the cloud? In the story https://www.yahoo.com/news/dutch-parliament-calls-end-reliance-155717872.html, Bert Hubert, a Dutch technology expert who has advocated for reducing dependency on the U.S., said "But he said one important outcome would be forcing agencies to publicly report on risks related to their reliance on U.S. cloud firms."
As Benjamin Franklin said, "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." In this case, we will keep the liberty of our privacy at the cost of building our own repository, or just not collecting data we don't want leaked.
At the time of the 2020 U.S. Census, I was recruited to be an enumerator, given an Apple phone, and sent out to collect personal data from citizens and residents. The tech behind the data collection was designed so that a field agent could record answers quickly on a mobile device, after which the content was inaccessible. With an always-on GPS, the management level could tell where the agent went, the agent could be directed from service point to service point, and the agent could not feasibly leak anything significant.
Fast forward to a new challenge--keeping a personal map of available vehicle recharging points, avoiding over-sharing with others, and getting directions when needed. The vehicle has mapping software, along with a built-in GPS, and is sourced from the manufacturer, not Google or Apple or Microsoft. Having a mobile device with another GPS source gives a second choice for location routing; adding an open source app then gives 3 navigation choices. We'll ignore the added risk to compliance if another onboard device is added, say from an occupant's mobile, or, worse, an "air tag" secreted on the vehicle for third party tracking/sleuthing.
The Simplex project I once worked on was for fire station location; using a University to present community resource shutdown options let the government officials offload political decisions to external experts and duck responsibility. Unlike a sales rep missing a call, a too-late fire or emergency response has life and health risk levels.
Without revealing any private info, including current location, can an app with preloaded map data compare to
"live" services supplied by cloud computing? How much power is used "at hand" to complete complex routing
and visible/audible guidance ("speed bump ahead")? Crowd-sourced/open-sourced data compared to private caches and compared to "learning machines" (read street signs, speed limit, real time obstructions/road conditions / hazards?
After searching for available tools, I chose the OsmAnd app for verification of suitability for on-device navigation features. Crowd-sourcing the data and the algorithms was appealing. Free was a bonus (though as it turned out, the lower-tier no-cost option was restricted and unsuitable). Starting with field practice, I used known test paths first, adding points of interest incrementally. I could use a GIS app to create lists of favorite places, then load to the app as needed. For SAP ecosystem developers, the HANA database is supported by PostGIS (present on Windows QGIS but not all Linux or BSD packaging). Waypoint export was either a KML or a GPX file. Import to the navigation app was straightforward.
Map Test Drive (torture track)
I tested the user interface, data quality, and suitability for general navigation in the map app. There were definitely oddities and idiosyncrasies, part of which could be explained by "it's different than the other apps" and part by quality control of nodes and routes. Of the 2 minor annoyances I found, both related to routing guidance. The first error was for a non-existent turn; the second I found was advice to "turn left" when the expected direction was "forward." Bonus features I found in OsmAnd were (surface water) stream direction and elevation profiles, and the default color scheme had excellent viewability.
When I posted on Mastodon about a bad turn gripe, a mapping community member replied helpfully. Within a few minutes, they had tracked down the bogus interchange and submitted a fix to the OpenStreetMap project database. Yet to be determined: how long it takes for that update to be reflected on-device, as the app vendor has multiple tiers of service level. Could be a month before new maps show the correction. Is this adequate response time for general navigation? As usual, that depends on the requirement.
Illustration: Stream flow in 2 directions in a drainage ditch:
The second major glitch I found was incorrect guidance to "turn left" when the route should not have a turn. In order to best report the error to someone who could help fix it, I went back to advice I was given to filing bug report: create a reproducible test case with minimum details, nothing extraneous. Because I saw nothing obviously wrong myself, I varied the planned start/end points, getting the same error. Good progress. Then I repeated the trip, trying to gather in situ details to determine what input data caused the invalid calculation. I also searched for similar errors ("roundabout entry/exit mangled") online, to get a clearer sense of possible variances. My working assumption at this point is the highway has turn-only lanes approaching the error point, such that the guidance should more properly be "bear left" due to a right-turn-only lane. I'm close enough to file a bug report that can be acted on, or coerce someone to correct the data anomaly causing the glitch.
Private Property Concerns
A related barrier to trusting crowd-source geo data is whether a planned route, or endpoint, is accessible. One of the chargers a search revealed turned out to be within a paid parking lot. Can't say for sure whether this is a contributor error, or data evolution ("it was reachable on the side of the road until someone put up a fence").
Related, navigation and destination data might be considered as "inclusive" or "exclusive" domains. You might need to know if your location is within certain boundaries, i.e. within 50 miles of a US national border, in or out of the immigration search zone. Or you might need to prove you *were not* there, within reasonable doubt.
- Keep data ~outside~ specific areas (quarantine zones)
- ~within~ specific areas (safe harbors / embassies)
Country or region specific rules require data be kept per above. Or, concerns about leaks to competitors, government TLA's, or bad actors. Or, just don't want to do business with Company or Country "XYZ", .e.g. boycott. Might need to follow embargo rules such as: don't do business with Cuba, Libya, North Korea, or wherever the rules of the day state.
Conclusions
Deploying an on-device, no-data-transfer mapping app is feasible, should one wish or be required to prevent privacy data leaks. Comparing huge tech company apps to much smaller open source based code and data shows a small loss of privacy freedom can be overcome by the larger feeling of safety in relative anonymity.
To do:
- Try navigating with cell data off (first results - OsmAnd worked great; Google maps still worked by complained about not being able to show current traffic conditions. Noted).
- Review data transferred (while using mobile data, see what leaks?)
- Measure power used (tricky, because the current scenario requires the mobile device to be plugged into a USB to allow Android Auto to work, so battery activity tracking is moot).
References
- OSMand
- QGis
- OpenStreetMap
- Striking a Balance: Navigating the Open-Source Tightrope in a World of Evolving Threats - Part 2
Bluesky| User | Count |
|---|---|
| 8 | |
| 8 | |
| 6 | |
| 6 | |
| 5 | |
| 4 | |
| 4 | |
| 3 | |
| 3 | |
| 3 |
