geo.provider.network.url - mozilla location service to be retired

[Thorin-Oakenpants]

https://github.com/mozilla/ichnaea/issues/2065

On June 12th, 2024 third party API keys will be removed and the service will only be available for Mozilla’s use cases

does this mean https://location.services.mozilla.com/v1/geolocate?key=%MOZILLA_API_KEY%" will no longer work?

[Tiagoquix]

We're near the deadline (12 June 2024).

There's also an issue on Geoclue (used by GNOME and other apps): https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/186

Some possible ways to replace MLS (but I don't know how to configure them properly, and I don't know if they can really be used in the same way as MLS):

• https://codeberg.org/tpikonen/ols
• https://wigle.net/
• https://opencellid.org/

For now, I think we should make the pref. inactive (add for prefsCleaner) so we can fallback to the default value, which uses Google Location Services. In this case, it's better to have a privacy-concerning service rather than broken functionality.

[Thorin-Oakenpants]

will only be available for Mozilla’s use cases

this is what confuses me a little. Is Firefox (as a point of difference to other apps/OSes) treated the same, and "use cases" means internal moz stuff.

I do not want broken functionality at all, as getting location is gated - so yeah, let's just make the pref inactive and eventually remove it, and not do anything more

[Thorin-Oakenpants]

unfortunately we're going to have an overlap until this lands in release, unless for some reason I do a v127

[Tiagoquix]

"Mozilla’s use cases" probably means only their staff will have access (i.e. no public access).

unfortunately we're going to have an overlap until this lands in release, unless for some reason I do a v127

Considering 0202, is geo.provider.network.url used for scenarios such as when asked for location permission?

If yes, then I see a v127 as plausible. We just have to wait for Mozilla to post the release notes: https://www.mozilla.org/en-US/firefox/127.0/releasenotes/ (currently: We’re still preparing the notes for this release, and will post them here when they are ready. Please check back later.).

I also see v126-2 as plausible, but I think v127 fits better. Let's see if v127 has any meaningful change notes for arkenfox. It having or not, v127 should still be released for arkenfox IMO to avoid broken geolocation functionality.

[Thorin-Oakenpants]

i don't think release notes will even bother to mention it, it's about:config only and not front facing. Also, release notes are very boring and we rely on diffs :)

So it really depends on how fast earthlng provides diffs and how fast I process them, and if anything needs adding in a hurry. Not keen on a v127 at all, but unfortunately I may have to - I have my months messed up, I keep thinking we're a month behind (probably because this years tor meetup was a month late, and it's still so warm here, but that might be the apocalypse)

I even had a subscription reminder a week ago to renew before 2nd June to keep my prepaid mobile number, and made a note to do it in the next few weeks, thinking it was a month's notice. Fuck me, lost my mobile number (but was able to get it back after it was cancelled as thank fuck there was a grace period before it is released to re-use, despite what they say on their website).

So that's on me, I should have done this in the last release

[Thorin-Oakenpants]

^ remind if nothing lands before Jun 12th

[Tiagoquix]

I believe we can postpone the v127 release until 11 June to provide more room for both you and earthlng. Let's see. I'll try to keep this issue in my head too.

[Thorin-Oakenpants]

well, June 11 is the release date for 127, so we're going to miss it regardless. The question is by how much, and do we really care if 128 comes out 4 or 5 weeks later? I guess it depends on what is in 127, which I suspect is nothing

edit: might as well reopen: I treat open issues as my ToDo list/reminders