GNOME Bugzilla – Bug 763230
Identifies location even though Location is turned off
Last modified: 2018-03-26 13:11:48 UTC
Created attachment 323271 [details] screenshot Tested on GNOME Continuous from today. I turned off location, but Maps is still able to identify my location.
It might be a problem with Continuous, because I was unable to replicate it with Fedora 24.
I saw this bug in Fedora 24 and seeing it again just now in Fedora 25. In terms of privacy and trustworthiness of the whole GNOME ecosystem, this is IMHO a very severe bug: Eve if I explicitly turn off location tracking, suddenly the Maps app knows where I am?! A not respected privacy setting is something very undesirable ...
Thanks for filing! If you restart Maps is the situation the same? And if you start Maps with location tracking off?
Restarting maps results in proper behaviour (location tracking not enabled). In fact, I could not reproduce this behaviour, even not by rebooting the whole machine. I noticed, however, a new setting in the privacy setting section that allows the Maps app to use the tracking "today". Maybe I could reproduce the bug therefore tomorrow, as the setting might be saved for one day? I have the location tracking off by default and just wondered, why Maps showed my location. Since I already saw this some months ago, I thought of reporting it this time. I will report back, if I see the bug again.
Didn't change my setting (so, location tracking is set to off in the general settings), but tested today: First start of Maps shows me my location, the top right GNOME menu says "location off" (or similar, I'm using German), the general privacy setting (settings>privacy) says in its overview "location service: in use". However, if I click on this setting, the slider is set to off. Again, restarting Maps won't show me my location (and I assume this will work until the next day begins). Also, the location submenu in the top right GNOME menu is gone and the general privacy setting says in it s overview "location service: off".
Ok, hmm this is weird. I am wondering if the bug can be elsewhere. Since we use geoclue2 dbus api and should get back ACCESS_DENIED or similar of location service is off. Zeeshan: Do you have any idea how to debug this? To clarify: Can you press the "goto user location button" in the top left of Maps or will that say location service disable? Jonas
Yes, if I start Maps for the first time, the top-left button brings me to my current location. If I restart Maps, the button prints a message that I need to allow location services first (and does not bring me to my current location).
Do you get any warnings about dconf?
(In reply to Jonas Danielsson from comment #6) > Ok, hmm this is weird. I am wondering if the bug can be elsewhere. Since we > use geoclue2 dbus api and should get back ACCESS_DENIED or similar of > location service is off. But in this case the location has already been received. Maybe Maps is not listening for changes from Geoclue. > Zeeshan: Do you have any idea how to debug this? Check if you can reproduce against geoclue's where-am-i binary and see if it does the right thing. It does so on my machine: $ /usr/libexec/geoclue-2.0/demos/where-am-i -t 100000 Client object: /org/freedesktop/GeoClue2/Client/4 New location: Latitude: 57.704193° Longitude: 11.961119° Accuracy: 80.572142 meters Timestamp: Tue 21 Feb 2017 18:24:17 CET (1487697857 seconds since the Epoch) Geolocation disabled. Quiting.. $
(In reply to Jonas Danielsson from comment #8) > Do you get any warnings about dconf? Not sure where those would pile up, but journalctl | grep dconf gives me a lot of the following lines: tracker-extract[1808]: unable to create file '/run/user/1000/dconf/user': Permission denied. dconf will not work properly. > > $ /usr/libexec/geoclue-2.0/demos/where-am-i -t 100000 this ones returns for me (non-root): ** (where-am-i:7804): CRITICAL **: Failed to connect to GeoClue2 service: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Geolocation disabled for UID 1000 and prefixed with sudo: Client object: /org/freedesktop/GeoClue2/Client/2 New location: Latitude: [correct number I won't tell in public due to privacy] Longitude: [correct number I won't tell in public due to privacy] Accuracy: 76,926591 meters Timestamp: Sa 25 Feb 2017 14:53:14 CET (1488030794 seconds since the Epoch) This information repeats itself after some time (and including "speed" information) So, root has access to the geolocation although I turned it off in my user's privacy settings? I couldn't reproduce the bug in GNOME Maps this time, by the way. It correctly reported that I'd need to enable the location service. I ran the where-am-i command before I started Maps, though.
(In reply to h.tulk from comment #10) > (In reply to Jonas Danielsson from comment #8) > > Do you get any warnings about dconf? > > Not sure where those would pile up, but > journalctl | grep dconf > > gives me a lot of the following lines: > > tracker-extract[1808]: unable to create file '/run/user/1000/dconf/user': > Permission denied. dconf will not work properly. > > > > > $ /usr/libexec/geoclue-2.0/demos/where-am-i -t 100000 > > this ones returns for me (non-root): > > ** (where-am-i:7804): CRITICAL **: Failed to connect to GeoClue2 service: > GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Geolocation disabled > for UID 1000 > > and prefixed with sudo: > > Client object: /org/freedesktop/GeoClue2/Client/2 > > New location: > Latitude: [correct number I won't tell in public due to privacy] > Longitude: [correct number I won't tell in public due to privacy] > Accuracy: 76,926591 meters > Timestamp: Sa 25 Feb 2017 14:53:14 CET (1488030794 seconds since the Epoch) > > > This information repeats itself after some time (and including "speed" > information) > > So, root has access to the geolocation although I turned it off in my user's > privacy settings? These settings are user-specific. If you login to GNOME with root and disable geolocation, you should get the same error.
I just reproduced this bug with GNOME weater. Despite my global setting of not allowing to track my location, it gave me a city closeby to my current location. So, apparently, this bug is neither in GNOME Maps nor in GNOME Weather but somewhere in the geolocation provider (or however you call this). Could someone reassign this to the proper software wher this bug originates? I still feel that this is a quite important bug, as it it messes with the trust an user provides to the OS. If the OS is not respecting privacy related issues, it's hard to trust anything that it is supposed to be ...
(In reply to h.tulk from comment #12) > I just reproduced this bug with GNOME weater. Despite my global setting of > not allowing to track my location, it gave me a city closeby to my current > location. The settings in control-panel is user-specific. Typical users are not only not supposed to run apps as root (or other user than one they are logged-in as) but also expected to run apps from sandbox (Flatpak) if they really want proper privacy control. > So, apparently, this bug is neither in GNOME Maps nor in GNOME Weather but > somewhere in the geolocation provider (or however you call this). > Could someone reassign this to the proper software wher this bug originates? > > I still feel that this is a quite important bug, as it it messes with the > trust an user provides to the OS. If the OS is not respecting privacy > related issues, it's hard to trust anything that it is supposed to be ... Going through the log, your issue is very different from Andreas. Let's not derail please. Andreas, is this still reproducible?
(In reply to Zeeshan Ali (Khattak) from comment #13) > (In reply to h.tulk from comment #12) > > I just reproduced this bug with GNOME weater. Despite my global setting of > > not allowing to track my location, it gave me a city closeby to my current > > location. > > The settings in control-panel is user-specific. Typical users are not only > not supposed to run apps as root (or other user than one they are logged-in > as) but also expected to run apps from sandbox (Flatpak) if they really want > proper privacy control. Sorry, with "global setting" I meant my user-specific global setting, I didn't use any root account here. (I just used it in reply to a previous comment). You might be right with flatplak giving you "proper privacy control" but I still think that if the desktop setting disallows tracking of my location no app ever should be allowed to bypass this. Apparently, however, this is the case here under Fedora 25 as I was just again able to see my location in Maps, even though it is turned off in my user-specific desktop-settings. Since the same thing happened the other day with GNOME Weather I still have the strong feeling there is something wrong in the geolocation layer and the setting is not properly activated / distributed. > > Going through the log, your issue is very different from Andreas. Let's not > derail please. > > Andreas, is this still reproducible? Sorry, if I hijacked this issue. I did so, because I searched the bugzilla and think this is the same bug: the first comment incl. screenshot fits to my situtation. I'm happy to open another bug report, if you do not think so.
I saw the same thing; starting Maps with "Location Services" set to "Off" in GNOME Shell Settings, Maps was able to get a general location. Shell's status area and Settings->Privacy also showed location as "in use" (despite being "Off" in the latter). Trying with Weather straight afterwards resulted in not being able to enable automatic location. Similarly, trying to read the D-Bus property directly (busctl get-property org.freedesktop.GeoClue2 /org/freedesktop/GeoClue2/Client/1/Location/0 org.freedesktop.GeoClue2.Location Latitude) resulted in "Access Denied". Enabling "Location Services" then restarting Maps/Weather resulted in a prompt for each application, and allowing/denying worked as expected. Subsequently disabling "Location Services" and restarting Maps/Weather also resulted in expected behaviour (location unavailable in each). Should this be a separate bug in GeoClue (or was one opened)?
(In reply to Stephen from comment #15) > I saw the same thing; starting Maps with "Location Services" set to "Off" in > GNOME Shell Settings, Maps was able to get a general location. Shell's > status area and Settings->Privacy also showed location as "in use" (despite > being "Off" in the latter). > > Trying with Weather straight afterwards resulted in not being able to enable > automatic location. > > Enabling "Location Services" then restarting Maps/Weather resulted in a > prompt for each application, and allowing/denying worked as expected. You mean that you were only able to reproduce the issue on the first launch of apps? > Should this be a separate bug in GeoClue (or was one opened)? We'll see. So far, I haven't seen any evidence to suggest that it's a geoclue issue. Could be more a shell/control-center issue. But first need to be clear what the issue really is. > Similarly, trying to read the D-Bus property directly (busctl get-property > org.freedesktop.GeoClue2 /org/freedesktop/GeoClue2/Client/1/Location/0 > org.freedesktop.GeoClue2.Location Latitude) resulted in "Access Denied". That's expected. Each app/client get their own Client and Location objects that no other app can access.
(In reply to Zeeshan Ali (Khattak) from comment #16) > We'll see. So far, I haven't seen any evidence to suggest that it's a > geoclue issue. Could be more a shell/control-center issue. But first need to > be clear what the issue really is. > That's expected. Each app/client get their own Client and Location objects > that no other app can access. I was wondering if Shell was just incorrectly showing location services as disabled when they're not (perhaps as a result of upgrading from pre-privacy settings versions of GNOME?), but then is there an explanation for Weather acting in a "no location allowed" manner *before* I touched Shell's location settings in my sequence of actions above? If it were a case of the Shell setting not reflecting reality, I'd expect Weather to have location access initially, the same as Maps, but then I don't know the GeoClue2/location permissions architecture really.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-maps/issues/56.