Mozilla Location Service is retiring #2237
Comments
|
We had also AppleWifiNlpBackend, could you please merge it in microG? |
|
Interesting... is there a natural successor to it? |
|
Apple does not allow us to access their location service. Also, in contrast to most Google APIs we're using, usage is not strictly required for interoperability, so we don't have a legal basis for using their API in most jurisdictions. Unfortunately there is no natural successor I'm aware of. However there are also other open source projects (e.g. geoclue, the location service of Linux desktop) affected, so I'm hoping for some coordinated effort to bring a similar open source service to life. |
|
Can we just continue to run MLS in some jurisdiction that isn't concerned about patents? |
|
This would sort of kill microG for me, can we just use Apple's NLP? It was always more accurate anyway? |
|
As I mentioned in the /e/ OS Community I hope something better than MLS is used because ever since microG went to 0.3.0 every app but maps (Magic Earth) is not accurate at all and is off by 50-100 miles. I agree with using Apple's NLP. Unless a good accurate open source NLP is found. |
|
Even if we have to put Apple's NLP behind a radio button with a big disclaimer "Apple doesn't want you to do this, you're on your own"
…-------- Original Message --------
On 14 Mar 2024, 12:53 pm, ToughDBlue wrote:
As I mentioned in the /e/ OS Community I hope something better than MLS is used because ever since microG went to 0.3.0 every app but maps (Magic Earth) is not accurate at all and is off by 50-100 miles. I agree with using Apple's NLP. Unless a good accurate open source NLP is found.
—
Reply to this email directly, [view it on GitHub](#2237 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AB4ZXESVFVT54IBEXNC7QTDYYGMUHAVCNFSM6AAAAABEVCZHJKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXGM4TCNJTGQ).
You are receiving this because you commented.Message ID: ***@***.***>
|
It is all about the data. The more users contribute data to the service, the more precise the results become. |
I understand but when I had microG 0.2.27 it all worked great. How about going back to that NLP method? |
|
As I wrote above:
As a last resort option we could of course have that included and put a big warning that using it is a breach in ToS and Apple can sue your for financial compensation if you used that feature when trying to enable it, but if we can figure out somehting else I would definitely prefer that. If you have problems with location in current versions of microG I suggest to enable local location learning in settings and then use an app that requests both GPS and network based location. As soon as you get a GPS fix, it would then remember the correct location of nearby wifi networks and use it instead of MLS, so MLS' data quality doesn't matter anymore. |
Understandable, don't want to breach any TOS. Didn't know that. I'd rather something else be figured out as well. |
|
SatStat would do the trick. Also apps that use Google Maps API of microG often do request both locations through microG's API.
|
That works! Although my weather app says "Current Location" and not the actual city and state. The map in the weather is correct but again just says "Current Location" and not city and state. I have Nominatim enabled. Is there a way to reset Nominatim? |
|
I feel that the loss of UnifiedNLP together with this makes for an unacceptable step back. @mar-v-in I know there were technical reasons behind dropping UnifiedNLP but consider that it was working fine or well enough not to notice the issues for many, including on newer versions of Android, and that there was a small but relatively healthy "ecosystem" of backends and not just Apple, for instance I was an avid user of offline backends, and the GSM Location backend wasn't limited to "learning" but could download cell databases for local use. That was amazing and given I use mostly open source applications, I do lose a lot of the usefulness of microG when network location goes away. |
This was intended to be a feature in the new implementation as well (+ importing wifi and cell databases from file). With the learning code, there already is the logic to handle location data once it's in the database, we "just" lack the downloading/importing.
I think there might be a bias here. As you said, you've been mostly working with offline backends, which are faster in processing and less likely to run into timeouts or similar issues than online backends. I am convinced that the single process approach and centralized code will in the long run improve the results, but I do recognize that short term there are downsides as long as we lack some important features (with download/import of data being one of the major lacking features). |
|
The way that I see it, one of the primary purposes for which people use their smartphones is navigation. Personally, I'd say navigating is a more common use case for a smartphone than voice calls. If they don't have a fast, accurate location provider (ie if all they have is GPS), they can't navigate with their phone. The lock-on time is too high and it's not usable effectively indoors or in dense cities. If people can't navigate with their phone on MicroG, they won't use MicroG on their phone. Losing the ability to provide navigation - via whatever means - isn't just a feature regression, it's an existential threat to MicroG usage. It's important to do things the right way, but it's also important to make sure the project has a healthy enough base of users that it survives. |
|
Does anyone know how accurate OpenCellID and other downloadable databases actually are? Maybe if their TOS allows we could add a menu to download their data (maybe on a country by country basis). |
Downloading can be worked around for some (I e.g. do that on my Linux machine, using FastLacellsGenerator, which includes MLS and OpenCellID, and then push the database to all my devices – also saves me from downloading and generating it multiple times). Easiest way would probably be supporting that SQLite database directly. Not sure if the corresponding Backend could be used stand-alone to download and generate the database on-device for those who need it – but having it supported would be a good first step IMHO. Btw: I saw that TowerCollector now supports custom MLS URLs for upload, so there might be some "aggregators" for that, too. Not sure if they could be accessed the way microG currently accesses MLS, though. But an offline database is what some of us would definitely like to have anyway 😜 |
Yeah I've been using microG now for a while, however having to mess about whenever attempting to order an Uber is becoming too much. Sandboxed GMS is looking a lot better in terms of quality of life. I really don't want to have to deal with downloading local towers etc, I just want a decent enough NLP provider (Apple or Google) |
|
I vote for return UnifiedNLP. Or someone self-hosted database server. |
This doesn't really solve the privacy issues; this would push people to Google and Apple for Location Services, weakening the privacy/FOSS projects. That way you can create a public database but have it be relatively private; someone revealing their SSID won't have the same effect on their location privacy as it usually has; of course there's other public databases like Wigle that can make this an issue, but they seem very bad and outdated that accuracy is... eh. As you would only really know the mac and SSID if you know where the network is anyway; of course you wouldn't hash individual properties as that doesn't really give you many benefits The issue with such an approach rather than just publishing raw data, is that protocol ossification can be an issue. One solution to this is allow users to backup their contribution data and never delete it; so in the case of an upgrade to the network, one can re-upload new data. I think something like this can also have value in a closed ecosystem, which would have better privacy, as in a map it is still very possible to do some analysis of contributed points and dates and things; I personally think that a closed system that uses a private protocol is better than a completely open, or than closed but not private to the operator; with a closed system with a private protocol, we could potentially move the data in a private way to other projects; and data analysis is harder. TowerCollector is an interesting project, the maintainer is busy ATM and it's not his focus, so a fork to include WiFi, Bluetooth data, etc and be compatible with such a protocol would be needed. This would be a lot of work and research; so it's very likely something like this isn't actually developed; it's still interesting to debate this, especially what improvements can be made to location services overall :P
/e/foundation seems to be offering to do that (thankfully!) |
It would push me to using the local databases I was using before UnifiedNLP was retired. Can't speak for others of course. I also wonder: how many independent developers are probably going to want to be contributing to this repository, with PRs that must rightly not break things and be approved, as opposed to tinkering by writing their own module in their own repository, maybe using a simple existing module as a template, and publishing it there? I think that was a powerful aspect of the approach. |
|
FYI, my plan for the next version is to add:
|
Will that include the cell database as used by LocalGSM – and maybe auto-detect if a fresh copy has been placed in a defined location (as LocalGSM does)? Idea is to easily distribute an existing database to multiple devices for offline use (in addition to or instead of online checks like Ichnaea). |
And @rtsisyk offered the same on Mozilla's thread on this. There doesn't seem to be any shortage of people/organizations willing to do the hosting. |
|
FYI, all of us and a bunch of others are in communication with each other. We're aiming to ensure there is a single successor of MLS endorsed and supported by all the libre software projects involved, including microG |
|
Relatedly, one issue I've had myself and seen many reports of with the internal UNLP implementation in recent GmsCore versions beyond the Mozilla db staleness: Just enabling any of the Mozilla UNLP sources at all seems to "pollute" GPS results to the point that even with a good GPS lock geolocation is flaky or completely anomalous. You can see this with SatStat on the map page where the blue UNLP "circle" and/or pin is constantly turning grey ("stale data") and/or flickering on/off constantly even when the device is stationary. Seems to me that a good GPS lock should override UNLP inputs especially if the UNLP inputs are extremely unstable. I can open a separate issue on this if necessary. Just seems that this should be fixed along with enabling new MLS hosts, or else I think it will undermine the utility of those as well. |
|
The network location provider is (and should be) independent of GPS and having a GPS fix and the results from GPS are not considered in it. The blue circle in SatStat displays the network location provider, the red circle shows the GPS location. There is also the fused location, merged from both. This should use GPS once GPS is available and network location if not. The flickering of the blue location is probably caused by the update interval. MicroG only provides an update if updated data exists, which due to rate limiting might be less often then SatStat's requested interval. |
I sure would like to know more about this service. Their website is rather "fuzzy" about the background of it. Strange that they would exclude the largest internet user base in the world like that. But there are a couple of UNLP backends for the old architecture specifically targeting Chinese users: AMap and Baidu. (Available on IzzyOnDroid) Perhaps that functionality can be an option for people in those parts of the world in the future. |
|
I think the exclusion of China comes from their legislation. |
|
Did MLS have data for China? |
It works fine for me :) |
I wondered about that. However the 2 prior UNLP backends I mentioned above apparently use public domestic Chinese geolocation data sources. Which suggests to me that offering such services would not necessarily be in violation of the local rules, since I would think that those sources have already passed governmental scrutiny. |
|
UNLP backends are not supported anymore by microG in new versions so I guess it won't work. |
|
GrapeneOs recently released this article on positon, thoughts? |
It's written by someone who - for some reason - has an intense (and IMHO irrational) to /e/OS, the /e/ Foundation and, seemingly anyone who, like the microG project, have anything to do with /e/. IMHO, the article is FUD and can be pretty much discounted |
|
I'll just follow to Pete's comment that while the individual in question has a long history of slandering people and FOSS projects for little to no reason I am not exactly a fan of /e/'s track record when it comes to running secure and reliable public servers either. And there may be some legitimate privacy issues in their implementation which might be useful to look at but after making that criticism he criticizes them for caring about a different privacy matter that he thinks is not an issue. Personally I have pretty good faith that Marvin can tell the difference between a privacy-preserving and non-privacy-preserving service so if a particular service meets his expectations in that regard I will respect that. |
|
For all I know /e/OS is not involved with Positon at all. I'm in contact with both and both of them told me that they don't work with each other. /e/OS set up their own, independent network location service roughly at the same time that Positon started, so building two network location services at the same time would've been an insane waste of their limited resources. Regarding their privacy: They do have an easy-to-read policy on their website: https://positon.xyz/docs/privacy/. To me it sounds perfectly reasonable. With respect to future plans of Positon, the claims made don't match at all what I heard from them and as I know one of them personally, I have no reason to doubt what they tell me. |
At https://positon.xyz/docs/getting-started/ the URL is |
|
Will microG get integrated offering both providers (BeaconDB and Position) as options or just one of them? Is submission of data thought? |
|
@EchedelleLR note that data submission is already possible for BeaconDB using NeoStumbler or Tower Collector. Not sure whether it would fit within microG's scope to feature submission itself. |
Yes this is in the plans. It will be optional. I do not know for which service, or if multiple services will be supported yet. |
The first URL there is just the documentation. The second URL is the one you actually add to the microG settings. (In location settings, at the upper right tap the 3 dots) Tap "Configure service URL" and paste the URL in there. Just keep in mind that these services are in very early days and their database is not comprehensive yet. If it gives you bad results, just disable it and use GPS until it improves. You can also submit data to the beacondb service, eg for your neighborhood and other places you travel. Don't forget to enable the "Remember from GPS" feature - this will automatically create a local location db in places where you get a good GPS signal. |
If you look at my post you see that the URL mentioned at positon.xyz is different from the one that mar-v-in posted. My question war about that difference. |
I made a mistake and updated my post, sorry about that. |
The problem is battery. If microG is already getting data in local, could be better to use that having already microG. NeoStumbler cannot be put in automatic mode with microG devices, or at least I did not see possibility to enable because the API related to detect the movement seems not supported. A few hours in background takes 25% of battery. |
I don't know what is up with this platform but it seems to keep dropping my comment edits. What I was trying to say is that the original URL Marvin posted is correct. The one you posted that ends in "[API Key]" is just a generic template example. Without the full expanded key added (as in Marvin's posted URL), it won't work. |
Just by trying, either in microg or your browser, you would have had your answer already. It appear the API url has changed, with |
Instructions to submit data: |
This is a reminder (after it was also brought up in #2478) that, what I originally wrote remains correct, the URL you have to configure in microG to use Positon is And for those that want to use BeaconDB, the URL you need to configure is As mentioned in #2478, in the next version of microG I'll add the feature to automatically remove |
|
Can anything be done for huawei users? |
Huawei users with -hw build don't need to do anything as they never used Mozilla. microG does not act as network location provider on -hw build because Huawei devices with original OS already have their own network location provider. |
Ah so there is nothing us -hw users can do for issues like #2490 ? :( Will the non -hw version work on HarmonyOS ? |
|
That issue (and this issue for that matter) are not in any way relevant to you. You are not using the location provider feature from µG. |
|
Maybe add Mylnikov GEO and radiocells.org to the wifi location service and make microg automatically contribute to it should slowly solve this? The important thing is that the location service should be free, on both software and database, I don't know why grapheneos claim that a e/OS implementation would be proprietary, I doubt it, but if it's true we should avoid it. |
|
Today I noticed Positon is only supposed to be a temporary service until other alternatives exist. From their about page
While not an immediate issue, this would be something to keep in mind for the next ~year. |
and others
As was announced at mozilla/ichnaea#2065, Mozilla will retire MLS soon. The final deadline for third parties seems to be set to June 12.
The text was updated successfully, but these errors were encountered: