SUPL: Vermeidung/Minimierung der Datenübertragung an Google

Izzy · 31. März 2023 um 16:58

Kleine Ergänzung zum Micro-Blog Artikel Android: Bei jeder Standortermittlung erfährt Google eure Position inkl. IMSI-Nummer – insbesondere für diejenigen, die kein GrapheneOS verwenden:

auch CalyxOS bereinigt m.W. den übermittelten SUPL-Request
ShiftOS tut dies ebenfalls
LineageOS seit kurzem auch (außer „in case of emergency“, was ~~wahrscheinlich~~ die Standort-Übermittlung im Kontext von Notrufen meint (siehe Marvin’s Kommentar für Details); 3/2023; Danke an Kurt für den Hinweis!)
DivestOS entfernt die IMSI bereits seit 6/2019 – und erlaubt auch die einfache „Komplett-Abschaltung“ über Settings (Dank an Mario für den Hinweis!)
Nebenbei erklärt sich hier auch das „in case of emergency“, Zitat: „The carrier/SIM along with emergency calls can override this server.“ – gemeint sind also in der Tat Anrufe bei Notfall-Nummern.

In beiden Fällen sagt das aber noch nichts über den SUPL-Server selbst aus. Daher:

das genannte Magisk-Modul (A-GPS SUPL replacer) gibt es auch in meinem magisk Repo
ohne root kann man mit AdAway ReDirect z.B. auf den GrapheneOS SUPL umleiten:

supl.google.com-supl.grapheneos.org
oder
supl.google.com-146.59.144.170

Geht aber erst mit Smartphones wo SUPL von Broadcom im Userspace von gpsd gemacht wird. Ansonsten geht es auch personalDNSFilter (wurde mir gesagt), ist aber etwas schwieriger.

tulpenknicker · 31. März 2023 um 17:25

Bei einem Notfall wird aber weder etwas zu Google vermieden noch etwas minimiert. So habe ich zumindest die von dir verlinkte Info verstanden.

Zwecks der Vermeidung von Missverständnissen würde ich dir vorschlagen wollen es z.b. auf folgendes zu ändern.

LineageOS minimiert seit kurzem die Datenübertragung an Google (ausser in Notfällen, da nicht)

Izzy · 31. März 2023 um 18:04

OK, bleibt die Frage nach der Definition für „Notfall“. Ich gehe einmal davon aus, dass da Anrufe bei 110 etc. gemeint sind.

        final Boolean isEmergency = mNIHandler.getInEmergency();
        // Unless we are in an emergency, do not provide sensitive subscriber information
        // to SUPL servers.
        if (!isEmergency) {
            mGnssNative.setAgpsSetId(type, "");
            return;
        }

Da sich Gerrit in meinem Browser scheinbar nicht vernünftig navigieren lässt, kann ich schlecht nachschlagen. Wenn es jemand findet, bitte ergänzen – derweil setze ich oben mal ein „teilweise“ bzw. „Meistens“ rein.

HousEpti · 31. März 2023 um 18:07

In Mikes Blogpost heißt es:

Wenn ich die Domain supl.google.com global via DNS sperre, dann bin ich doch fein aus, oder?
Danke

Izzy · 31. März 2023 um 18:24

Jein. Kommt auf Dein Gerät an. Manche umgehen das komplett und erledigen SUPL via Baseband:

Broadcom SUPL will go through a VPN but Qualcomm SUPL is done by the baseband and always goes over the mobile network.

(Quelle)

Oh, und:

This doesn’t necessarily have an impact for all SUPL implementations, since the Snapdragon one is capable of retrieving this information itself due to being done in a baseband RTOS process.

(Quelle)

Ich meine Mike hatte zu Android, VPN & DNS-Leak auch schon etwas geschrieben (dass das OS auch gern eigenmächtig „selbst auflöst“), finde den Blog-Post aber irgendwie nicht – ah, hier vielleicht: Warnung: Android leakt beim Connectivity-Check Daten an VPN-Verbindungen vorbei.

