beaconDB is a drop-in replacement for MLS, which uses the same format request that’s used by Mozilla’s Ichnaea.

The source code is available on Codeberg: https://codeberg.org/beacondb/beacondb

You can contribute to the project by using an app like NeoStumbler (GitHub) or Tower Collector (GitHub) to submit location reports. NeoStumbler does Wi-Fi, Bluetooth and GSM, while Tower Collector can only do GSM cell towers. Both are FOSS and available on F-Droid.

It is also recommended by the GrapheneOS project: https://grapheneos.social/@GrapheneOS/112759509558471713

https://grapheneos.org/articles/positon-location-service

Just keep in mind that it’s still in relatively early development, which is why it really needs contributions.

    • No.

      It is hard to have both; but not impossible. You can still be privacy friendly without sacrificing necessary functionality.

      It will require that the “provider” of such a dataset constantly scrub, sanitize and remove data that would cause privacy hazards as quickly as reasonably possible however. That in and of itself is a technical challenge; though not impossible.

        • Using a location service obviously means that this service is going to know your location. beaconDB already minimizes the data that is collected about users. There’s not much else that can be done to make these kinds of services more private. The other options (Google and Apple) are much worse. The only alternative is not using a network location service at all, and simply relying on GNSS + PSDS and SUPL, like GrapheneOS does by default. I’d say beaconDB is the next best option, much better than proprietary alternatives and on par with the now defunct Mozilla Location Service.

          • I don’t really see the need for a location service in the first place. My phone can share my GPS coordinates with first responders in an emergency. For everything else, there’s simply typing in the location I want to know about.

            • there’s simply typing in the location I want to know about

              That’s not always possible. Imagine you’re visiting a city that you’ve never been to, or you go hiking in the mountains, or you go to another country that uses a different alphabet, so you can’t type in a street name or something like that. There are many more use cases like sharing your location with someone else (for example over Signal), tracking your workout (for example when cycling or going on a run) using an app like OpenTracks, or if you like saving geolocation to your photos.

                • GNSS does work, but it can take a pretty long time to acquire an initial location without PSDS and SUPL. It also uses much more battery. This can especially become an issue if you want to share your live location with somebody, or record your workout over a longer period of time. There are technologies like A-GNSS (Assisted GNSS) that use SUPL (Secure User Plane Location) and PSDS (Predicted Satelite Data Service), but these also require you to send your location to a third party (the default SUPL service on Android is supl.google.com, which is definitely much worse for your privacy than any NLP). GrapheneOS hosts a proxy at supl.grapheneos.org, which is much more private (see GrapheneOS’s privacy policy for all their network services: https://grapheneos.org/faq#privacy-policy). PSDS isn’t much better, as it’s usually provided by the manufacturer of your phone’s SoC (e.g. Qualcomm, Broadcom or Samsung). PSDS also sends a lot of data to the service, including SoC serial number and information on the phone including manufacturer, brand and model. GrapheneOS improves the privacy of PSDS (you can read more about all of this at https://grapheneos.org/faq#default-connections), but I still don’t see how this would be better than a privacy-friendly network location provider. beaconDB is still in a pretty early phase of development, but it’s likely going to be used by GrapheneOS when it becomes more stable. It’s also likely, that the GrapheneOS project will either host their own proxy for the public beaconDB service, or their own server using beaconDB data. That way, it would be even more private, and it would be covered under Graphene’s privacy-policy, which is essentially just the EFF’s privacy-friendly Do Not Track (DNT) policy.

  • Ideally there’s not a whole lot of data that needs to be kept.

    Legitimately all that needs to be stored is a few things:

    • Location (GPS)
    • SSIDs (Wifi APs only)
    • Cell ID & MCC/MNC (Cell Towers only)

    and things they MUST NOT STORE OR SHARE like:

    • IPs of contributors for longer than a few days
    • un-hashed BSSIDs (Wifi/BT)
    • MAC addresses (Wifi/BT)
    • IMEI/IMSIs (or other cellular identifiers derived from them)
    • APs that don’t exist in a fixed location (Think mobile hotspot SSIDs) for longer than a fixed amount of time.
    • BT devices
    • Non-unique SSIDs or IDs that may indicate no user config took place and manufacturer did not differentiate device ID. (Things like “SETUP” with no unique number (SSIDs like"SETUP-be3fd34d" would be valid) or “[ISP]@HOME” or “[ISP]Wifi” which provide no meaningful discriminators)