- BeaconDB ist ein Online-Ortungsdienst, der Mozilla Location Services ersetzen soll und seine Abdeckung auf Basis von direkt von Nutzerinnen und Nutzern eingereichten WLAN- und Mobilfunkmastdaten aufbaut
- Die Datenerfassung erfolgt per Opt-in; eingereichte Daten werden aggregiert und für beaconDB-API-Clients bereitgestellt, zudem ist künftig die Veröffentlichung verschleierter Datendumps geplant
- Da es sich noch um einen experimentellen Dienst handelt, kann die WLAN-Abdeckung je nach Region unzureichend sein; bei Fehlschlägen wird auf Mobilfunkmast-Standorte aus dem letzten MLS-Datendump oder auf IP-basierte Schätzung zurückgegriffen
- Unter Android können Daten mit NeoStumbler, Tower Collector und Network Survey eingereicht werden; über microG, geoclue und Firefox-Einstellungen lässt sich der Dienst zur Ortung nutzen
- Entwickler können den mit MLS/Ichnaea API kompatiblen `-Endpunkt verwenden; zum Identifizieren des Clients muss ein User-Agent gesetzt werden
Grundsätze zur Erfassung von Standortdaten
- BeaconDB betreibt seine Standortdatenbank auf Basis einer Opt-in-Erfassung
- Öffentliche Daten werden zum Schutz von Sendern und Beitragenden verschleiert
- Zum Aktualisieren bestehender Daten sind Informationen nötig, die sich nur innerhalb der physischen Reichweite eines Beacons erfassen lassen, was die Missbrauchsresistenz erhöht
- Eingereichte Daten werden aggregiert und anschließend für beaconDB-API-Clients nutzbar gemacht
- Künftig sollen verschleierte Datendumps unter einer Public-Domain-Lizenz veröffentlicht werden
- Wie eingereichte Daten verarbeitet werden, ist im privacy notice beschrieben
Apps zum Beitragen von Abdeckung
-
NeoStumbler
- NeoStumbler ist eine Android-App, mit der sich neue Abdeckung einfach einreichen lässt
- Verfügbar über Accrescent, F-Droid, Google Play, GitHub
- Ab v1.5.1 wird der Endpunkt auf beaconDB gesetzt, wenn man in der Eingabeaufforderung „yes“ auswählt
- In älteren Versionen wird durch Auswahl von beaconDB unter Settings → Endpoint → Suggested services automatisch die korrekte Konfiguration angewendet
-
Tower Collector
- Tower Collector ist eine seit Langem genutzte App zum Sammeln von Mobilfunkmastdaten
- Download über F-Droid oder Google Play
- Aktuelle Versionen laden standardmäßig zu beaconDB hoch
-
Network Survey
- Network Survey ist ein Werkzeug für umfassende lokale Datenerfassung
- Verfügbar über F-Droid oder Google Play
- Auf dem Hauptbildschirm wird unter Upload to Database in den Upload Settings die Übermittlung an beaconDB aktiviert
Aktuelle Einschränkungen und Fallback-Verhalten
- BeaconDB ist noch experimentell, daher kann die Standortschätzung ungenau sein oder der Dienst instabil laufen
- Da die Datenbank vollständig neu aufgebaut wird, ist die Wahrscheinlichkeit hoch, dass es in der eigenen Region noch keine WLAN-Abdeckung gibt
- Wenn keine Standortschätzung per WLAN möglich ist, erfolgt ein Fallback auf ungefähre Mobilfunkmast-Standorte aus dem letzten MLS-Datendump
- Als letztes Mittel wird eine IP-basierte Schätzung verwendet
- Es dauert mindestens 5 Minuten, bis eingereichte Daten über die beaconDB-API verfügbar werden
- Datendumps werden derzeit noch nicht bereitgestellt; aktuell läuft die Arbeit an Datenverschleierung zum Schutz der Privatsphäre von Beitragenden und AP-Besitzern
So werden Clients konfiguriert
-
microG
- Wenn ein Android-ROM microG unterstützt, kann die neue Standort-Engine von microG so eingerichtet werden, dass beaconDB als Online-Ortungsdienst verwendet wird
- Diese Standort-Engine ist seit v0.3.6 stable
- In microG Settings → Location → More options → Select online location service beaconDB auswählen
- Sowohl für „Wi-Fi location“ als auch für „Mobile network location“ muss „Request from online service“ aktiviert werden
-
geoclue
[wifi]
enable=true
url=https://api.beacondb.net/v1/geolocate
submit-data=true
submission-url=https://api.beacondb.net/v2/geosubmit
submission-nick=geoclue
-
Firefox
- Firefox kann so eingerichtet werden, dass es beaconDB direkt abfragt oder unter Linux den Standort über geoclue bezieht
- Für die direkte Nutzung
geo.provider.network.url in about:config auf https://api.beacondb.net/v1/geolocate setzen
- Für die Nutzung von geoclue
geo.provider.use_geoclue aktivieren
API und Ressourcen für Entwickler
1 Kommentare
Hacker-News-Kommentare
Ich frage mich, wie ethisch erhobene Daten in der Praxis funktionieren sollen, wenn sie per Opt-in gesammelt werden.
Wenn mein Nachbar mein WiFi-Netzwerk scannt und bei BeaconDB hochlädt, habe ich dem doch nicht zugestimmt, oder? In der Datenschutzerklärung steht, man könne dem WiFi-Namen
_optoutanhängen, was eher nach Opt-out als nach Opt-in klingt.WiFi-Netzwerke senden ihre Existenz zehnmal pro Sekunde in alle Richtungen aus. Jeder in der Nähe kann das empfangen, daher ist es allgemein bekannt, dass man keine sensiblen Informationen in die Netzwerk-SSID packen sollte. In diesem Fall ist es also eher so, dass Opt-out möglich ist.
Jeder Datendump würde nur kryptografisch gehashte, nicht umkehrbare Daten oder aggregierte Daten enthalten.
Als ich früher nach etwas Ähnlichem für GrapheneOS gesucht habe, war es nicht möglich, einen benutzerdefinierten Ortungsdienst bereitzustellen.
Es wäre wirklich toll, wenn man das unter GrapheneOS nutzen könnte. Falls jemand eine Möglichkeit ohne microG kennt, würde ich mich freuen. Ich nutze sandboxed GMS.
Es scheint keine Open-Source-Mobile-App zu geben, mit der der Autor Daten direkt vom Gerät aus sammeln kann. Gerade wenn das Opt-in am erfassenden Gerät hängt, würde mich interessieren, woher die Daten stammen.
War das Kernproblem bei MLS nicht, dass Skyhook sie mit Patent-Trolling/Klagen überzogen hat? Ich frage mich, welche Patente betroffen waren und wie beaconDB dieses Problem umgeht.
Wenn man den Thread zur Einstellung von MLS[1] liest, scheinen mehrere bestehende Organisationen wie /e/ foundation und Graphene ebenfalls an einem Ersatzdienst interessiert zu sein. Ich frage mich, ob gerade mehrere Open-Source-Ortungsdienstanbieter konkurrieren oder ob dies derzeit das einzige öffentlich zugängliche Projekt ist.
Das Projekt selbst ist cool, aber auf GitHub[2] wirkt es wie ein Ein-Personen-Projekt mit wenig Beteiligung. Ich frage mich, ob Gespräche über eine Skalierung des Projekts und Zusammenarbeit mit anderen mit ähnlichen Zielen laufen. Mit Unterstützung aus der bestehenden Entwickler-Community könnte es auf das nächste Level kommen.
https://github.com/mozilla/ichnaea/issues/2065
https://github.com/beacondb/beacondb
Edit: Das eigentliche Projekt scheint auf Codeberg[3] zu liegen, und dort gibt es neben dem Hauptentwickler etwas mehr Beteiligung als auf GitHub.
Das Projekt war ursprünglich auf GitHub, ist aber inzwischen zu Codeberg umgezogen.
Ich frage mich, ob es einen Grund gibt, warum die API nicht die Positionen der Access Points zurückgibt, damit der Client die Position selbst berechnen kann.
Ich habe allerdings noch keinen Client gefunden, der so etwas bereits nutzt. Falls jemand so etwas entdeckt hat oder entwickelt, wäre ein Hinweis hilfreich.
Hoffentlich unterstützt GrapheneOS das bald. Aktuell sind nicht von Google stammende GPS-Anbieter praktisch hoffnungslos, wenn man nicht im Freien ist.
Wirklich ein großartiges Projekt. Es ist immer schön zu sehen, wenn lösungsorientierte Menschen die Lücke füllen, die MLS hinterlassen hat. Unabhängig davon ist auch das Design hervorragend.
Ich frage mich, wo man den letzten Datendump von MLS noch bekommen kann. Ich konnte ihn online nicht finden.
Ich arbeite an einem Projekt, das verbundene Mobilfunkmasten anhand von mcc, mnc, cid usw. findet. Derzeit beziehe ich Daten nur von opencellid und combain, und zusätzliche Daten wären sehr hilfreich.
Eine Zusammenarbeit mit geoclue2 wäre wünschenswert. Seit dem Ende von MLS hat geoclue2 die WiFi-basierte Positionsschätzung deaktiviert.
https://gitlab.freedesktop.org/geoclue/geoclue