Wenn da also irgendwo die IP „hart verdrahtet“ ist, wird es schwierig – dann ist ja keine DNS-Auflösung mehr nötig. Und ob selbst eine root-Firewall greift, wenn das Baseband selbst den Abruf handelt, bezweifle ich ein wenig. Vielleicht kann @kuketzblog dazu etwas sagen? Das geht ein wenig über meine Expertise hinaus

HousEpti · 31. März 2023 um 19:18

OK, zusätzliches Sperren via DNS schadet vermutlich aber auch nicht, oder?

Izzy · 31. März 2023 um 20:00

Einen Versuch ist es sicher wert. Wüsste jetzt nicht, was (außer SUPL selbst) es noch brauchen sollte – und selbst wenn, ob Du das dann wollen würdest

larma · 1. April 2023 um 12:42

Zur Vollständigkeit: Das Gerät ist dann „in emergency“, wenn:

Ein ausgehender Anruf an eine Notrufnummer aktiv ist (oder vor weniger als 5 Minuten beendet wurde).
oder, in den letzten 5 Minuten mindestens eine SMS an eine Notrufnummer geschickt wurde
oder, ein eingehender Anruf von einer Notrufnummer aktiv ist, nachdem ein ausgehender Anruf an eine Notrufnummer vor weniger als 5 Minuten beendet wurde.

Die Regeln sind also so gestaltet, dass der Zustand nicht von extern ausgelöst werden kann, aber trotzdem möglichst alle Notruffälle abgedeckt sind.

Während eines Notrufs wird zudem GPS auch dann aktiviert, wenn es eigentlich abgeschaltet ist und insbesondere bei Multi-SIM-Geräten wird gezielt die SUPL-Konfiguration der SIM-Karte genutzt, über die der Notruf erfolgt. Der Vermutung liegt daher nahe, dass Google in manchen Ländern während eines Notrufs die über SUPL ermittelten Standort-Daten an die Notrufzentralen weitergibt. Das funktioniert aber natürlich nur, wenn die entsprechende IMSI oder Telefonnummer übertragen wird.

Art · 2. April 2023 um 00:33

Soweit ich es heute herausbekommen habe, soll iOS wohl auch die Google Services nutzen, da Google SUPL patentiert hätte-> kann dies jemand bestätigen oder wiederlegen.
Meine Quelle ist ein YT Video von Rob Braxman und ich habe Nichts zum verifizieren gefunden.

dazu würde passen, dass supl.vodafone.com auf supl.google.com redirected

→ übermittelt iOS auch die IMSI?

die GOS Adresse ist nur ein Proxy!?
→ gibt es andere SUPL hosts als supl.google.com, die man nutzen kann?

In satstat kann ich das Herunterladen der AGPS Daten manuell auslösen.
→ Ich bekomme Daten für eine Zone (wie groß?), die ich für eine bestimmte Zeit nutzen kann (wie lang?), um den TTFF ( Time to first fix) zu verkürzen.
Das ist mehr als die Almanac Daten der Satelliten, aber die 403 Seiten der Protokollbeschreibung sind mir doch zuviel

alterknacker · 2. April 2023 um 13:06

Hab das mal mit meinem ungerooteten Samsung und mit meinen gerooteten OnePlus versucht.
Die Vorschläge den Apn-Eintrag zuändern gehen nicht, bei Vodafone kann ich garnichts bearbeiten und bei der Telekom ist es zwar möglich den Eintrag zu löschen, nach den Speichern wird die Änderung aber wieder zurück gesetzt.
Beim Oneplus habe ich jetzt einfach das Magiskmodul benutzt, in der Hoffnung das es funktioniert.
Mit Adaway muss ich mal ausprobieren.

Izzy · 2. April 2023 um 18:27

Siehe Link weiter oben zum entsprechenden PR bei GOS. Ja, es ist ein Proxy (aber eben nicht einfach nur ein CNAME wie bei Vodafone, oder ein einfacher ReDirect). Details findest Du dort.

