Disabling geolocation

Problem: Would like to be able to disable Geolocation requests from the Operating System level

Situation and Background:

Yesterday, I went to openstreetmaps.org or something to find out exactly where the Ottawa campus is located in relation to Ottawa for the FreeBSD Canada Conference. They asked me my geolocation. OtterBrowser asked me if I wanted to authorize this or not, I went to click no, but being fancy that I was doing it with the touch screen caused an erroneous answer. Geolocation according to my quick google searches is something used to track prisoners. I do not need to authorize tracking to people haphazardly.

I would like an option that disables it on the Operating System level as opposed to having to let applications be empowered with the situation howsoever that they choose.
 
on the IpHone there's a way to give applications the control such as location information, etc.. Is there no way to do that here?
 
No problem. The kernel source is available. Look in it for all words related to "geo" or "location". Comment out those lines. Recompile, install, done. OK, that was a joke. There are no such lines in the kernel. There are also no such lines in most libraries. Matter-of-fact, I believe there is absolutely nothing in the base system that does geolocation.

There are really two main ways that computer/tablet/cellphone uses can be geolocated. The first one is done by their "ISP" (whoever provides internet connectivity). If that is a normal landline provider (DSL, Cable modem, ...), they feed a crude estimate of the location of the hookup point into well-known databases, given your IP address. Those can be widely inaccurate. For example, for the IP address that our house uses, none of the well-known services are even in the correct county, and they get the location wrong by between 9 miles and 295 miles, with most of the databases wrong by 28 miles. Note that we live near Silicon Valley, so a circle of 28 mile radius around our house has several million people in it! So this is inaccurate, and a function of how careful your ISP is.

For internet connection via the cell phone network, the carrier can triangulate where the phone is by comparing signal strength and latency via different towers. How accurate that is depends on the geography; in rural areas (where cell towers can be a dozen miles apart), it can be as inaccurate as 1/2 mile or 1 mile; in urban areas and with "microcells", it can be good to a few dozen feet. Furthermore, in the US every cell phone by law has to have a GPS receiver and report its accurate location when making emergency (911) calls. So the cell phone carrier knows the location of cell phones (and therefore any device that uses a cell signal to get Internet connectivity) to within a few meters.

Note that all of this has nothing to do with the operating system on the client side. It is purely a function of the Internet connection! There is nothing FreeBSD can do to disable this, and some of it is legally required.

The second way of geolocating is application based, and is usually done for web or cell phone apps. If your client device (typically a cell phone, not typically a desktop or laptop computer) has a GPS receiver, client applications can query the location, and report it over the network to servers. Both iOS and Android will explicitly tell you when an application wants to do this, and ask for your permission. Some applications (such as mapping software) will obviously not function if you don't give permission, that's your choice. In FreeBSD, there is no standard API for accessing GPS receiver hardware (which is not present anyway on most machines that run FreeBSD, that being server, desktop and laptop computers). And to my knowledge, the only applications in FreeBSD that could even communicate this would be web browsers. So there is no need to disable anything here, unless you have a GPS receiver and are running some web page that knows how to access it.
 
It's a bit different with a computer compared to a phone. Phones have a far better idea of where you are because of how they work. That's why the phones tend to be a bit more "in your face" about checking if you want to share your location.

With a computer you are sitting on your home network. You can still be geo-located - very roughly - based on your IP address. Your search terms and IP will be sent to the remote server, and they'll be able to work out to possibly at least city level where you are located.

So for something like FreeBSD not sharing your location doesn't really make any sense - because it doesn't know your location, nor can it conceal it.

If you were using OtterBrowser on FreeBSD, the location it would have shared would probably have been very broad (and most likely quite wrong - my browsers usually place me hundreds of kilometres out!)
Geolocation according to my quick google searches is something used to track prisoners
Not sure where you got that from.

Geolocation allows apps to return location-appropriate information to you. If you are in Norwich, England and search for "good pub" then you probably don't want to know about pubs in Angola. Yes, it can be used in other ways to track people (including prisoners).

Your phone provider will always know exactly where you are (well, where your phone is!), and depending on where you live, will be required by law to store that information for months if not years, and potentially give that information to the authorities.
 
1673323377035.png

makes sense, I tried it on my computer it seems to work as you said ... doesn't seem to reveal anything spectacular as you said... I would have deleted my post then but I couldn't so I decided to stick out the challenge... but thank you for clearing this up...
 
I worked for a location project on a telco operator.
I could follow myself on a map where i was at which time and how i traveled.
With different antenna's and certainly 3G/4G triangulation is possible and relative precise.
Note: The marketing people wanted to send the "best bars" based on your position. But there where also legal concerns. opt-in/opt-out.
 
It's a bit different with a computer compared to a phone.
Right, but the real world is more complicated. The difference is not between a computer and a phone, but between network connection via an ISP (like DSL from the phone company, cable internet from the TV company, several wireless and satellite providers) and connection via the cellular network. Today, many cell phones communicate via WiFi when there is fast and trusted WiFi around, which means that the location accuracy of the cell phone suddenly drops to what is available for the IP address. Conversely, some computers connect to the internet via a cell phone interface (I have a RPi with a cell modem, and cell modems are available on laptops), so now you have a computer with cell-phone like location accuracy.

