Moin, unter https://discuss.grapheneos.org/d/30985-downloads-app-contacts-gstaticcom wird in einem Thread die Beobachtung diskutiert, dass Pixels mit GrapheneOS und RethinkDNS periodisch während des Ladevorgangs eine Verbindung zu gstatic.com herstellen und eine geringe Datenmenge transferieren. Die App, der das in RethinkDNS zugeordnet wird, ist eine der folgenden anscheinend gemeinsam ausgewerteten:
Die Verbindung ist unter den Standardverbindungen bei GrapheneOS nicht gelistet ( https://grapheneos.org/faq#default-connections ), und im Thread schiebt GrapheneOS es auf Rethink [edit: Mein Interpretation, sie schieben es tatsächlich nur nachvollziehbar auf eine unbekannte auslösende App und schlagen zur Isolation des Verhaltens vor, das System auch ohne RethinkDNS zu beobachten].
Mindestens eine Nutzerin hat die Verbindung jedoch auch mit deaktiviertem (aber nicht deinstalliertem) RethinkDNS beobachtet.
So, daher jetzt:
Gibt’s hier Leute, die beobachten können, ob ihre Telefone während des Ladevorgangs mit gstatic.com reden möchten, und die im Idealfall auch feststellen können, was dabei passiert? Vielleicht auch, ob es eine RethinkDNS- oder GrapheneOS- oder gar AOSP-Sache ist?
Die Analyse übersteigt leider meine bisherigen technischen Fähigkeiten.
Und ob das mit dem täglich genutzten Telefon so hübsch zu untersuchen ist, weiß ich auch nicht…
ja, ich kann diese Beobachtung bestätigen. Das passiert bei mir seit ca. 5 Tagen auf meinem Google Pixel 7a mit GrapheneOS V16 Buildnummer 2026061600 und wird von mir auch dokumentiert da ich mir diesen Vorgang nicht erklären kann. Der Zugriffsversuch geht von den Systemdateien MTP-Host etc. während dem Ladevorgang aus und benutzt dabei den Port 53. Bei mir allerdings erfolglos, da die Adresse gstatic.com aufgrund einer anderen hier bereits schon früher berichteten Situation komplett blockiert wird, wo gstatic.com unerklärlicherweise aktiv wurde.
Vor zwei Tagen hatte ich auch eine Meldung in der Benachrichtigungsleiste, daß der Downloadversuch einer unbekannten Datei fehlgeschlagen sei. Diese Meldung erschien zweimal und wenn ich auf diese tippte, wurde ich zum Hauptbildschirm von RethinkDNS weitergeleitet.
Ist aktiviert da ich bei Apps mit eigenen Downloader, wie z.B. Threema, diesen auch prinzipiell verwende.
Aktuell tendiere ich dazu, daß dieses Verhalten von RethinkDNS ausgelöst wird. Diese App wurde in dem beobachteten Zeitraum mehrmals aktualisiert. Ich verwende aber immer noch die Version 0.5.5t, weil ich die Ursache des Komplettversagens von RethinkDNS eingrenzen möchte.
Nachtrag:
Ich reiche hier mal noch einen Screenshot von heute morgen nach. Auf diesem sind vier verschiedene Zeitabschnitte der letzten Tage zu erkennen (allesamt Ladevorgänge) in denen die Zugriffsversuche erfolgten.
Ich sollte wegen der Formulierung in https://social.tchncs.de/@kuketzblog/116803930223872181 (danke fürs Fragen!) dazu schreiben, dass zumindest bei den von mir verwalteten Geräten das Firebasegedöns von RethinkDNS ausgeschaltet bzw. in Version n noch gar nicht verfügbar ist.
Ich würde zum Eingrenzen als Erstes einen möglichst langweiligen A/B-Test machen: einmal mit RethinkDNS komplett gestoppt bzw. deaktiviert und einmal nur mit deaktiviertem „In-App-Downloader“. Wenn der Zugriff nur im zweiten Fall verschwindet, wäre das ein ziemlich starkes Indiz Richtung RethinkDNS. Falls er auch ohne laufendes RethinkDNS bleibt, würde ich eher bei Download Manager/MTP/Android-Systemkomponenten suchen und nicht bei GrapheneOS-spezifischen Standardverbindungen.
Das ist so nicht richtig bzw. zumindest stark übertrieben. GrapheneOS hat dort zwar auf die Implentierung von Rethinks „stability program“, dass Googles Crashlytics nutzt, hingewiesen und damit indirekt die Frage aufgeworfen, ob es damit zusammenhängen könnte - was nachvollziehbar ist und auch aufgefordert, das Ganze mal außerhalb von Rethink-DNS zu loggen zu versuchen - was ebenfalls nachvollziehbar ist. Ich sehe nirgends in dem Thread, dass jemand von GOS direkt behauptet, dass es an RDNS liegen müsse - das machen dort eher andere Nutzer. Wo hast Du dies gelesen, dass GOS es auf Rethink „schiebt“?
Es gibt in den Einstellungen von RDNS noch den Punkt Website-Icon in DNS-Logs anzeigen, der im verlinkten Thread von Nutzern im Verdacht stand, diese Verbindungen zu verursachen. Das konnten andere Nutzer dort offenbar widerlegen. Aber diese Downloads könnten mit der von @TeomaHK beobachteten Meldung hängen, oder aber auch der Download von lokal genutzten DNS-Blocklisten, falls diese verwendet werden.
Nein, es scheint zu 99,9% ausgeschlossen, dass es von Rethink ausgelöst wird. Im GOS-Forumsthread hat ein Nutzer dies sowohl mit als auch ohne Rethink getestet. Dieser scheint das recht akkurat auf einem frisch installiertem GrapheneOS mit lediglich Rethink als installierter Dritt-App getestet zu haben - einmal mit aktivem Rethink und einmal mit komplett in den Android-App-Einstellungen deaktiverter Rethink-App, während die Verbindungen über ein Pi-Hole außerhalb des Geräts getrackt wurden - mit jeweils dem gleichen Ergebnis.
Es kann daher eigentlich nicht an Rethink liegen. Wenn eine komplett deaktivierte App so etwas auslösen könnte, dann hätte Android/AOSP/GOS an sich wohl ein ganz anders Problem.
@kuketzblog Auch von mir ein Danke, dass Du Dich dieses Phänomens annimmst. Aber zusätzlich zu dem von @Emmeline genannten Punkt, möchte ich noch anmerken, dass Du in Deinem Post schreibst, dass es „oft“ während des Ladens auftritt. Allem Anschein nach tritt (bei denen es auftritt) es nur während des Ladens - und dann aber zuverlässig - auf. Außerdem ist der eben genannte Punkt, dass es offenbar auch bei komplett deaktiverter Rethink-App auftritt, nicht zu vernachlässigen.
Ich verfolge den eingangs verlinkten Thread im GOS-Forum auch bereits, seit er erstellt wurde und kann diese Verbindungsversuche zu gstatic.com spätestens seit diesem Zeitpunkt auch bestätigen. Allerdings fehlen mir die Zeit und die Möglichkeiten, dies selbst näher zu untersuchen oder zu testen, da ich nur ein Gerät habe, dass ich täglich nutzen muss und daher weder frische Neuinstalltionen noch sonst irgendwelche eingehenderen Experimente - wie einige in dem Thread dort - machen kann. Ich begnüge mich seitdem daher mit dem Blocken dieser Verbindungen und verfolge den Thread. Was ich jedoch bestätigen kann:
Es werden laut DNS-Log in RethinkDNS immer und zuverlässig mehrere Verbindungsversuche zu gstatic.com initiiert mit dem Eingangs genannten „Paket“ aus 5 Apps als mutmaßlichen Auslöser. Dies bei jedem Ladevorgang des Geräts und nur dann.
Es hat offenbar nichts mit der im Thread vermuteten Webicon-Download-Funktion zu tun. Es tritt sowohl mit dieser - dann werden Verbindungen zu anderen, von Rethink in diesem Zusammenhang genannten Adressen gemacht - als auch mit ausgeschalteter Funktion.
Ebenso ist die Teilnahme am ‚stability program‘ (Crashlytics) deaktiviert und dennoch treten die Verbindungsversuche wie zuvor beschrieben auf.
Du hast recht, das haben sie nicht direkt geschrieben. In dem als Lösung markierten Post haben sie nur geschrieben, dass eine andere App den Download auslöst, und später haben sie nahegelegt, ohne Rethink zu probieren. Ich habe das zwischen den Zeilen interpretiert, aber vielleicht übertrieben. Ich korrigiere meinen Post oben entsprechend.
Da ich heute mein Gerät wieder aufladen musste, habe ich es gleich mal mit deaktiviertem „In-App-Downloader“ versucht - obwohl ich mir nicht vorstellen konnte, dass es irgendwie damit zusammen hängen könnte. Und wie (von mir) erwartet, machte es keinen Unterschied, die Verbindungsversuche tauchten genau wie immer auf.
Tracken via Pi-Hole o.ä., wie es einer der Nutzer im GOS-Forum getan hat, ist mir leider bislang nicht möglich, so dass ich die Probe mit deaktiviertem RDNS nicht bewerkstelligen kann. Aber das wäre eh nur auf einem frisch installierten System sinnvoll, mit mehreren anderen installierten Drittanbieter-Apps wäre das nicht besonders aussagekräftig.
zu GOS kann ich nichts beitragen, aber ich habe bei Android schon erlebt, daß „deaktivierte“ Apps Aktivitäten gezeigt haben.
Direkt nach dem Deaktivieren muß man sie in der Regel auch wirksam beenden, solange die Option „beenden erzwingen“ unter Info noch aktiv ist, ist imho die App nicht wirklich beendet.
Wirksamer ist es, die App unter Info-> „Akkunutzung der App“ zu beenden, hilft aber auch nicht bei allen, insbesondere bei nicht-google-freien Geräten nicht. Das „Beenden erzwingen“ muß dauerhaft deaktiviert bleiben und nicht wieder anwählbar sein.
Berechtigung für Alarme/Wecker und Benachrichtigungen können u.a. das dauerhafte Beenden verhindern. (bei Hinter- und Vordergrunddiensten bin ich mir nicht sicher)
gibt es den letzten Punkt eigentlich auch unter GOS? War mir in Vergangenheit gar nicht aufgefallen, setzt aber mit Sicherheit Datenübertragung voraus. (Android 17 seit kurzem hier auf dem Pixel 6 Pro)
Also unter GOS habe ich es noch nicht erlebt, dass sich eine deaktivierte App von selbst wieder aktiviert, Zumindest nicht bei Drittanbieter- oder „Anwendungs“-Apps. An System-Apps habe ich diesbezüglich bislang nicht rum gefummelt, daher kann ich es dafür nicht beurteilen. Klar, „beenden erzwingen“ gehört ggf. auch dazu, aber wenn das unter GOS getätigt und die App daktiviert wurde, bleibt das auch so. Auch Apps mit Alarm/Wecker-Berechtigung habe ich da noch nicht sich selbständig wieder aktivieren gesehen.
Natürlich ist die Deaktivieren-Funktion nicht für jede App verfügbar - vor allem für bestimmte System-Apps nicht, unter GOS zumindest auch nicht für die Telefon-, SMS- und Dateien-Apps. Aber für die Apps, die sich deaktivieren lassen - wozu auch RethinkDNS gehört - funktioniert es zuverlässlich.
Ich habe über Nacht ein Testgerät mit LineageOS bespielt, RethinkDNS Version x installiert, und laden lassen - voilà, der gleiche Aufruf von gstatic.
Gibt’s eine App-Empfehlung zum Mitschreiben der Domainaufrufe auf dem Gerät per App ohne RethinkDNS? Ein externes Beobachten kann ich derzeit nicht angehen.
Mir geht das ebenso. Jedoch mit einem Unterschied. Ich besitze noch ein zweites Gerät. Ein Pixel 6a, welches in der Grundkonfiguration dem Pixel 7a gleicht und nur, aufgrund des Einsatzes als Navigationsgerät am Fahrrad, bei den installierten Apps Unterschiede aufweist. Bei diesem Gerät kann ich nichts dergleichen beobachten.
HIer möchte ich noch meine eigenen Beobachtungen hinzufügen:
Die Verbindungsversuche finden nicht sofort mit dem Beginn des Ladevorgangs statt. Es vergehen immer ca. 10 Minuten bis der erste Versuch stattfindet.
Es sind immer exakt 5 Verbindungsversuche pro Ladevorgang. Nicht mehr und nicht weniger.
Bei dieser Erkenntnis hatte ich auch einen spontanen Gedanken. Welche App auf meinem Pixel erkennt und analysiert den Ladevorgang? Das schließt auch das anstecken des USB-C-Ladekabels ein. Ich habe aber diesen Gedankengang nicht weiter verfolgt.
HIerzu möchte ich noch anfügen, daß die Meldung tatsächlich - wenn ich mich nicht irre - in eckigen Klammern „unbekannt“ anzeigt. Sollte diese Meldung nochmal auftauchen, werde ich dann einen Screenshot machen.
Ich verwende tatsächlich die DNS-Blocklisten lokal. Doch wie passt das mit dem Download-Manager von GOS (deaktiviert) und dem In-App-Downloader (aktiviert) zusammen?
Zuletzt noch einen Screenshot vom gestrigen Ladevorgang. Nach ca. 10 Minuten des Ladevorgangs das gleiche Spiel - 5 Verbindungsversuche.
Ich habe jetzt auch mal nachgeschaut. Auf dem Phone mit Stock Android und RethinkVersion t, alle Verbindungen zu Google per DNS Blockliste geblockt, habe ich keine gstatic Verbindungsversuche.
Auf dem Tablet habe ich welche, aber da ich dort noch auf Version n bin, werden die Verbindungsanfragen nicht den Apps zugeordnet, sodass ich nicht sehen kann, woher sie kommen. Ich habe aber auch nicht 100 Prozent die gleichen Apps auf beiden Geräten.
Unter Netzwerk, ja, aber unter DNS nicht. Und unter Netzwerk sehe ich ja keine gstatic Abfragen, weil die ja vorher durch die Google-Block-List abgefangen werden. Unter DNS sehe ich zwar die geblockten Anfragen, aber da kann ich eben unter es nicht sehen, welche App es war.
Das wurde erst in einer der späteren Versionen geändert, dass man es jetzt bei beiden Protokollen sehen kann.
Some users have reported seeing a connection to www.gstatic.com when the device starts charging which is due to certificate transparency logs being fetched. We’ve been planning to review certificate transparency log updates for a while but hadn’t gotten to it yet. We’ll have our own approach soon.
Yey, da muss wohl tatsächlich erst der Herr Kuketz kommen, damit die sich bei GOS ernsthaft dieser Sache annehmen. Den Meldungen der User im GOS-Forum wurde ja nicht so viel Beachtung geschenkt. Und der Herr Micay schreibt dann auch gleich wieder einen halben Roman zur Erklärung auf Mastodon.
Den Meldungen der User im GOS-Forum wurde ja nicht so viel Beachtung geschenkt. Und der Herr Micay schreibt dann auch gleich wieder einen halben Roman zur Erklärung auf Mastodon. 