Was die Notation in Deinem Quote betrifft: Die besagt nach meinem Verständnis, dass alle Anfragen, die irgend etwas auf Deinem Gerät an supl.google.com stellt, stattdessen an supl.grapheneos.org geschickt werden.

Zu Deiner Patentfrage kann ich nichts sagen. Tatsächlich existiert ein solches – aber was genau das impliziert, müsste jemand anderes formulieren. Eventuell müsste jeder, der einen solchen Server betreibt, sich das von Google lizensieren lassen – aber ein Patent schließt ja nicht automatisch aus, dass andere es nutzen können. Meines Wissens gab es in der Vergangenheit mehrere unabhängige SUPL server. Welche es gab, und welche davon noch in Betrieb sind, weiß ich allerdings nicht. Als Anhaltspunkt ein kurzes Zitat aus einer CISCO Dokumentation:

There are 2 type of SUPL servers; Google’s SUPL server or Carrier based SUPL server. The Cisco A-GPS feature uses the one from Google.

Was ja u.a. besagt, dass es außer Google’s SUPL Servern noch andere gibt bzw. geben kann. Eine schnelle Suche im Netz bezeugt zumindest, dass auch Nokia einmal einen solchen betrieben hat, ein weiterer wird bei Broadcom erwähnt.

weltyx · 3. April 2023 um 08:48

Darf ich mal kurz dazwischen fragen?
Soweit ich bisher die Beiträge und Linkverweise verstanden habe gibt es konkret
für einen Calyxuser insbesondere mit Fairphone 4 (Qualcomm-Snapdragon) keinen wirklichen Ausweg, um supl.google zu entkommen, richtig?
Und Adaway Redirect - wenn es denn helfen könnte - würde ja voraus setzen, dass die VPN-Verbindung nicht schon z.B. durch Netguard oder dgl. genutzt wird, oder?
Also derzeit keine Lösung z.B. für Nutzer von Fairphones - oder?

Izzy · 3. April 2023 um 19:10

Kann Netguard das nicht auch – zumindest wenn sie von F-Droid bezogen und die Pro-Funktionen freigeschaltet wurden, wie in NetGuard: Datenverkehr von Android-Apps filtern – Privatsphäre schützen beschrieben? Das kann vielleicht ein Netguard-User beantworten. Ich könnte mir vorstellen, dass das über eine (selbst erstellte) Filterlist möglich wäre, bei der man supl.google.com auf die IP-Adresse 146.59.144.170, also den SUPL von GrapheneOS, umleitet (siehe oben: supl.google.com-146.59.144.170).

Bit · 6. April 2023 um 14:42

13 Beiträge wurden in ein neues Thema verschoben: Repo beim Fox’s Magisk Module Manager hinzufügen

Waterdrop · 16. Mai 2023 um 19:30

HINWEISE:
@Izzy Ich würde gerne zu deiner Liste iodéOS beisteuern. Vielleicht kannst du das noch ergänzen (notfalls durch einen MOD)?

In der ersten Dokumentation von iodéOS steht drin, dass sie IMEI, IMSI und Telefonnummer nicht an den SUPL-Server senden. Die Dokumentation ist vom April 2022 und es ist anzunehmen, dass sie diesen patch aber schon länger haben:

LineageOS uses location reporting with Google’s secure user plane location (SUPL) server (supl.google.com)
for A-GPS. This helps in speeding up device positioning when using A-GPS, but each request to the server
includes the device’s International Mobile Equipment Identity (IMEI), International mobile subscriber identity
(IMSI) along with the phone number.
We use a patch to avoid leaking personal data to SUPL server.

Seitdem LOS einen ähnlichen patch hat, hat iodé diesen übernommen. D.h. dass jetzt auch bei iodé die Ausnahme „in case of emergency“ gilt.

Seit April 2023 kann der SUPL-Server auch deaktiviert werden.

