Mozilla will be retiring the Mozilla Location Service
github.com
github.com
Skyhook basically owns triangulation of rf. It's absurd.
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.
If you don't see [1] then the site hasn't used the browser's location API.
[1] https://assets-prod.sumo.prod.webservices.mozgcp.net/media/u...
Did everyone forget there's a standard for this? e.g. my browser sent a "Accept-Language en-US,en;q=0.5" header when it loaded this page.
Some services, Google for example, ignore this simple fact and as a consequence force major inferior experience and usability. Many people waste considerable amount of time to fix the issues caused by that, with varying degree of success. The solutions usually have limited lifetime, due to changes in the services. So much needless pain.
iPads with mobile chips definitely do this, even prior to the user setting up their own service.
- red shift at night: if you move around countries, you don't want to reconfigure or use IP location. Having location from WiFi allows this.
- Weather application without picking a city or using GPS
- Night/Day wallpapers
MLS is also used by microG, also on phones.
also, it will set the wrong light when using a vpn.
even your extremely obscure use case cames sort trying to justify this nonsense.
Then to reply to your points. I don't use a VPN, but I regularly travel between south-western Europe and north-eastern Europe. The timezone is CET everywhere, but the actual solar time differs by about 2 hours. It may be a niche case for you, but can't I enjoy that it just works (for now)?
(Reasonable people may also disagree that traveling with your laptop with night colors is an "extremely obscure use case". It's a builtin feature on KDE. The night time also depends on the latitude which is not something captured by the timezone)
Also:
> In 2016, Skyhook introduced a range of innovative [sic] products tailored for the advertising technology sector: Retailer Personas, Power Personas, and On-Demand Personas. Leveraging Skyhook's vast processing capabilities handling billions of location data points, these solutions empower marketers to finely tune consumer targeting by analyzing past locations, enabling personalized mobile marketing campaigns.
Lovely.
I know that they sued Google over their Android NLP implementation and Google lost on almost all of the enumerated complaints, Apple started using Skyhook beginning with early versions of iOS, and Microsoft apparently also uses them.
What they have seemingly done with the assistance of an absurd number of patents that they apparently keep getting granted by the USPTO (which is known for issuing boatloads of junk patents), is take a fairly obvious tactic which amounts to one of the earliest examples of crowdsourcing - the WiFi "wardriving" practice - and find ways to patent-encumber that technique that they did not invent until they have engineered what appears to be a complete monopoly on it.
I'm also curious how the legal landscape of that business may have changed after the Qualcomm acquisition. IIRC at one point in time Qualcomm was licensing Skyhook data.
The plugin is open source though
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?
Additionally I'd assume they're quite hard to automatically update: The crowdsourced updates these databases depend on only work when at least one device has both a GPS signal and can see a cell or Wi-Fi base station, which is obviously quite hard underground.
I've experience this when a company I worked for switched offices. As soon as I got into range of the WiFi access points, my phone got confused. I'm pretty sure it was the WiFi access points + the IP address of the work WiFi's IP address.
It takes a while for location services to heal themselves. I run a VPN server at home, so ever since I took my phone and tablet to Amsterdam for a day, Google associated my IP address with that city, probably because my phone and tablet got so many data points there. I've seen it happen before, but that'll switch back eventually too.
Really? What is it called and can it be disabled? That kind of data collection seems like a gross violation of user privacy, and should be illegal.
[1] https://support.google.com/android/answer/3467281#scanning
Especially considering Qualcomm's relationship with many device makers and the OS platforms.
>> 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...
Looks like it depends on a GeoIP database.
https://dev.maxmind.com/geoip/geolite2-free-geolocation-data
They are the comany that infamously set the default US location to a farm in Kansas, causing all sorts of trouble for the people who live there. From the file name it sounds like classify-client is by default only trying to identify the country you are in.
I'm not seeing a browser.search.geoip.url setting, however I have geo.enabled set to false and various other setting that might cause that to not be present.
So they did choose a location - the lake, in response to the center being a bad location.
Is that the latest rename of `geo.provider.network.url`? And if so, have they changed the json format again too? I set that manually on my desktop because Mozilla's regularly put me far away (and in a different legal jurisdiction).
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.
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.
Up until a few days ago when the submission service was turned off on MLS side, it was just a matter of setting `submit-data=true` in geoclue.conf and going for a walk.
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.
mozilla was google henchman for over a decade. and nobody here will even grasp the size of the impact.
Skyhook might still be running the actual database and augmenting it with their own manual scans, though, but I strongly suspect that any Apple device with GPS is contributing its location data back to it.
Given the ubiquity of Apple devices, I wouldn't even be surprised if Skyhook paid Apple at this point.
But it's academic at this point. The MLS data had been going stale for 2-3 years now, I stopped using it ~2 years ago because of how inaccurate it had become.
If you're using microG GMSCore prior to 0.2.28.xxxx, you can use various other UNLP backends that can still give good results.
But for 0.3.0.xxxx and newer, it relies solely on the MLS db as well as some more obscure methods that don't help most people. Many in the microG community are hoping that gets greatly improved going forward.
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.
I, for one, had assumed that this service had been retired ages ago.
er, isn't it entirely for physical location based on wifi and mobile network towers?
Do you understand what you just said? Raw GPS is universally unusable, requiring up to half an hour of waving your phone under clear sky, hoping it a) will actually work; b) will not loose signal; c) will not drain the battery before you reach your destination.
The only way to get reasonable estimation of location? Location services. Guess who are the only providers? About 5 or something companies, all with expensive licenses and weird terms of use.
And here comes Mozilla, providing this same expensive exclusive service for free as a convenient API. Just send some WiFi SSIDs and signal strength, cell towers, and Bluetooth devices, and without even having to turn on the actual GPS, you get a faster, more accurate estimate of geolocation, down to a few meters.
This service is vital to mobile Linux or even deGoogled Android or non-Chrome browsers. In its time Canonical had to plead with Here maps for years to give their devices proper GPS. To say a project unique in its entire domain on which hinges the existence of entire ecosystems is less important than a yet VPN or email alias service seems downright silly.
Besides, it's not like Mozilla did it on their own volition. A patent troll had come to destroy their competitor on shaky legal footing, knowing they won't fight back...
Sigh. The increasing amount of unsubstantiated FUD finding its way on to HN recently is depressing.
Two glaringly obvious points to make at your nonsense:
1. What you describe is ancient history. It applied to old previous-generation devices with single-frequency chipsets (L1 GPS signals). However, effectively 100% of devices released within the last 3–5 years (and more in the case of certain manufacturers !) (a) have L1,L2,L5 GPS chipsets and (b) have multi-frequency GPS chipsets whch work not only with the "original" GPS but also Galileo, QZSS and others.
2. Even if we accept your argument, which we should not, then the rapid adoption of Apple's FindMy network (and the equivalent for Google) surely cannot have escaped your attention ? These serve to increase accuracy.
The reality is there is fast becoming no need for a third-party service such as the one Mozilla provided, because there is now first-class support for sufficiently robust high-accuracy positioning.
It's quite impressive, though, at how the hardware has improved. For a complete cold start one of the challenging issues is to actually find a single satellite to listen to. For GPS there's 32 different spreading codes and each transmitted signal is affected by Doppler shift depending on its position and velocity relative to where you are on the Earth. You basically have to iterate through (spreading code, Doppler shift) pairs and run a correlator to see if there's a signal present. Contemporary hardware has a ton of correlators that can run in parallel which can significantly improve the TTFF (time to first fix). As soon as you find one SV and start to get a bit of almanac data you can quickly eliminate (spreading, Doppler) options from the problem space by dropping SVs that you know are not going to be visible.
Dismissal of Mozilla being forced to bring down an essential service like this because the concerned post has some FUD in it, and that proprietary alternatives exist so what's the worry, is frankly disgusting. Especially when it's done via the blatantly immortal (but technically legal!) abuse of the legal system like this.
Not everyone wants to use the newest hardware.
Is that watch de-googled, running only with FOSS software, without a proprietary location service? How it the AGPS system mentioned in https://news.ycombinator.com/item?id=39725522 working, who provides the data? Was it stale?
If you can't answer that or if it's backed by (recently acquired) proprietary data, then you just do not know how GPS behaves in the scenario we are talking about.
Do you mean Apple's and Google's Wi-Fi positioning databases? These are different from Find My: Find My is crowdsourced positioning of (themselves usually unconnected) trackers; the positioning databases are (at least partially) crowdsourced Wi-Fi (and maybe Bluetooth) signal to location mappings.
> released within the last 3–5 years
So, pretty much only the very fresh devices then.
> have L1,L2,L5 GPS chipsets
That's not going to reduce cold TTFF to seconds without online assistance (which, by the way, is not what MLS is about).
> work not only with the "original" GPS but also Galileo, QZSS and others
Same as above. None of the constellations or assistance data help when you can't see the sky.
> then the rapid adoption of Apple's FindMy network (and the equivalent for Google) surely cannot have escaped your attention
How is it relevant and how can it be used by anyone who isn't Apple or Google?
> The reality is there is fast becoming no need for a third-party service such as the one Mozilla provided
The reality is that I'm not aware of any currently existing alternatives to MLS that could be used by Geoclue or microG, which provide non-GNSS location on many phones out there, which is essential to provide anything resembling a good user experience when it comes to location. The opposite of what you said is true - there's a rapidly growing need for this kind of service as more FLOSS starts to be used on mobile phones.
It is relevant because most people on the planet are not like you.
Most people on the planet use Apple, Google or indeed both.
Meanwhile, services such as the one Mozilla used to offer cost time and money to maintain. There's servers to maintain, software to maintain, CDN bills to pay.
If your user base is effectively a bunch of die-hard anti-Apple, anti-Google people, then its not worth the time or effort.
We are afterall, talking about location services here, not e.g. email where sure there's a market for non-Apple, non-Google.
For location services in 2024 there is little reason for people to not use what their device comes with, frankly.
You’re right that it can use more power, but it’s really not that bad with modern hardware.
You may not need Google for a GPS lock, but you certainly can't get a good fix without an external party. I've unwittingly tried this, when I saw a weird HTTP URL on my network being polled in the background; I blocked it in my Pihole and found out not much later that my phone's GPS started taking longer and longer to get a fix. Not "waving your phone 30 minutes at a clear sky" long, but definitely to the point where using Google Maps with cell/WiFi scanning disabled become very annoying.
What you're seeing is the effect of AGPS and the interaction with the phone's aggressive power management. https://en.m.wikipedia.org/wiki/Assisted_GNSS
It's not really a limitation of GPS, it's about using the external service to let you minimize the time your GPS receiver is active. You can get a great fix without AGPS, but you can't both keep the GPS off 99.9% of the time _and_ get a fast, great position fix.
Yes, after waiting minutes with good line of sight for almanac and ephemerides to download from the satellites. Anything that gets a fix faster is already "assisted", usually either by fresh data downloaded online or not-yet-fully-out-of-date data stored locally.
> but you certainly can't get a good fix without an external party.
is not true. You can get a great fix without a third party. You just have to be more patient for your TTFF.
* Unless you want RTK-level accuracy, in which case you're back to needing a third party.
From the user perspective, it's not going to be a good experience if you rely on cold GNSS only on a mobile device (unless the user is already well aware of what to expect and how to behave).
On the map page, the red "pin" and "circle" represent data originating from GPS. Blue color is data originating from Network Location provider(s). And you may also see "Fused Location", this is used by 3rd-parties like microG as one way to provide network location data to the OS.
https://f-droid.org/en/packages/com.vonglasow.michael.satsta...
You could test this by disabling WiFi, downloading AGPS from mobile, and then driving to place without service or putting in airplane mode. GPS fix will be fast cause ephemeris is good for days and corrections are small.
Hmm, more likely to end up as another C-level bonus/salary bump.
You aren't saying it, but it is implied or can easily misread as such. But Google is not directly funding Mozilla.
Mozilla gets its funds from many places, and one of them is Google; paying for being the default search engine. It's by far the largest amount. But not the only, nor a direct funding.
Being paid directly for a service by a company (Google paying for the privilege of being the default) is to be directly funded by that company. You're right that it's not the only source of revenue, but it's absolutely a direct source of funding.
They owe you a box of crackers. Once you've departed with it, they're no longer beholden to you.
Mitchell got Google to pay nearly double what Yahoo was willing to pay and has gotten Google to pay more each year for a dwindling user base.
If someone was going to Walmart and paying millions for a box of crackers, you’d be right in assuming the transaction wasn’t about the crackers.
That's still "just" a B2B relation and not "that one company is funding is".
Now, I'm not arguing about how good this situation is (it's bad, for a startup it's actually worse) just that it's not "funding".
Without Google funding, Mozilla wouldn't be able to maintain its operations. That is more than enough to treat the "Mozilla is funded by Google" statement as objectively true.
It's a bit of an odd market, since there aren't that many buyers or sellers, and since Firefox users are about the least valuable user segment. But that should already be reflected in the money Firefox is making from Google. And just back of the envelope it doesn't look like Google is overpaying Firefox compared to other browsers where they buy being the default search engine. We know from the recent lawsuit that Google paid Apple $26B in 2021. We also know from Mozilla's financials that the Firefox deal pays only about $400M/year.
Microsoft should definitely be interested in this, based on the statements their execs made under oath about the value of economies of scale and of query/click streams just last year. DuckDuckGo is already more than happy to pay Apple for being a non-default search (i.e. they pay Apple, and rather that complain about it being unfair they tried to keep it secret). There's no reason why Firefox couldn't get in on that action too.
We can try to justify one way or another but that's just the current reality.
It means Google doesn't actually get to say how Mozilla runs Firefox. They have a contract for a service ("make us the default search for the next N years, and we'll pay you X% revenue share on those searches"), Mozilla fulfills their part of that contract, and that's it. Google can't, for example, demand that Firefox must support some web standard proposal as a condition of being paid. If they tried making such demands, Mozilla would just sell their service to somebody not making such unreasonable demands.
And the reason people keep parrotting this idea on HN is to imply that there is some kind of wrongdoing and malicious use of funding as leverage going on. But that idea only works if this isn't a normal commerical arrangement with multiple potential bidders.
Another way it matters is that the utterly moronic ideas people throw around for this being an antitrust figleaf. Paying for default search engine placement is just how that business works, and worked before Chrome even existed.
They don't need to demand that, but how would you explain that Mozilla (despite all their talk about privacy and safety in the Internet) never considered putting an ad-blocker in the default install?
The point is: Mozilla needs funding from any of the Big Tech more than any of the Big Tech need Mozilla. They have, for all intents and purposes, sold out to the highest bidder and it doesn't matter who it is.
They know exactly what their purpose is: to provide a figleaf that Google can point when facing allegations that they control the browser market.
If Google thought they didn't need this ploy, Mozilla would be snuffed out.
But best to watch the video, there are a plethora of sources.
Last time I wrote something like that here someone else from GrapheneOS accused me of being unfair, since he is out by now - now I see the old maintainer writing in the name of the foundation and that he still commits to the project.
What do you mean? At least to me knowledge, Daniel Micay has been the maintainer of GrapheneOS throughout (from day 1 until now).
He is definitely not "out by now." He said he would step down, but I am under the impression that gesture (and the original Twitter post) was retracted. He's still listed as a director with the Canadian Business Registry record on GrapheneOS Foundation:
https://ised-isde.canada.ca/cc/lgcy/fdrlCrpDtls.html?p=0&cor...
The GrapheneOS project, and its sub-projects, are a net positive. You can dislike any individual person or aspect of the project and still take from its success. "Don't throw the baby out with the bathwater."
That said, you and I might just have differing views on the project and its management. I feel the project itself should be assessed/characterized on its security-focused initiatives first and foremost.
I won't discuss more here as it gets OT. Your comment's conclusion paragraph is a good conclusion, with which I just completely disagree :)
To express my more complete opinion: I do not think that Micay’s responses are endangering the GrapheneOS project to the extent that users should be concerned about its security. I don't believe he has unrestricted access ("has root") or that his involvement poses any risk to GrapheneOS' users. Instead, I think his participation has been crucial to the technical achievements of this security-focused project. Micay appears to be technically adept. It's his signature to write in complete detail in response to a technical matters. His other signature, though, is marked by tension/escalation that derails the technical conversation. I wish he would moderate the less constructive aspects of his engagement style.
I think this GH conversation summary looks like this:
The community is in need. MLS is shutting down, and they're insisting on a timeline during which the community must coordinate. Micay is offering that the GrapheneOS project has a viable arrangement. (1) He discusses that GrapheneOS Foundation has already invested time on a plan and has already received funding and are willing to share their funding. (2) He also discusses consideration for the quality of data submissions that could benefit from other GrapheneOS projects. (3) He discusses that Mozilla might have legal hurdles in the way of simply handing off the existing data.
Someone objects to using data based on hardware attestation, and Micay addresses the concern with care, and mentions that third-party OSes (not GrapheneOS) could provide data; he directly names Google and Apple, which would significantly cover "all users." That same someone objects that attested data would compete with anonymity, and Micay replies with a strategy that accounts for privacy/anonymization with configurable levels (so as not to throw away unattested data, but still maintain privacy).
Then somebody tells him his grammar is bad a slings an XKCD comic at him in mockery. The grammar was correct, but I understood the way in which the somebody misinterpreted it as "its." The comic jab is silly because Mozilla is literally shutting down the service, due to patent (troll?) hazard, and Micay is offering a solution to work around the known problems such as that.
Finally, both Marvin Weisfeld and Micay have an exchange about technical details relating to implementation. I didn't find either response to be technically complete. Micay diverts the technical conversation and launches an accusation, and I felt it had no place in the discussion. Marvin ended the discussion right there, and I think that ended the opportunity for escalation.