Key part of the article: a patent claim from Skyhook forced Mozilla to alter the service in a way they couldn't keep it working.

I'm not surprised this drifted into disuse.

Both Apple and Android smartphones come with a built in location service, which also has GPS. Firefox OS, which might have needed this service, is no longer around.

Desktops and laptops are rarely used for navigation - the only uses of the geolocation api for desktop web browsers I've encountered are when you go to a retailer's store finder page, and they have a button to use your current location. And even then, the geolocation api is competing with IP geolocation (which doesn't show the user an ominous consent popup)

And I don't imagine it was easy for Mozilla to get quality data - if their service is mostly used by the most privacy-focussed users, I don't imagine those users were lining up to submit their geolocation and wifi data to a public database.

Really sad to see it go. It powers KDE Plasma's geolocation for its Night Colors feature among other FOSS projects.

For those wondering, Skyhook is a "location technology company" that was acquired by Qualcomm

https://www.skyhook.com/

What service can replace this in microG? Most Android ROM relies on it for location services :(

Reminds me of a problem I had in NYC back in 2019. There was one station in Manhattan and when I went in there my phone always though I was somewhere out in Brooklyn. Even with WiFi off. It only happened on Android no IOS. It was like this for a long time and I tried many times reporting it as an issue on Google maps. Confirmed the issue with many friends who used Android.

I don't know exactly how these things work but I always suspected that some WiFi AP got repaired and moved to a new location and was broadcasting an SSID that used to be somewhere else for a long time.

Or could it be caused by something else?

Thank you Skyhook Holdings, Inc.

The rather troubling part of this announcement in a GitHub issue is that this nugget comes out in a seemingly innocuous comment[1]:

>> Firefox still uses MLS for `browser.region.network.url`; will that also move to Google Location Services?

> This endpoint will be migrated to another service (classify-client) that will return the expected response. We'll adjust DNS entries when it's time to make that move so firefox won't see any difference.

What exactly is this "classify-client" service?

Note also this led me to discover for the first time that this is a thing[2]:

> Geolocation for default search engine

> In order to set the right default search engine for your location, Firefox will perform a geolocation lookup once by contacting Mozilla's servers and store the country-level result locally. This connection happens on the first start of Firefox – in case you want to prohibit that, you will have to preconfigure the browser and set the browser.search.geoip.url preference to a blank string.

Also related is [3].

[1]: https://github.com/mozilla/ichnaea/issues/2065#issuecomment-...

[2]: https://support.mozilla.org/en-US/kb/how-stop-firefox-making...

[3]: https://old.reddit.com/r/firefox/comments/iq27wa/disabling_l...

I think this is a good thing in the long-run.

Relying on WiFi access points to geolocation was always a bit of a hack and in my experience it's allowed phone manufacturers to roll back on the quality of their satellite-based GPS implementations and worsened phone battery life ; now the phone is constantly scanning for WiFi access points and Bluetooth and shuffling that data back to the mothership(s) on the user's data plan.

My old Samsung S4 could get a GPS lock (sans Internet, WiFI, in airplane mode) in doors usually in < 30s. I had a few different iPhones, 6, 6S, 7 and XS where GPS wouldn't reliably work unless it had "network" (Internet) connectivity due to the reliance on WiFi-geolocation. Similar experience with Pixel 3's, with noticable improvements on Pixel 4s satellite GPS acquisition time.

For Android phone users, if you can use a slightly older version of microG (due to some recent unfortunate change microG made making the use of other backends more difficult), I found this backend to consistently be the best:

https://f-droid.org/en/packages/org.fitchfamily.android.gsml...

The above backend lets you use a database of CELL TOWER IDs to speed up location acquisition. As you might expect, cell phone towers rarely (ever?) move and even without a SIM card or celluar connectivity, a phone can scan for CELL IDs.

The other cool thing about this backend is it can create the database from the phone, or you can do it offline on a PC and push a sqlite.db file to phone. I suggest the PC route, the script is pretty simple to understand and you can filter out countries that might not be relevant to you.

And f** Skyhook.

The service has indeed been getting worse and worse over the last few years. In the tools I've got that use it the number of inaccurate hits I've gotten has been increasing. People who move and keep their same wifi gear seem to be the cause of it. Then it happened to me when I moved, and I tried to find a way to update MLS and couldn't, so my Linux laptops can no longer be set to automatic time zone mode, or they revert back to my old time zone whenever I'm at home...

I very much hope they release the information about which patents are a problem so that future attempts at a service like it can hopefully avoid that problem, but considering the state it's been in I'm not terribly upset that it'll be shutting down.

I helped stand up MLS and worked on the Android "stumbler" submission app. The original motivation for MLS was to provide a free location service for carriers that would potentially ship Firefox OS devices but not want to pay for Google's or Qualcomm's location services.

We always wished we could release the Wi-Fi location data, but there were privacy and safety concerns. Google was sued in Germany for recording Wi-Fi access points' locations and some data packets. And we were considering publishing similar location data, which would be an even bigger liability. The Google lawsuit lead to a lame opt-out system: to opt out of Google's Wi-Fi mapping, you're supposed to append "_nomap" to your SSID. To opt out of Microsoft's Wi-Fi mapping, you're supposed to append "_optout" to your SSID. I'm not sure how you're supposed to do both. MLS honored both "_nomap" and "_outopt" anywhere in the SSID string, filtering out those access points from submissions and lookup requests on both Mozilla's clients and server side.

A potential safety concern for releasing the MLS location data was the "stalker scenario": if you knew someone's access point MAC address and they moved, you might be able to find their new location by looking up their MAC address in the location database. This scenario was less of concern for lookup requests to the MLS server server because lookups include a list of MAC addresses that the client sees. The server returns an average of those neighboring MAC addresses' locations, but shouldn't return the location of an individual MAC address. (I don't know if MLS currently implements this restriction.)

Another protection (not implemented, AFAIK) could be to require lookups to include the SSID that matches a known MAC address and SSID pair. This would allow an access point's owner to change their SSID so lookups using the old SSID don't return the new location.

I thought we might be able to release the location database leveraging that restriction of requiring multiple MAC addresses. Instead of releasing a database mapping raw MAC addresses to locations, the database would map hashes of MAC1 + SSID1 + MAC2 + SSID2 to locations. Offline database lookups would need to know the MAC addresses and current SSIDs of two access points that had previously been seen together. I'm not a cryptographer, so there's probably some hole in this idea. :) It would also significantly increase the size of the database.