FRAGEN:
Iodé redet immer davon, dass IMEI, IMSI und Telefonnummer nicht an den SUPL-Server gesendet werden. Bei Graphene ist es nur noch IMSI und Telefonnummer. In dem Datenmitschnitt (unter 4.5 (GPS-)Standort) von Mike bei CalyxOS taucht aber „nur“ die IMSI auf. Ist demnach die Erwähnung von IMEI und Telefonnummer nur überflüssige „Werbung“? Werden in Wirklichkeit ohne einen patch „lediglich“ der ungefähre Standort, die IMSI und IP gesendet?

Der vorgeschlagene Magisk SUPL replacer macht unterm Strich genau das Gleiche, was Mike damals in der LineageOS-Serie (unter Punkt 2.4) oder auch hier schon vorgeschlagen hatte. Auf diese Weise lässt sich der SUPL-Server entweder deaktivieren oder neuerdings der supl.grapheneos.org einstellen. Unter GrapheneOS selbst kann man dies ja jetzt als normaler Anwender sogar einfach in den Android-Einstellungen vornehmen. Ist die technische Umsetzung von Graphene ebenfalls genau die Gleiche?

Mike schlug beim Test von Calyx Folgendes zum Deaktivieren vor:

Ist das nicht die Möglichkeit, die z.B. gem. Graphene generell nicht zuverlässig funktioniert?:

add toggle to Settings ➔ Location for force disabling SUPL as a carrier-independent replacement for editing APN configuration since editing APN configuration is unintuitive, not fully respected on Tensor SoC devices and users with no carrier should be able to disable it without using airplane mode

Ich hatte zudem auf verschiedenen Seiten gelesen, dass der Netzbetreiber einen eingestellten Server überschreiben könne. Es gab aber nie weitere Hintergrundinfos dazu. So ist die Aussage auch bei DivestOS zu finden.

→ Der Netzbetreiber/die SIM-Karte sowie Notrufe können diesen Server überschreiben.

Kann das sein, dass damit lediglich die Lösung, in den Einstellungen den APN-Typ zu ändern (s.o.), gemeint ist? Und die Lösung sowohl mit dem Magisk SUPL replacer als auch die von Graphene funktionieren hingegen zuverlässig?

Bedeutet das, dass bei einem Handy mit Qualcomm eine Umleitung mit AdAway (VPN) oder personalDNSfilter (VPN) nicht möglich ist? Würde es mit einer App funktionieren, die kein VPN benötigt?

@larma schrieb auf Mastodon:

Das klingt zwar vielleicht gut, ist aber mMn. mehr Augenwischerei. Das einzige was auf diesem Weg verschleiert wird ist die IP-Adresse des Nutzers. Diese kann aber aus den transportierten Daten über die Funkzelle ohnehin geschätzt werden (z.B. über andere die zur selben Zeit in der selben Zelle aktiv sind). IP(v4)-Adressen sind im Mobilfunk einfach keine sensiblen Daten.
Ich hatte ja eigentlich gehofft, das jemand ankündigt einen alternativen open-source SUPL-Server zu bauen.

Darauf hat Graphene Bezug genommen:

The reason to mask the IP address is because the mobile IP address will remain the same as you move around and will end up providing multiple locations tied to a single IP address over time. Since SUPL connections are short lived, our proxy serves to separate each request so that the SUPL server only gets a location without an identifier. Our SUPL proxy could zero out IMSI and IP address but we disabled that client side for GrapheneOS which is superior.

Und hier:

IP address can be tied to other things. Broadcom SUPL will go through a VPN but Qualcomm SUPL is done by the baseband and always goes over the mobile network. Carrier likely has a persistent record of which IPv4 (likely shared) and IPv6 address (likely unique) belonged to each user a given time. I don’t think it’s fair to claim that there is no benefit from the proxy. IP address is not sensitive by itself when all it reveals is that the device uses an Android-based OS but IP address + location data becomes problematic.

Außerdem schreibt Mike:

Wird durch den SUPL-Server von Graphene die wahre IP nun versteckt oder nicht?

