Package: gnome-clocks
Version: 3.30.1-2
Severity: important
Tags: l10n
Dear Maintainer,
Hello gnome-clock dev team. First, i would like to thank you for your
development efforts.
But I would like to address a concern i have. It came to my attention that
current stable version of the package distributed via apt repository with
Debian 10 (Buster), seems to be able to read and very precisely identify a
physical location of the host machine.
As a matter of security review, currently done against the new Debian Buster
distribution, could some one from the dev team comment and clarify how such
functionality is possible?
The OS is running on a physical host with a coreboot bios with Intel ME removed
from the host. Host doesn't have any physical hardware, like a GPS receiver to
identify it's location. Host has a network connectivity via network stack -
tcp/ip to a open internet.
During the installation of the OS, only general time zone was provided (Los
Angeles USA).
No additional customization was done to any of the components/packages/settings
or config files, and yet, when gnome-clocks was launched, it immediately was
able to identify the city where the host is connected to the network as San
Jose California.
Please note, while a general time zone was provided, package gone-clocks was
able to identify host location in its actual point of presence (City of San
Jose) with in the the same time zone as Los Angeles.
This essentially demonstrate an ability to trace the hosts location right down
to a City, while a user/owner of the host never explicitly authorized/enabled
such trace. Potentially this functionality can be used with a malicious intent
by a hacker/state actor against the user/owner of the said host.
So, my question(s):
Is this functionality specific to the code of the gnome-clocks package, or
Was the location of the host's city was derived from with in the OS itself?
Is there a way to stop gnome-clocks from identifying by default host's
geographical location.
Your feedback would be greatly appreciate, thank you for your time. Damien.
PS: Gnome-clocks version 3.22.1-1 running on Debian 9.9 (Stretch) did not
demonstrated this behavior.
-- System Information:
Debian Release: 10.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.19.0-5-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages gnome-clocks depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.30.1-2
ii geoclue-2.0 2.5.2-1
ii libc6 2.28-10
ii libcairo2 1.16.0-4
ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1
ii libgeoclue-2-0 2.5.2-1
ii libgeocode-glib0 3.26.1-1
ii libglib2.0-0 2.58.3-2
ii libgnome-desktop-3-17 3.30.2.1-2
ii libgsound0 1.0.2-4
ii libgtk-3-0 3.24.5-1
ii libgweather-3-15 3.28.2-2
gnome-clocks recommends no packages.
gnome-clocks suggests no packages.
-- no debconf information
