After I started working for Collabora in April, I've finally been able to put some time on maintenance and development of Geoclue again. While I've fixed quite a few issues on the backlog, there has been some significant changes as of late, that I felt deserves some highlighting. Hence this blog post.

Leaving security to where it belongs

Since people's location is a very sensitive piece of information, security of this information had been the core part of Geoclue2 design. The idea was (and still is) to only allow apps access to user's location with their explicit permission (that they could easily revoke later). When Geoclue2 was designed and then developed, we didn't have Flatpak. Surely, people were talking about the need for something like Flatpak but even with those ideas, it wasn't clear how location access will be handled.

Hence we decided for geoclue to handle this itself, through an external app authorizing agent and implemented such an agent in GNOME Shell. Since there is no reliable way to identify an app on Linux, there were mixed reactions to this approach. While some thought it's good to have something rather than nothing, others thought it's better to wait for the time when we've the infrastructure that allows us to reliably identify apps.

Fast forward to an year or so ago, when Flatpak portals became a thing, I had a long discussion with Matthias Clasen and Bastien Nocera about how geoclocation should work in Flatpak. We disagreed on our approach and we forgot about the whole thing then.

Some months ago, we had to make app authorizing agent compulsory to plug some security holes and that made a lot of people who don't use GNOME, unhappy. We had to start installing the demo agent for non-GNOME as a workaround. This forced me to rethink the whole approach and after some more long discussions with Matthias and a lot of thinking, the plan is to:

• Create a Flatpak geolocation portal. Matthias already has a work-in-progress implementation. I really wanted the portal API to be as identical to the Geoclue API but I failed to convince Matthias on that. This is not that big an issue though, as at least the apps using GeoclueSimple API will not need to change anything for accessing location from inside the Flatpak sandbox.
  
  
• Drop all authorization from Geoclue and leave that to the geolocation portal. I've already dropped authorization for non-flatpak (i-e system) apps in git master. Once the portal is in place and GNOME shell and control-center have been modified to talk to it, we can drop all app authorizing code from Geoclue.
  
  Note that we have been able to reliably identify Flatpak apps and it's only the system apps that can lie about their identity.

A modern build system

Like many Free Software projects, Geoclue is also now using Meson for its builds. After it started to work reliably, I also dropped autotools-based build completely. The faster build makes development a much more pleasant experience.

And a modern issue tracker to go with it

Bugzilla served us well but patches in Bugzilla are no fun, even though git-bz makes it much much better. So when Daniel Stone setup gitlab on freedesktop.org, Geoclue was one of the first few projects to move to gitlab. Now it's much easier and simpler to contribute to Geoclue.

Minimize GeoIP use

While GeoIP is a nice backup if you have neither WiFi hardware nor a cellular modem, Geoclue would also use (only) that if an app only asked for city-level accuracy. Apps like GNOME Weather and GNOME Clocks ask for only that since that's the info they need and don't need to know which street you're currently on. This would be perfect if only the GeoIP database being used would be correct or accurate for at least 90% of the IP addresses but unfortunately the reality is far from that. This meant, a significant number of people getting annoyed with these apps showing them time and weather of a different town than their current one.

On the other hand, we couldn't just use a more accurate geolocation source (WiFi) since an app should not get more accurate location it asked for and it was authorized for by the user. While currently we don't have the UI in GNOME (or any other platform) that allows users to control the location accuracy, the infrastructure has always been in place to do that./

Recently one person decided to not only report this but had a good suggestion that I recently implemented: Use WiFi geolocation for city-level accuracy as well but randomize the location enough to mitigate the privacy concerns. It should be noted that while this solution ensures that apps don't get more accurate location then they should, it still means sending out the current WiFi data to the Mozilla Location Service (MLS) and Geoclue getting a very accurate (street-level) location in response. It's all over HTTPS so it's not as bad as it sounds.

The future of Mozilla Location Service

When Mozilla announced their location service in late 2013, Geoclue became one of it's first users as it was our only hope for a reliable WiFi-geolocation source. We couldn't use Google's service as their ToC don't allow it to be used in an open source project (I recall some clause that it can only be used with Google Maps and not any other Map software). MLS was a huge success in terms of people contributing WiFi data to it. I've been to quite a few places around Europe and North America in the last few years and I haven't been to any location, that is not already covered by MLS.

Mozilla's own interest in this service was tied to their Firefox OS project. Unfortunately Firefox OS project was abandoned two years ago and Mozilla lost its interest in MLS as a result. Mozilla folks are the good guys so they have kept the service running and users can still contribute data but it's no longer developed or maintained.

Since this is a very important service for all users of geoclue, I feel very uneasy about this uncertain future of MLS. So consider this a call for help. If your company relies on MLS (directly or through Geoclue) and you'd want to secure the future of Open Source geolocation, please do get in touch and we can discuss how we could possibly achieve that.

Visit Zeeshan's blog.