Wenn ja, welchen datenschutzmäßigen Vorteil hätte dann noch ein selbst gehosteter SUPL-Server (ohne Weiterleitung an Google)?

larma · 16. Mai 2023 um 20:25

Bzgl. APN-Einstellungen ändern: Der Netzanbieter kann auf dein Gerät eine neue APN-Konfiguration pushen und damit die Konfiguration überschreiben. Manche Netz-Provider machen das automatisch, wenn das erste mal deine IMEI+IMSI-Kombination sich mit ihrem Netz verbindet (du also das Smartphone zusammen mit der SIM-Karte zum ersten mal nutzt). Dahinter steckt auch keine böse Absicht, denn die APN-Konfiguration ist hauptsächlich dafür da, dass dein Smartphone sich korrekt mit dem Netz verbinden kann, es macht also völlig Sinn, dass dein Netz-Anbieter den für das eigene Netz gültigen APN-Eintrag verändern kann. Ich will nicht ausschließen, dass einige Geräte die SUPL-Konfiguration aus dem APN-Eintrag nicht korrekt anwenden, dass wäre dann aber unter Umständen in manchen Ländern ein Grund, dieses Gerät zu verbieten.

Ich würde diese Aussage erstmal grundsätzlich anzweifeln. Die Behauptung, Modem, Firmware, u.ä. würden irgendetwas am Betriebssystem vorbei machen, ist in der Regel nur durch Unkenntnis begründet (siehe zum Beispiel der NitroKey blog post von vor ein Paar Wochen). Wenn der SUPL client bei einigen Qualcomm-Geräten am VPN vorbeiläuft, dann könnte man das als Fehler im Betriebssystem verstehen und das sollte man sich dann entsprechend ansehen.

Bei Verwendung des SUPL-Servers von GrapheneOS wird deine „wahre“ IP an GrapheneOS übertragen, statt an Google und Google sieht stattdessen die IP von dem GrapheneOS-Server. Meine Aussage bezog sich darauf, dass IP(v4)-Adressen im Mobilfunk von so vielen Geräten geteilt werden (die üblicherweise dabei auch räumlich an einer ähnlichen Position sind), dass Google aus der IP-Adresse selbst sehr wenig Information gewinnen kann. Es würde mich stark wundern, wenn Google die IP-Adressen, die am SUPL-Server anfallen, mit anderen Datensätzen verknüpft, einfach weil auf >99.9% der Endgeräte dadurch kein Mehrwert zu erwarten ist (Endgeräte, auf denen Google Play Dienste installiert sind oder die Apps installiert haben oder Webseiten ansurfen die Firebase, Google Analytics oder Google Ads nutzen), aber die Chance besteht, die Qualität des Datensatzes zu verringern.

Für AGPS braucht man zwei Informationen: 1) Die ungefähre Position und Flugbahn der Satelliten des GPS-System 2) die ungefähre Position des Endgeräts. Das SUPL-Protokoll stellt beides bereit. Um die ungefähre eigene Position zu bestimmen, wird die ID der Funkzelle, mit der das Gerät verbunden ist an den Server übertragen und die Informationen über die Satelliten sind öffentlich abrufbar.
Der Vorteil einer freien SUPL-Server-Implementierung wäre nicht, dass man diese als Konkurrenz zu Google betreiben könnte, sondern, dass der Server auf dem Gerät selbst ausgeführt werden könnte. Dann könnte der Ortungs-Prozess mit vorhandenen Open-Data-Daten vollständig lokal ausgeführt werden, lediglich die Flugbahn-Daten der Satelliten müssten regelmäßig geupdated werden - und da diese keine privaten Informationen enthalten ist das etwas was datenschutzfreundlich und sogar peer-to-peer gelöst werden könnte.

Waterdrop · 17. Mai 2023 um 12:54

@larma vielen Dank für deine ausführlichen Antworten!

OK, das bedeutet, dass es nichts nützt, wenn man in den Einstellungen unter APN-Typ den Wert supl entfernt, um SUPL bzw. A-GPS zu deaktivieren.