One other thing of note: There is a lot of research going on to make geolocation of cell phones much more accurate and always available. Two examples: Today, mapping and navigation programs use the speed at which cell phones travel to measure traffic flow, and then base their suggested routing on the observed speeds. This is how navigation programs can give you reasonably accurate forecasts of how long the trip is going to take, and how they can help avoid traffic jams. But today, that is based on relatively little data: Only cell phones that have explicitly opted into feeding location data back to the server can be used, and only GPS-accurate data is transmitted back (often sloppy by dozens of meters). Imagine how much more accurate that data would be if the navigation services could receive data from many more phones, and also get speed and heading information: not just "I'm now here, I was there earlier", but also "I'm travelling at 37 km/h in direction 237 degrees". Clearly, the privacy implications mean that this data would have to be totally anonymized: Not "I am travelling ..." but "some unknown person is traveling". The trick here is how to anonymize the data, while still allowing insights into what is really going on. For example, four people traveling in the same direction at the same speed could be four cars that by coincidence are moving together, or it could be four adults in the same car; for traffic planning those need to be treated differently. Similarly, if someone gets on a bus, and than 10 minutes later gets off the bus and walks the last block to their house, the way the data is anonymized has to allow the server to distinguish that one walking person from the rest of the bus (which is probably speeding towards the next stop). This is a complex information theoretical problem.

The other area of research I know of is to make cell phone location much more accurate, at least to a meter, ideally to within a few inches. The idea is to help people navigate within buildings. For example, today the calendar program tell you "You have a meeting in 5 minutes in conference room XYZ". In the future, it could give you navigation within a building, like saying "open the door to the hallway, now turn left and go up the stairs, and now go through the door". Where this is of particular importance is for disabled people (for example the blind) to navigate within an office building. It may sound superficial, but simply helping a blind person to get to the restroom or the cafeteria in their office building without needing an attendant to lead them would be a huge quality of life improvement.
 
Ugh.

If you use a browser like Chrome it geolocates you based on triangulation of the different wifi networks and their relative strengths around you, That is a lot more precise that just using the IP address of the wifi hub, it uses all your visible networks to triangulate. Of course you can turn off transmitting this location to websites, but Chrome itself has an excellent idea unless you are on a hardwired desktop with no wifi chip.
 
Are you saying that Chrome contains the functionality to configure the OS layer to switch to different WiFi networks?

On a normal Unix-based desktop OS (whether it's Linux, FreeBSD, or MacOS), a Chrome browser can only see the IP connection(s) that the OS provides. And since all these OSes provide one IP connection to Chrome (which does its network IO by opening sockets), Chrome itself has no means to see any information about WiFi networks, in particular not signal strength, and definitely not switch to different WiFi base stations.
UPDATE: See cracauer's message below: Using dbus, Chrome can see Wifi signal strength data for all access points.

Now, if you move around with a Unix device and use a WiFi access points whose location is very accurately known, then the normal IP-based geolocation will work excellently. For example, you're sitting on a laptop at Starbucks, and using their free public WiFi, then your IP address indicates which network you're using, and Starbacks and/or their ISP might have configured accurate location information. But conversely, if you're just driving by a Starbucks while computing in the back seat, and don't connect to the Starbucks WiFi (which on all OSes I know of requires active participation from the user), then Chrome will not know that we just drove right past a Starbucks WiFi (I'm just using Starbucks as an example of a ubiquitous set of free WiFi access points in fixed locations, McDonals works just as well).

On ChromeOS (where the Chrome browser is more tightly integrated with the OS layer) and on Android, that's a different story. On Windows, I have no idea how things work (nor do I care terribly much).
 
Are you saying that Chrome contains the functionality to configure the OS layer to switch to different WiFi networks?

On a normal Unix-based desktop OS (whether it's Linux, FreeBSD, or MacOS), a Chrome browser can only see the IP connection(s) that the OS provides. And since all these OSes provide one IP connection to Chrome (which does its network IO by opening sockets), Chrome itself has no means to see any information about WiFi networks, in particular not signal strength, and definitely not switch to different WiFi base stations.

Now, if you move around with a Unix device and use a WiFi access points whose location is very accurately known, then the normal IP-based geolocation will work excellently. For example, you're sitting on a laptop at Starbucks, and using their free public WiFi, then your IP address indicates which network you're using, and Starbacks and/or their ISP might have configured accurate location information. But conversely, if you're just driving by a Starbucks while computing in the back seat, and don't connect to the Starbucks WiFi (which on all OSes I know of requires active participation from the user), then Chrome will not know that we just drove right past a Starbucks WiFi (I'm just using Starbucks as an example of a ubiquitous set of free WiFi access points in fixed locations, McDonals works just as well).

On ChromeOS (where the Chrome browser is more tightly integrated with the OS layer) and on Android, that's a different story. On Windows, I have no idea how things work (nor do I care terribly much).

Here is the Linux version of the geolocation-via-wifi part:

It reads the list of networks and their strength for all wifi devices.
 
That's fascinating. Completely surprises me: I didn't know that Chrome/Chromium talks to dbus to get lists of WiFi networks, other than the one that is currently active.

I wonder whether browsers can also look at Bluetooth information.

Thank you for digging that out and convincing me.
 
Back
Top