Viele Datenschützer nutzen Android Custom ROMs, um der Überwachung durch Hersteller zu entgehen. Leider fehlen diese einige heute übliche Funktionen wie Push Dienste. Deshalb empfehlen viele gerne microG. Ein Fehler?
Ich persönlich benötige diese Dienste nicht und nutze deshalb kein microG. Die Frage, welchen Mehrwert für Privatsphäre und Datenschutz microG bietet, hatte ich hier aber auch schon gestellt.
microG bewirbt das eigene Produkt wie folgt auf der Webseite:
Although most microG components are far from complete, users are amazed by the results. Free software users got extended application support, privacy-caring users can reduce or monitor data that is sent to Google and especially older phones can expect some battery life improvements. microG is not only used on real devices, but also replaces Google tools in test emulators and is even used in virtual mobile infrastructure.
microG, abgerufen am 04.12.2021 (Hervorhebung durch den Autor)
Die Gleichsetzung von Open Source mit positiven Effekten für Privatsphäre und Datenschutz als Werbestrategie ist hier mal wieder ein beliebtes, aber gefährliches Mittel.
Denn der Mehrwert für Privatsphäre und Datenschutz ist nicht besonders positiv. Das ist jedenfalls die Meinung der GrapheneOS-Entwickler, wie man im September in einem Thread auf Twitter darlegte:
Da viele Leser hier Twitter nicht nutzen möchte, fasse ich die Kernaussagen knapp zusammen:
- microG ist keine Open Source Implementierung, der App Dienste, da die darauf zugreifenden Apps weiterhin proprietäre Google-Bibliotheken nutzen.
- microG ist somit nur ein Open Source Zwischenhändler zwischen proprietären Bibliotheken und proprietären Diensten. Das bietet keinen Mehrwert für Privatsphäre und Sicherheit.
- Sie sind faktisch sogar unsicherer als die proprietäre Play Service-Implementierung, weil das API Sicherheitsmodell nicht richtig umgesetzt ist und Techniken wie Pinning nicht implementiert sind.
- Die Nutzung von microG erfordert die Umgehung von Sicherheitsprüfungen und Play Services Signaturen.
- Die Verwendung von microG kann nur durch eine invasiven Eingriff in das Betriebssystem erfolgen und setzt umfassenden Zugriff auf privilegierte APIs und spezielle SELinux-Richtlinien vorraus.
Meiner Meinung nach trifft damit auf microG die Bezeichnung „Snake oil/Schlangenöl“ zu. Die meisten kennen das bestimmt aus dem Kontext von Antiviren-Programmen. Es handelt sich per Definition um ein völlig wirkungsloses „Wundermittel“, das anstelle zu helfen sogar unerwünschte Nebenwirkungen haben kann. Genau das scheint nach Aussage der GrapheneOS-Entwickler, deren Expertise klar sein dürfte, auf microG zutreffen.
Bei GrapheneOS arbeitet man stattdessen an sogenannten „Sandboxed Play Services„. Letztlich scheint das eine sinnvollere Variante zu sein. Entweder man kann auf Google-Technologien verzichten oder nicht. Wenn man sie benötigt, hilft auch keine vorgeblich freie Reimplementierung in Open Source, da man Bibliotheken in den Apps und die proprietäre Serversoftware bei Google trotzdem nicht kontrolliert. Man verschafft sich damit bestenfalls die Illusion von Datenschutz und vielleicht ist das sogar kontraproduktiv für die Sicherheit des Geräts.
In Österreich bin ich gezwungen MicroG in /e/ einzusetzten, das sonst die Covid Kontakte app und der Green Pass nicht funktionieren.
Wirklich? Das ist ja ein Armutszeugnis sondergleichen! Für die Contact Tracing App braucht man hier zwar auch microG oder die Play Services aber die CovPass App für die Impfung funktioniert ohne microG.
Das wäre mir neu. Ich benutze „Corona Contact Tracing Germany“ aus F-Droid und habe weder microG noch Play Services auf meinem Phone laufen. Die App hingegen scheint tadellos zu funktionieren.
Tatsächlich, da war mein Kenntnisstand veraltet. Ich dachte die Tracing API wäre in den Play Services und microG integriert und nicht direkt in der App. Danke für den Hinweis!
Wer sich für mehr Informationen interessiert: https://fsfe.org/news/2020/news-20201208-01.de.html
Das hier ist aus dem FAQ der Corona Tracing App Germany:
– Do I need microG/signature spoofing for this?
– No, this app bundles a standalone version of the microG implementation that will get used when there’s no microG system installation found.
D.h., wenn kein MicroG da ist, dann bringen die ihr eigenes mit.
Naja du. Rauchst ja irgendwelche location provider und willst das nicht google verraten wo du bist und was du siehst?
Die.Nachteile von microg und dem.Ansatz des Signaturen. Spoofings kamen ja schon oft und sind sicherlich nicht von der.Hand zu weisen. Aktueller Stand ist aber, dass Nutzer einige Funktionen wollen die Google vormacht und welche die Lieblingsapps integrieren. Da empfinde ich einen Nachbau der Funktionen z.B. zur Kartendarstellung als sinnvoll.
Die.Herleitung zu snakeoil kann ich beim besten Willen nicht verstehen…
Ich verstehe den Kommentar irgendwie nicht richtig. Standorterkennung funktioniert via GPS, dafür braucht man nichts anderes. Mein Samsung Galaxy S10 ohne microG hat den Standort in Sekunden.
Zum Rest: Will ich Google-Funktionen, installiere ich Google-Software. Die Play Services lassen sich ja auch in Custom ROMs installieren.
Je nach Standort dauert die Erkennung des selbigen ohne Play Services oder microG mit entsprechenden Location Providern bei mir eine gefühlte Ewigkeit oder klappt sogar gar nicht, egal ob nun unter LineageOS oder GrapheneOS.
Die Location Provider (ich nutze Deja Vu, Mozilla Location Service und Nominatim) holen sich im Hintergrund regelmäßig den aktuellen Standort und speichern ihn auf dem Gerät, so dass eine spätere Erkennung des Standorts dann deutlich schneller geht.
Danke Gerrit, dieser Artikel trifft den Nagel auf den Kopf!
Die Darstellung stimmt nicht so ganz.
Ja, MicroG bietet in einigen Dingen wie Firebase Cloud Messaging eine Reimplementierung der Google Dienste, die wiederum auf Google Server zugreifen und bilden damit nur ein Open-Source-Zwischenlayer (was einem aber immerhin die Notwendigkeit erspart, sich dort mit einem Google-Account einzuloggen und dadurch Privacytechnisch deutlich besser ist).
Aber, MicroG reimplementiert in einigen Dingen aber eben auch die Google-APIs _ohne_ auf Google-Server zuzugreifen. Ein Beispiel dafür ist das unifiedNLP-Framework (https://github.com/microg/UnifiedNlp) für schnellere Standortbestimmung und zum Adressen nachschauen (ja, das Handy hat zwar GPS, nutzt aber zur initialen Bestimmung des Standorts die Informationen von WLAN und Funkzelle, was den Prozess deutlich beschleunigt und auch noch eine Menge Strom spart). Dieses Framework lässt einem dann die Wahl, ob man für den Lookup bei Mozilla, Apple, … oder doch lieber in einer lokalen Datenbank nachschlagen will. Ein weiteres Beispiel ist die Maps-API, bei der MicroG dann eben nicht auf Google-Maps zugreift, sondern das alles durch OpenStreetMap ersetzt. D.h., einige Apps für die es kein Open-Source-Pendant gibt (ich hatte das z.B. mal bei der MVG-App in München zum Fahrrad ausleihen), laufen nur Google-frei durch MicroG (weil die dortige Karte dann auf OpenStreetMap basiert).
Was MircoG außerdem noch leistet, ist es APIs, die keiner will (die Werbe-API) z.B. soweit zu reimplementieren, dass die proprietäre App läuft ohne abzustürzen, aber natürlich auch, ohne die Werbung anzuzeigen.
Weiterhin sind die ganzen verschiedenen Frameworks natürlich an- und abstellbar, sodass der Nutzer entscheiden kann, ob er dann doch auf Google-Server zugreifen will.
Zum Signature-Spoofing: Ja, das „umgeht“ Sicherheitsmaßnahmen. Der Patch tut dies aber nicht pauschal, sondern führt bei Android eine neue Capability ein, bei der der Nutzer _pro App_ entscheiden muss, ob diese die Signatur spoofen darf und dieses dann auch prominent angezeigt bekommt.
Also nein, MicroG ist kein Schlangenöl, sondern macht, dass manche proprietäre Apps, die bestimmte Google-APIs nutzen, jetzt vollständig Google-frei laufen, befreit einem von dem Zwang, einen Google-Account haben zu machen, wenn man dann doch Google-Serverdienste nutzen will und macht das alles auch noch vollkonfigurierbar.
Aber letztlich bleibt es ein Zwischenhändler zwischen proprietären Bibliotheken in den Apps und den Google-Servern. Wir wissen bei beiden nicht wirklich, was sie machen und was genau übertragen wird. Darauf zielt einer der Vorwürfe bei GrapheneOS. Wir wissen nicht mal, ob der fehlende Google-Account überhaupt einen Vorteil beim Versuch Tracking zu vermeiden bietet.
Zudem läuft microG mit sehr weitreichenden Rechten, umgeht Sicherheitsmaßnahmen und es man kann sich durchaus Fragen, ob man damit nicht mehr Risiken ins System zieht als zu umgehen.
Ja, es kann sein, dass microG manchmal unumgänglich ist. Ein Beispiel ist ja ganz oben in den Kommentaren. Viele ziehen sich das aber ins System, weil es nett ist, Open Source und man ja Google vermeidet. Ich behaupte, die meisten benötigen es gar nicht, weil die Zahl der Apps, die nur mit microG funktionieren, überschaubar ist. Damit werden vollkommen falsche Erwartungen geweckt, die es nicht nachweisbar bedienen kann.
Auch Virensoftware tut irgendwas. Sie findet sogar Schadsoftware. Sie behebt nur nicht wirklich das Problem und zieht weitere Risiken ins System. Ich finde den Vergleich deshalb angebracht und auch den Begriff „Schlangenöl“
Bei Virensoftware gibt es bereits genügend Beispiele, die deren Unsicherheit belegen. Bei microG sind die bisher nur theoretischer Natur. Ich werde meine Entscheidung microG zu nutzen in dem Moment überdenken, in dem eines dieser theoretischen Probleme mal in der Praxis demonstriert wurde.
Die meisten Datenschutzbedenken sind theoretischer Natur, weil der letztendliche Beweis meistens fehlt. Wenn du dich auf diese Position zurückziehst, kannst du auch Stock Android mit den Play Services nutzen.
Nein, kann ich nicht, denn was Google mit den Daten macht, ist bekannt.
Nein, eigentlich nicht wirklich, wenn wir mal ehrlich sind.
Es gibt begründete Vermutungen über die Datensammlung und Auswertung, aber keine exakten Belege über die Vorgehensweise. Wir wissen schlicht nicht genau, was Google wo erhebt und was davon verworfen und was weiterverarbeitet wird. Deshalb kann man genau so gut begründet vermuten, dass der Datenabfluss via microG schon ausreicht, um im „persönlichen Google-Profil“ zu landen.
Doch, diese Belege existieren:
https://windowsarea.de/2019/09/google-soll-identifizierbare-nutzerdaten-an-dritte-verkauft-haben/
Wir wissen auch, dass Google von Dritten Daten zukauft:
https://www.zdnet.de/88376351/bericht-avast-verkauft-daten-seiner-nutzer-an-google-microsoft-und-pepsi/
Google hat sich inzwischen so extrem durchgesetzt, dass man nicht mehr umhin kommt, dass sie Daten über einen haben, auch wenn man mit Gewalt versucht, sich davor zu wehren.
Will man sich wirklich davor schützen, muss man das Internet aus machen. Und selbst dann wird es Menschen im eigenen Umfeld geben, die Daten über andere an Google weitergeben.
Diesen Kampf haben wir verloren, wir können nur noch versuchen, den Schaden so gut es geht zu begrenzen. Für mich heißt das eben u.a. auch, dass ich microG nutze.
Deine Links belegen gar nichts und enthalten auch keine konkreten technischen Hinweise über die exakte Vorgehensweise von Google.
Du kannst dir gerne einreden, dass microG dich vor Google schützt. Wenn du damit besser schlafen kannst, ist das schön. Faktengestützt ist es aber nicht.
Die genannten Links widersprechen u.a. deiner Behauptungen, es gäbe keine Belege für die Datensammlung von Google. Wie das unten rum technisch funktioniert ist mangels Blick in den Quellcode aber nicht nachvollziehbar, ja.
Ich rede mir auch nicht ein, dass microG mich vor Google schützt, im Gegenteil.
Die Diskussion ist für mich hier beendet, du scheinst meine Aussagen absichtlich oder unabsichtlich falsch zu interpretieren, da macht eine Fortführung keinen Sinn mehr.
Bitte ließ noch mal meinen Kommentar auf den du geantwortet hast. Ich habe nirgendwo die Datensammlung bestritten.
„Wir wissen bei beiden nicht wirklich, was sie machen und was genau übertragen wird.“
Wenn das wirklich ein Argument ist, darf man Apps wie Signal oder den DB Navigator auch nicht verwenden. Beide bestehen zumindest teilweise aus proprietärem Code, von dem niemand weiß, was er tut.
Hast du Belege für diese Behauptung bzgl. Signal?
Signal bindet Google Maps und Firebase Cloud Messaging ein. Deswegen existieren ja Forks wie z.B. Signal-FOSS:
https://www.twinhelix.com/apps/signal-foss/
Firebase Cloud-Messaging wird aber z. B. nicht genutzt, wenn man keine Play Services hat. Es kommt aber naturgemäß zum Einsatz, wenn man diese mit microG substituiert. Das ist ja genau einer der Knackpunkte an microG.
Hast du in den Code gesehen und geprüft, dass die proprietären Komponenten wirklich komplett nicht laufen, wenn keine Google Dienste (oder microG) genutzt werden? Falls dem wirklich so ist, nehme ich meine Aussage zu Signal natürlich zurück.
Ich kann den Datenverkehr mitschneiden und das mache ich sogar. Ich weiß also wohin Signal Verbindungen aufbaut (und jede andere App auf meinem Smartphone auch). Ich gehe aber auch davon aus, dass dies Sicherheitsexperten, die Signal empfehlen ebenfalls getan haben. Es gibt keine Verbindungsaufnahme zu Google-Diensten.
Ich fasse das mal zusammen: Nein, du hast nicht in den Quellcode gesehen, kannst also nicht sagen, was die proprietären Bestandteile in Signal genau machen. EOD.
Tatsächlich kann ich das nicht. Was ich aber weiß ist, dass sie keine Daten an Google-Server übertragen.
Meinethalben können wir die Diskussion gerne beenden, da es dir scheinbar nur darum geht, deinen Einsatz von microG zu rechtfertigen und du alle Fakten mit neuen Nebenschauplätzen vernebelst.
Kann man halt, wie oben erwähnt, natürlich einfach bei MicroG abstellen, Signal nimmt dann Websockets und man kann den DB-Navigator immer noch mit OSM-Karten genießen.
Habe ich vergessen: Hier https://github.com/microg/GmsCore/wiki/Implementation-Status ist eine gute Übersicht der Einzeldienste.
Schlangenöl ist die falsche Bezeichnung, für mich ist microG einfach nur ein hässlicher Workaround, der leider nötig ist, weil einige Hersteller ihre Apps nicht vernünftig bauen. Da gibt es Apps, die zwingend auf den Play Services aufsetzen (z.B. NINA für die Push Notifications oder die Ortung im Hintergrund, und ja, ich kenne FOSS Warn, das ist noch keine Alternative) oder Apps, die ohne Play Services nicht zuverlässig funktionieren bzw. den Akku schneller leer saugen, als ich die nächste Steckdose finde (z.B. Signal). Und jetzt bitte kein „das Problem habe ich mit Signal nicht“ oder „das Problem existiert nicht“, wie es der GrapheneOS Entwickler gerne von sich gibt, es ist real und es finden sich dazu mehrere Issues auf GitHub.
Das ist alles andere als schön, aber IMHO immer noch besser, als sich das komplette Google Services Framework aufs Gerät zu holen, so wie es bei GrapheneOS gemacht wird.
„Das ist alles andere als schön, aber IMHO immer noch besser, als sich das komplette Google Services Framework aufs Gerät zu holen, so wie es bei GrapheneOS gemacht wird.“
Genau das wird von Sicherheitsexperten anders gesehen. Ich bin über das ganze Thema/Konzept tatsächlich das erste mal im Blog von Mike Kuketz gestolpert. Die Implementierung der proprietären Play Services in einer nicht privilegierten und abgeschirmten Umgebung (Sandboxed) kann für Privatsphäre und Datenschutz sinnvoller sein als ein zusammen gefrickelter Workaround (um dich zu zitieren). Da lassen sich zu viele vom Begriff „Open Source“ blenden.
Und auch wenn du es nicht hören magst: Ich habe hier ein Testgerät mit /e/ (also auch mit microG) und kann keinen Vorteil im Vergleich zu einem LineageOS-Gerät ohne microG sehen. Ich nutze drei Messenger (Threema, Signal und WhatsApp) und alle funktionieren auch ohne Push Notifications. Bei anderen proprietären Apps wie dem DB Navigator muss ich auf so fancy Funktionen wie die integrierte Karte verzichten. Das sind Kompromisse, die man für Privatsphäre und Datenschutz eingehen muss. Ansonsten kann man gleich bei einem iPhone bleiben. Dort hat man mehr Komfort und kommt vermutlich bei einem ähnlichen Datenschutzniveau raus.
Ich habe nichts von einem „gefrickelten Workaround“ geschrieben. Wenn du mich zitierst, mach das Zitat bitte entsprechend kenntlich.
Natürlich ist microG ein Kompromiss, das bestreite ich gar nicht. Ich habe vor Jahren bereits CopperheadOS auf einem Google Nexus verwendet, zu einer Zeit, als es weder CalyxOS, noch GrapheneOS gab. Und ich habe mich dann bewusst für den Kompromiss CalyxOS entschieden, der microG beinhaltet. Wäre maximale Sicherheit mein Fokus, würde ich auch GrapheneOS nutzen.
Threema funktioniert problemlos mit Polling, da spüre ich bei der Einstellung alle 15 Minuten zu pollen auch keinen Unterschied. Zu WhatsApp kann ich nichts sagen, das nutze ich nicht, aber bei Signal gibt es das Problem durchaus:
https://github.com/signalapp/Signal-Android/issues/9729
Ich nutze mein Smartphone (ein Pixel 4a) sehr wenig, komme mit einer Akkuladung so zwischen vier und fünf Tage weit. Nutze ich Signal ohne microG verringert sich die Laufzeit auf etwas über einen Tag, was tägliches Laden nötig macht. Das ist ein drastischer Rückgang, den ich mit LineageOS, CalyxOS (ohne microG) und GrapheneOS auf mehreren Geräten reproduzieren kann und den ich nicht bereit bin zu akzeptieren.
Daher lautet mein Kompromiss microG, weil sich in meinem Umfeld Signal als Standard-Messenger durchgesetzt hat. In der idealen Welt in meiner Vorstellung könnte ich darauf verzichten, weil alle Menschen Messenger auf Basis von XMPP nutzen würden, bei denen die Föderation nicht mit Gewalt abgeschaltet wurde (wie bei WhatsApp).
Ich habe diesen Kampf auch lange gekämpft, bin inzwischen müde und daher dankbar für den Workaround microG.
Dir noch viel Erfolg, irgendwann kommst du auch in mein Alter 🙂
Ich weiß nicht was deine letzte Bemerkung hier soll.
Natürlich geht es immer um Kompromisse, dazu schreibe ich seit Jahren. Meinethalben kann man auch proprietäre Software nutzen. Warum nicht?
Ich habe ein Problem mit falschen Versprechungen und in diese Kategorie gehört für mich microG.
Auch XMPP hat das gleiche Problem. Google Cloud Messaging (oder jetzt Firebase Massaging) ist deswegen so gut, weil es die sowieso notwendige Verbindung zu einem Server von mehreren Apps bündeln kann. D.h., dass eben nicht mehr 3 Verbindungen von 3 Messaging-Apps aufgebaut werden müssen, sondern nur eine.
Eigentlich ist das ein ziemlich elegantes Konzept, ein vollständiger Open Source Nachbau wäre halt nett, bei dem ich bei Signal und den anderen Messengern als Push-Server meinen eigenen einstellen kann und nicht den von Google, und der Signal-Server dann eben die Benachrichtigung, dass eine Nachricht da ist, an meinen Server schickt und nicht an den Google-Server, der dann wiederum meinem Handy Bescheid sagt.
Meines Erachtens gibt es einen solchen Dienst aber nicht Open Source.
XMPP funktioniert zumindest mit Conversations als Client hervorragend ohne Google Cloud Messaging, und das auch ohne den Akku spürbar zu belasten.
Ich gebe Dir recht, dass die Sammlung von Push Nachrichten an einer zentralen Stelle keine schlechte Idee ist, wenn man viele solcher Dienste verwendet. Daher wird auch versucht, mit UnifiedPush eine vergleichbare Lösung zu bauen.
Daniel Micay hat offenbar ein persönliches Problem mit den Machern von CalyxOS, er und seine Community schießen permanent in deren Richtung. Ich persönlich gebe da nichts drauf. Das ganze fing an, als Techlore ein an einigen Stellen etwas ironisches Video mit einem Vergleich zwischen GrapheneOS und CalyxOS hochgeladen hat. Bis dahin zog man am selben Strang, ab dem Moment aber fühlte sich Daniel verfolgt. Das ging so weit, dass Daniel alle die Menschen, die parallel im GraphenOS und CalyxOS Matrix-Kanal waren, aus dem GrapheneOS Kanal rausgeworfen und verbannt hat, u.a. auch mich.
Es gibt dazu ein recht populäres Video von Techlore mit dem Titel „GrapheneOS: The MOST toxic privacy community“, das das Drama mit Stand von Anfang April schön zusammen fasst. Ich finde den Link auf Peertube gerade nicht, daher kein Link.
Für mich ist GrapheneOS inzwischen gestorben, weil ich den Haupt-Entwickler für problematisch halte. Aus dem selben Grund verwende ich auch Tiny Tiny RSS nicht mehr, obwohl das an sich tolle Software ist.
Ich habe mir das Verhältnis von GrapheneOS und CalyxOS nicht genauer angesehen und möchte nicht bestreiten, dass Daniel Micay eine schwierige Person sein könnte.
Ich verstehe aber hier den Punkt nicht. microG hat nichts mit CalyxOS zu tun, sondern ist ein unabhängiges Projekt und wird auf XDA Developers von ziemlichen vielen eingesetzt.
Korrekt, microG ist aber der einzige Punkt, an dem Micay gegen CalyxOS schießen kann (genau darum ging es ja im verlinkten Thread auf Twitter), und das tut er IMHO nicht wegen microG, sondern weil er ein böser Mensch ist. Bis zu einem gewissen Punkt war die Zusammenarbeit zwischen CalyxOS und GrapheneOS gut, zu der Zeit gab es auch keine Kritik von Micay an microG.
Es ist wohl eher umgekehrt:
Ich lese da öfters mal mit seit ca. einem 3/4 Jahr und habe viel mitbekommen, Daniel lässt manchmal sogar was über die Hintergründe rausgucken. Da gerade Techlore und die CalyxOS-Leute offensichtlich gegen GrapheneOS arbeiten (Daniel wollte nicht mit Techlore zusammenarbeiten, er strikt seine Sicherheitsentwicklungen verfolgt und hohe Ansprüche hat, CalyxOS noch kein AOSP 12 zustande bekommen hat, also Neid… Über Gründe dieser Community darf spekuliert werden) Sie haben wirklich viele falsche Dinge öffentlich behauptet und auf verschiedenen Wegen versucht, GrapheneOS schlechtzumachen. Neueste Methode ist die: Einfach User direkt anschreiben und „Zweifel“ anzumelden und „Kritik“ üben. Natürlich wird dabei nicht der Grund für das banning genannt: meistens sinnlose schon 100x gestellte Fragen zu wiederholen und Antworten zu ignorieren, anderen Usern bewusst falsche Antworten zu geben usw. Nicht Daniel hat den Mist angefangen…
Und so wie CalyxOS und Friends (mich würde nicht wundern, wenn das aktuelle Copperhead seine Finger da im Spiel hat) agieren, haben sie ja bei dir ihr Ziel erreicht: GrapheneOS ist toxisch und du hast dich abgewandt – Mission accomplished. :geek:
Daniel ist es nach Monaten der Angriffe einfach leid, dafür seine und anderer Entwicklungszeit opfern zu müssen. Und wenn man weiß, wie der Werdegang von CopperheadOS und GrapheneOS war, kann man seine Dünnhäutigkeit diesbezüglich vielleicht verstehen, aber er versucht, das Projekt zu schützen.
Ich für meinen Teil vertraue seiner Experise bzgl. Android/Enwicklung im allgemeinen und GrapheneOS im besonderen. Viele Dinge, die er entwickelt hat, sind sogar in AOSP eingeflossen und heute Bestandteil von Android.
Es gibt Belege für das schwierige Verhalten von Daniel, siehe das Video von Techlore. Mir sind keine Belege für das von dir behauptete nicht korrekte Verhalten von CalyxOS bekannt. Sobald mir die jemand zeigt, bin ich gerne bereit, meine Meinung zu ändern. Aber sowohl von Daniel als auch von dir sehe ich keine Belege, nur nicht belegte Behauptungen.
Welche falschen Dinge wurden von CalyxOS über GrapheneOS behauptet? Wo hat CalyxOS GrapheneOS schlecht gemacht? Du hast jetzt die Chance, deine Behauptungen zu belegen.
microG setzt wie viele freie Software-Projekte darauf, dass der Anwender weiß, was er tut. So kann man microG ohne Google-Registrierung oder Push-Benachrichtigungen benutzen und auch ganz ohne Verbindungen zu Google verwenden. Dann gibt es natürlich auch die entsprechenden Funktionen nicht. Damit sehe ich das Datenschutz-Versprechen schon erfüllbar durch microG.
Der Anwender kann entscheiden, welche Zusatzdienste über microG bereitgestellt werden. Die Corona-Warn-App ist ein Beispiel für eine App, die ohne Verbindung zu Google mit microG läuft. Mittlerweile gibt es die freie Alternative, die den erforderlichen microG-Code selber mitbringt. Daneben lässt sich eben zusätzliche Ortung neben GPS datenschutzfreundlich lokal realisieren.
Bleibt das Problem der Umgehung von Sicherheitslücken, da microG tief im System eingebettet laufen muss. Das sehe ich ähnlich, insofern dadurch die Sicherheitsanforderungen an microG genauso hoch sein sollten, wie an die Betriebssystemsoftware selbst.
Mein grösstes problem ist der fehlende Push dienst.
Ich werde von vielen seiten imer wieder deswegen angespeochen, weil ich Nachrichten, ob von Signa oder, Threema meist zu spät ethalte wenn die App nicht läuft.