Man kann aber stattdessen in der Datei /etc/system/gps.conf oder /vendor/etc/gps.conf den Eintrag SUPL_HOST=supl.google.com in SUPL_HOST=localhost ändern. Dies soll ebenfalls bewirken, dass SUPL bzw. A-GPS deaktiviert wird. Ist das wirklich zuverlässig so und hat dies Vorrang vor den APN-Einstellungen oder wird diese Datei ebenfalls vom Netzbetreiber überschrieben?

Diese Aussage (siehe obigen Link) hat Daniel Micay (Graphene) am 5. März getroffen. In der GrapheneOS-FAQ (3. + 4. Absatz) steht auch Einiges zum Thema APN und SUPL usw. Möglicherweise ist diese Quelle etwas aktueller. Hier ein gekürzter Ausschnitt aus dem 4. Absatz:

When you have both a cellular connection and Location enabled, control plane and/or user plane (SUPL) A-GNSS is used in addition to PSDS to greatly reduce the time needed for GNSS to obtain an initial location lock.
[…]
Control plane A-GNSS is provided by the cellular connection itself and therefore doesn’t have any real privacy implications while SUPL connects to a server often not provided by the carrier.
[…]
Pixels with a Qualcomm baseband use it to provide both cellular and GNSS including both control plane and user plane A-GNSS being implemented inside the baseband. For Qualcomm baseband devices, SUPL is only enabled if the APN configuration for the carrier includes supl as an APN type. Pixels with a Samsung baseband have a separate Broadcom GNSS chip without integration between them so SUPL is done by the OS with regular networking (can use Wi-Fi and VPN) and SUPL is used regardless of the carrier’s APN type configuration.
[…]

Niemand ist unfehlbar, aber für mich als Laien klingt das schon so, dass Graphene weiß wovon sie sprechen. Ich lasse mich aber gern eines besseren belehren. Graphene hat einen sehr professionellen Ruf, aber ehrlich gesagt, kann ich deren Aussagen nur trauen oder eben nicht. Das als Laie zu verifizieren ist (für mich) unmöglich.
Wie würdest du es jetzt nach Erhalt dieser Informationen einschätzen?
Und mal angenommen die Aussagen von Graphene stimmen, wie sähen dann die Antworten auf meine Fragen aus?:

Für mich ist das Thema sehr komplex. Entschuldige daher, dass ich nochmals nachfrage.
Ich verstehe das jetzt so, dass der Graphene-SUPL zwar tatsächlich die „wahre“ IP erfolgreich vor Google „versteckt“, dies aber keinen datenschutzmäßigen Mehrwert hat. Zum einen teilt man sich sowieso dieselbe IP mit vielen anderen in der Nähe befindlichen Geräten und daher kann und wird diese IP wahrscheinlich nicht von Google mit anderen Informationen verknüpft. Zum anderen könnte Google trotz der „Graphene-IP“ die „wahre“ IP erraten, weil die anderen in der Nähe befindlichen Geräte eben üblicherweise dieselbe IP haben.
Demnach schadet der Graphene-SUPL-Server nicht, aber einen echten datenschutzmäßigen Vorteil bringt er nicht. Wenn man also mit seiner verwendeten ROM keine Möglichkeit hat supl.grapheneos.org zu verwenden, hat dies keinen Nachteil.

Aber was ist mit Graphenes Argument, dass die IP des eigenen Gerätes immer gleich bleibt und somit diese IP im Laufe der Zeit natürlich an verschiedenen Standorten auftaucht? Dann wäre die IP doch eindeutig wieder erkennbar?
Und was ist mit diesem Argument (übersetzt von obigem Zitat) von ihnen?:

Der Netzbetreiber hat wahrscheinlich eine dauerhafte Aufzeichnung darüber, welche IPv4- (wahrscheinlich eine gemeinsame) und IPv6-Adresse (wahrscheinlich eine eindeutige) zu einem bestimmten Zeitpunkt zu jedem Nutzer gehörte.

