@beacondb is an open, and privacy-friendly network location service (just like Mozilla's now defunct location service), recommended by @GrapheneOS: https://grapheneos.org/articles/positon-location-service

Help the project by contributing Wi-Fi, Bluetooth and GSM location data through NeoStumbler, a FOSS app available on @fdroidorg

Official website: https://beacondb.net/

Source code on @Codeberg: https://codeberg.org/beacondb/beacondb

NeoStumbler on #fdroid: https://f-droid.org/packages/xyz.malkki.neostumbler.fdroid/

#beacondb #opensource #foss #privacy #android

@Andromxda
Thanks for mentioning. I contributed multiple sessions to Mozilla at the time, with Tower Collector as the most recent app. I had noticed NeoStumbler and it looks cool. Does BeaconDB build on the collection of Mozilla or have to start over?
@beacondb @fdroidorg @Codeberg @GrapheneOS

@nicorikken Mozilla has published the cell tower data their users had collected, but they weren't able to publish any wifi data due to privacy concerns. Mozilla's cell tower dataset has been imported but it is not included in the statistics.

I'm using data submitted to BeaconDB to research ways to obfuscate this data such that it can't be used to identify or track people, and hope to publish it so that users aren't dependent on BeaconDB either.

@beacondb @nicorikken Is Mozilla's cell tower dataset actually in use? When I query beaconDB for an LTE cell I'm connected to right now (which is present in Mozilla's dump) I only get 404 responses.

@dos @nicorikken I'm able to query the first cell tower in MLS' data dump:

```
$ curl -X POST https://beacondb.net/v1/geolocate -H "content-type:application/json" -d '{"cellTowers":[{"radioType":"gsm","mobileCountryCode":202,"mobileNetworkCode":0,"locationAreaCode":25,"cellId":12852}]}'
{"location":{"lat":37.994987,"lng":23.800217},"accuracy":0.0}
```

Please let me know if this doesn't work for you.

@beacondb I'm trying with the first LTE cell from my operator in the dump and get 404:

$ zcat MLS-full-cell-export-final.csv.gz | grep LTE,260,3, | head -n 1
LTE,260,3,11,1306213,402,21.0048378,52.2180052,0,1,1,1670110185,1670110185,
$ curl -X POST https://beacondb.net/v1/geolocate -H "content-type:application/json" -d '{"cellTowers":[{"radioType":"lte","mobileCountryCode":260,"mobileNetworkCode":3,"locationAreaCode":11,"cellId":1306213}]}'

@dos For LTE cell towers, you'll want to include the physical cell ID, or unit code. In the ichnaea API, this is referred to as the PSC/primary scrambling code, as this is the WCDMA/UMTS equivalent.

$ curl -X POST https://beacondb.net/v1/geolocate -H "content-type:application/json" -d '{"cellTowers":[{"radioType":"lte","mobileCountryCode":260,"mobileNetworkCode":3,"locationAreaCode":11,"cellId":1306213,"psc":402}]}'
{"location":{"lat":52.218006,"lng":21.004837},"accuracy":0.0}

@beacondb Ah, Geoclue doesn't include that field, and ModemManager doesn't expose it in its location API (it does in cell info API though). It used to work with MLS this way and still works with Google. Could this be handled on beaconDB side?

Ultimately Geoclue could do a much better job here, but this makes the versions currently out there incompatible with beaconDB...

@dos microG also doesn't send the physical cell ID and I originally thought this was a bug on their side, but if geoclue isn't sending it either then it sounds like making it optional for compatibility is a good idea.

https://codeberg.org/beacondb/beacondb/issues/22