October 12, 2018
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.
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:
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.
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.
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.
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.
We can now confidently say that PipeWire is here to stay. But of course it is not the end of the journey. There are many new areas to explore…
Our look at the Rust crate for interconnected objects continues, as we examine how persian-rug really does tie the room together by providing…
The testing ecosystem in the Linux kernel has been steadily growing, but are efforts sufficiently coordinated? How can we help developers…
With the upcoming 0.5 release, WirePlumber's Lua scripts will be transformed with the new Event Dispatcher. More modular and extensible…
This second installment explores the Rust libraries Collabora developed to decode video and how these libraries are used within ARCVM to…
Why is creating object graphs hard in Rust? In part 1, we looked at a basic pattern, where two types of objects refer to one another. In…