Ich hätte jetzt gesagt, dass der Netzbetreiber seine Aufzeichnungen nicht mit Google teilt, oder? Aber wenn tatsächlich eine IPv6-Adresse (wahrscheinlich eine eindeutige) an mein Gerät vergeben wird, bin ich ebenfalls wieder eindeutig erkennbar?

Kann ich mir das vereinfacht und laienhaft gesagt, so vorstellen, dass auf dem Smartphone ein „Programm“ installiert ist, dass sich die Flugbahn der Satelliten selbst aus dem Internet holt und direkt auf dem eigenen Gerät mit den dort sowieso vorhandenen aktuellen Funkzellen-Angaben kombiniert? Somit verlassen keine Informationen das Gerät?

AlphaElwedritsch · 17. Mai 2023 um 13:19

Nur mit root oder ADB root

Waterdrop · 21. Mai 2023 um 00:19

Das ist klar.

Mir fällt gerade auf, dass es völlig egal ist, ob eine Weiterleitung funktioniert, wenn Qualcomm bzw. der Netzbetreiber nicht über die Benutzerebene (SUPL) sondern über die Steuerungsebene geht. Ein Teil der oben angegebenen Graphene-FAQ übersetzt:

A-GNSS auf der Steuerungsebene wird von der Mobilfunkverbindung selbst bereitgestellt und hat daher keine wirklichen Auswirkungen auf die Privatsphäre

Man kann alles 10x Mal lesen und versteht trotzdem noch nicht alles!

Zusammenfassung meiner Fragen und teils deren Antworten

Ich würde gern die „Gefahren“ des in der Custom-ROM-Serie genannten Datenlecks verstehen und welche Gegenmaßnahmen, was bringen. Mich würde freuen, wenn einer von euch @Izzy @larma @kuketzblog @jemand anderes, der etwas darüber weiß, zu dem einen oder anderen Punkt etwas sagen könnte. Dies würde sicherlich auch vielen anderen bei der Einschätzung dieses Themas helfen.

Zunächst mal die Fragen, die noch übrig geblieben sind:

Normalerweise wird die IMSI an Google gesendet. Die IMEI und Telefonnummer ebenfalls oder nicht?
Wenn man in der Datei /etc/system/gps.conf oder /vendor/etc/gps.conf den Eintrag SUPL_HOST=supl.google.com in SUPL_HOST=localhost ändert, um SUPL bzw. A-GPS zu deaktivieren, hat dies dann Vorrang vor den APN-Einstellungen und wird nicht vom Netzbetreiber überschrieben?
Entspricht die Lösung force disabling SUPL von Graphene dem Punkt 2?
Man kann mit einer VPN-basierten App wie AdAway oder personalDNSfilter eine Umleitung zu einem Proxy-Server machen. Wenn man jedoch eine App hat, die im OS (z.B. iodéOS) fest integriert ist und daher ohne VPN läuft, funktioniert dann trotzdem eine solche Umleitung?

Hier die bereits erfolgten Antworten und Feststellungen:

Es nützt nichts, wenn man in den APN-Einstellungen unter APN-Typ den Wert supl entfernt, um SUPL bzw. A-GPS zu deaktivieren, da der Netzbetreiber dies überschreibt.
Eine Umleitung zu einem Proxy-Server ist nur notwendig, wenn A-GNSS über die Benutzerebene (Google SUPL-Server) erfolgt. Wenn A-GNSS über die Steuerungsebene (durch den Netzbetreiber) erfolgt, ist keine Umleitung notwendig. (mehr dazu weiter unten)
Ein Proxy-Server wie von Graphene „versteckt“ die „wahre“ IP vor Google, indem bei Google nur die IP vom Proxy-Server ankommt.
Die optimale Lösung wäre, jedes Handy selbst als SUPL-Server zu verwenden. Das Handy könnte sich die (öffentlich verfügbare) Flugbahn der Satelliten direkt aus dem Internet holen und direkt lokal auf dem eigenen Gerät mit den dort sowieso vorhandenen aktuellen Funkzellen-Angaben kombinieren. Damit müssen erst gar nicht irgendwelche sensiblen Informationen das Gerät verlassen.

