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.
Nothing to add yet, just glad there’s a replacement effort going, and wish them the best. Hopefully it will be in a useful state soon.,
Why is this needed? There’s a reason for Mozilla cancelling their service.
Aren’t “privacy-friendly” and “location service” mutually exclusive?
Note that they didn’t say “private” or “privacy-respecting”.
Touché. My bad 😕
No worries. It’s not your fault that “privacy-friendly” has become such a weasel word.
beaconDB doesn’t log location requests, and it anonymizes location submissions, making it much more privacy-friendly than Google’s or Apple’s location services
Is “not as bad as Google” really a good goal for a project?
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.
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.
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)
