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?
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)?