Hier im Weiteren mein Versuch, den Nutzen eines Proxy-Servers zu interpretieren:

Bezüglich der IP(v4)-Adresse gibt es offensichtlich verschiedene Annahmen. Entweder teilen sich in derselben Funkzelle viele Geräte dieselbe IP und bei jedem Wechsel der Funkzelle ändert sich die eigene IP. Oder das Gerät erhält dieselbe IP(v4)-Adresse wie viele andere Geräte, aber behält diese auch bei einem Funkzellenwechsel bei. Dann gibt es in derselben Funkzelle viele verschiedene IP-Adressen.

Wenn die Anfrage auf der Steuerungsebene erfolgt wird A-GNSS über die Mobilfunkverbindung von den Netzbetreibern selbst zur Verfügung gestellt. Auf diese Weise erhält Google keine Daten. Der Netzbetreiber selber hat sowieso immer meinen Standort, da sich das durch die SIM-Karte eindeutig identifizierbare Gerät sowieso laufend in die Funkzelle einbucht.

Wenn die Anfrage auf der Benutzerebene erfolgt wird A-GNSS von dem Google SUPL-Server zur Verfügung gestellt. Dies geschieht wahrscheinlich auch über die Mobilfunkverbindung aber über VPN. Wenn man eine eindeutige IP(v6)-Adresse erhalten sollte, kann Google die Standortdaten mit anderen Daten, die über diese IP generiert wurden, verknüpfen.

Wenn es jedoch eine IP(v4)-Adresse wäre, hätten viele Nutzer dieselbe (egal ob sie sich in derselben Funkzelle oder in verschiedenen befinden) und Google kann mein Bewegungsprofil nicht mit anderen Daten, die über diese IP generiert wurden, eindeutig verknüpfen. Schließlich könnten meine Daten und die der Anderen zu jedem der Bewegungsprofile gehören.

Falls es weitere Anwendungsfälle geben sollte, bei der sowohl die IP(v4)-Adresse als auch die IMSI verwendet werden, wären in dem Fall diese Daten miteinander verknüpfbar, weil die Anderen eine eindeutige IMSI hätten. Und meine Standortdaten die Einzigen ohne IMSI sind, meine anderen Daten mit IMSI gesendet würden und die einzigen sind, mit denen keine Standortdaten mit derselben IMSI zugeordnet werden können. Also müssen es die Standortdaten ohne IMSI sein. (Die meisten Leute haben ja nun mal kein Custom-ROM und senden somit immer ihre IMSI.) Falls man trotzdem das Glück hat, dass wenigstens ein zweites Gerät ebenfalls keine IMSI sendet, dann könnte Google die Daten nicht mehr eindeutig mit dem Standort verknüpfen.

Falls man eine eindeutige IP-Adresse erhalten sollte, ist die Verschleierung der IP (wie es Graphene macht) sinnvoll und wichtig.

Bei dem Szenario, wo auch andere Daten sowohl mit IMSI als auch IP-Adresse verknüpft wären, würde die Verschleierung ebenfalls helfen, sofern der Pool von denselben IP(v4)-Adressen sich in verschiedenen Funkzellen befinden würde. Dann kann Google nämlich nicht an Hand der anderen Geräte derselben Funkzelle die IP erraten, da die Geräte unterschiedliche IP-Adressen haben. Nur falls die IP(v4)-Adressen immer in derselben Funkzelle die Gleichen sind, kann Google an Hand der anderen Geräte die IP ermitteln. Das wäre damit der einzige spezielle Fall, bei dem das Verschleiern nicht helfen würde.

Unterm Strich macht ein Proxy-Server Sinn. Schon alleine deswegen falls man eine eindeutige IP(v6)-Adresse erhält. Und die werden sicherlich immer mehr eingesetzt werden.

Wäre schön, wenn jemand meine Angaben bestätigen oder korrigieren könnte.