Requiring lookups to include multiple MAC addresses and matching SSIDs could also reduce the impact of poisoned location submissions because lookups (online or offline) would only see poisoned data if they included multiple poisoned MAC addresses and valid matching SSIDs pairs that can previously been submitted as neighbors. Poisoned data in the database doesn't affect clients that don't fetch it. :)

Another way to reduce the impact of poisoned location submissions could be to filter out submitting clients' new access point locations outside the submitting client's GeoIP region.

A neat trick from lookups including multiple access points is that the service can learn about new access points and their locations. If the service has seen MAC1 and MAC2 before and a client's lookup says they see MAC1, MAC2, and MAC3, the service can return the location average of MAC1 and MAC2 and tentatively record that new MAC3 exists at that average location and is a neighbor of MAC1 and MAC2.

we all know that feature only existed because it was the bundle of things google feared getting in trouble for.

mozilla was google henchman for over a decade. and nobody here will even grasp the size of the impact.

Anyone know where on the spectrum of "Fair enough. That's clever" to "Oh come on! FFS..." these patents fall?

Pretty sure Apple use Skyhook - or at least they used to for geolocation

Will that break Mozilla UnifiedNip Backend on Android?

Crap. This was so great with microG :(

Fuck. I just last year integrated this in a project of mine. Thinking: "Yeah, Google fucked me over here before when I used their, but it's Mozilla, it will be fine."

It is not okay to stop providing a service like this. Not if you are Mozilla, with that mission and money, not something that is so deeply entrenched. Though, reading it more calmly, I can see how them being hit by a patent troll can make their investment in this project untenable.

There is a comment about the Graphene Foundation maybe providing an alternative. That would be great - but having https://www.youtube.com/watch?v=4To-F6W1NT0 in mind, with that maintainer still active the project and foundation is a complete no-go. The organic maps comment is the one to follow instead.

Who the F is Skyhook) Holdings? :-\