News Aus der Community: GrapheneOS auf dem Google Pixel 8 Pro

[siggi%%44]

z.B. weil Kabel zu ungünstigem Zeitpunkt gezogen, weil man blöd dran gekommen ist oder so was

Bevor Images auf deinen Speicher geflasht werden, lädt sie der Bootloader zuerst in den RAM. Von dort aus werden sie erst aufgespielt, damit genau so ein Szenario, wie von dir beschrieben, nicht passieren kann.
PC -> RAM -> Speicher

 

[Snowi]

Gut zu wissen, danke! Werde es dennoch nicht ausprobieren

 

[Gandalf2210]

Ich weiß ja nicht.
Mittelmäßige Hardware wo der Preis eigentlich nur durch die Software gerechtfertigt wird, und dann schmeißt man das einzige Killer Feature über Bord und macht so ein Rom ohne Google drauf?

 

[siggi%%44]

Du siehst das falsch. GrapheneOS ist nur für sehr wenige Hersteller in vollem Umfang verfügbar und Pixel-Modelle sind das Vorzeigeprojekt. Es liegt also nahe, diese ROM auf ein Pixel aufzuspielen.

 

[FR3DI]

Schon klar das ausgerechnet Du antwortest.

Wie du meinen?

Aber ja das mit dem Bunker fand ich gut.

Ist ja auch nichts verkehrt dran. Mitunter wäre das genau der Fall. Das die Interne Sicherheit nicht immer mit korrekten Methoden vorgeht, gut. Diese offen zu legen und damit die öffentliche Sicherheit gefährden, weniger gut.

Denn irgendwer und oder irgendwas wartet nur genau auf diesem Punkt um dann in seinen Augen Selbstjustiz ausüben zu dürfen. Beispiele darf ich auslassen.

Die sollte auch jeder haben. Genau.

Heutzutage wird doch alles einem im Munde verdreht sobald man nicht akkurat mit dem Strom Schwimmt.

Gruß Fred.

 

[Haldi]

Naja, GrapheneOS will dir als Projekt ein Betriebssystem anbieten, aber das was du verlangst, ist ein sicherer Clouddienst der voll ins Betriebssystem integriert ist.

Jaein.
Ich will eigentlich keinen Cloud Service.
Ich will ein ROM das eine anständige BackupLösung direkt integriert!
Ob das jetzt incremental backups auf mein sFTP Server legt oder sonst irgend nen Service ist mir eigentlich egal!

 

[ContractSlayer]

Bin seit zwei Jahren auf GrapheneOS unterwegs und ich muss echt sagen, der Anfang war richtig hart. Kein Playstore, kein GMaps, das war nicht lustig. Mittlerweile gehts.

Ich verwende seit ca. 6 Jahren LineageOS OHNE GOOGLE DIENSTE, was in etwa GrapheneOS entspricht.
Vermisst habe ich bisher nichts.
Statt den PlayStore verwende ich den Aurora-Store, welcher b.B. ohne Konto oder per Fake-Konto auf den Googel-Play Store zugreift.
Auch greife ich auf den F-Droid Store zurück, gerade was die Sicherheitsapps betreffen.
Als Navi kommt für mich OsmAnd+ und Magic Earth in bestacht, wobei auch GMaps ohne google Dienste auf LineageOS funktioniert.
Kontakte und Kalendereinträge synchronisiere ich verschlüsselt per DAVx5 auf NextCloud der Telekom-Cloud.
Da mir der Datenschutz wichtig ist, was bei der Verwendung von GrapheneOS sicherlich auch in Betracht kommt. Verwende ich noch folgende Apps auf meine Smartphones:

• Magisk Manager (Root-Rechte),
• AFWall+ (openSource Firewall),
• AdAway (OpenSource-Anzeigeblocker),
• personalDNSfilter (openSource DNS-Filter-Proxy)
• KeePassDX (Passwortmanager)
• TOR-Browser (anonymes Surfen im Web)
• Tutanota-App (für den eMail Provider Tutanota)
• KDE-Connect (um Bilder, Dateien, Videos im Heimnetzwerk zwischen Linux auf dem Laptop und LineageOS auf dem Smartphone zu verwalten).

 

[Metzilein]

Super, danke für den Beitrag!

Schön wäre es, wenn GrapheneOS es auch auf das Fairphone, VollaPhone etc. schaffen würde. Die Geräte sind m.E prädestiniert dafür.

Shiftphone nicht vergessen 😊

 

[jenzen]

Jaein.
Ich will eigentlich keinen Cloud Service.
Ich will ein ROM das eine anständige BackupLösung direkt integriert!
Ob das jetzt incremental backups auf mein sFTP Server legt oder sonst irgend nen Service ist mir eigentlich egal!

Wenn du einen eigenen Server hast, benutz doch Nextcloud dafür. Da kannst du auch deine Kontakte usw. ablegen. Und für Dateien ist es ja im Kern gedacht.

Ansonsten kann ich auch SyncThing empfehlen (Peer To Peer Datei-Synchronisation, ohne Server, ist aber natürlich besser wenn man ein Gerät hat welches immer online ist (also ein Server) und somit immer die Veränderungen am Sync-Ordner erkennnen und an die anderen Geräte propagieren kann.

Damit bist du dann unabhängig von einem Provider der deine Dateien für dich hostet, bzw. du bist selbst dein Provider. Was auch empfehlenswert ist. Verschlüsselung sollte man trotzdem auch immer nutzen. Und immer Finger weg von den Cloud Storage Angeboten von Big Tech. Die wollen nur eure Daten und Metadaten haben, und im Hintergrund kann auch noch die US-Regierung legal drauf zugreifen. Gebt eure Sachen nicht leichtfertig raus.

 

[Departet]

Einziges Manko ist, dass es kein Android Auto und kein Google Pay unterstützt, da Google dafür zu tief in das System eingreift.

Danke für die Info, damit ist GOS oder eine andere CFW leider raus bei mir

 

[jenzen]

--Bitte die Zitierregeln beachten--

Kann man machen. Ist sicher nicht das schlechteste Android-Setup. Muss aber sagen, auch wenn ich LineageOS cool finde, dass der Primärzweck von LineageOS nicht ist, besonders viel Sicherheit oder Privatsphäre zu bieten (by default). Und schon gar nicht, möglichst Google-frei zu sein (was ja meistens direkt zusammenhängt mit der Privatsphäre - je weniger Google-Software involviert ist, desto privater). Sondern, dass man damit älteren Handys wieder Leben einhauchen kann. Sicherlich ist es eine bessere Basis als Stock Android oder proprietäres Android ala Samsung, und mit etwas Aufwand kann man es fast komplett aus den Klauen von Google befreien, aber im Vergleich zu bspw. GrapheneOS, welches von Kopf bis Fuß (und das dokumentiert und unabhängig nachgeprüft) auf maximale Privatsphäre und Sicherheit konzipiert ist, kann so ein LineageOS nicht wirklich mithalten. Außerdem hängt es bei LineageOS auch sehr am Maintainer des jeweiligen Ports für das Device, welches man benutzt. Es gibt gute und schlechte Maintainer. Bei GrapheneOS ist es halt ein ganzes Team was dran arbeitet, und die achten schon von der Basis her darauf, dass nur halbwegs sichere und supportete Geräte verwendet werden als Basis. Auch bspw. CalyxOS oder /e/OS wären vermutlich eine bessere Basis als Lineage, auch wenn diese auch im Vergleich zu GrapheneOS weniger empfehlenswert sind, da sie einfach nicht strikt genug sind.

Darüberhinaus macht Graphene noch mehr Dinge, um die Privatsphäre von Usern bestmöglich zu gewähren, und das meistens transparent bzw. unsichtbar im Hintergrund. Z.B. geht jede Anfrage an Googles SUPL-Server (oder den eures Providers, was fast immer eh nur ein Redirect an den von Google ist) zuerst an einen Proxy-Server vom Graphene-Projekt, welcher dann die personenidentifizierbaren Daten aus dem Request rausnimmt bevor er die Anfrage ohne diese Daten dann weiterleitet an den SUPL-Server von Google. Standardmäßig ist da bei jeder Anfrage eure Telefonnummer und IMEI-Nummer mit drin, um Google ein weltweit eindeutiges Tracking der Anfrage zu erlauben. Und das ist nur ein kleines Tracking-Detail, was wenige kennen.

Ich empfehle übrigens NetGuard Pro für eine detaillierte Filterung des Netzwerkverkehrs von allen Apps.

Ergänzung (20. Oktober 2023)

--Bitte die Zitierregeln beachten--

Als Tipp für die Nutzer der (sandboxed) Google Play Services (welche ich auch auf meinem alten GrapheneOS-Handy installiert habe, um dort bspw. die DHL-App nutzen zu können): es reicht solchen Apps oft aus, wenn die Google Play Services als (sandboxed) App einfach nur installiert sind. Es ist gar nicht mal notwendig, dass ihr den Play Services Internetzugriff gewährleistet. Auf meinem alten Handy sehe ich via NetGuard Pro dass die Play Services natürlich regelmäßig alles mögliche im Internet kontaktieren will, aber ich habe für die App keinerlei Internetzugriff erlaubt. Und die App, die die Services benötigt, läuft trotzdem (auch ohne nervige Warnmeldungen o.ä. dass die Play Services fehlen würden).
Somit kann man, auch wenn man die Play Services installiert haben muss (was ja ein Nachteil ist), trotzdem sicher sein, dass sie nichts nach draußen rausposaunen können.

 

[Amaoto]

Google stellt das Original-Betriebssystem der Pixel-Geräte öffentlich zur Verfügung (an der Stelle mal ein dickes Lob an Google). Damit kann das Smartphone jederzeit in den ursprünglichen Werkszustand zurückversetzt werden und hat dem Entsprechend auch die volle Garantie. Damit kann das Smartphone jederzeit in den ursprünglichen Werkszustand zurückversetzt werden und hat dem Entsprechend auch die volle Garantie.

Bevor der Bootloader entsperrt werden kann, verbindet sich das Smartphone mit Google, um die Seriennummer o.Ä. zu übertragen. D.h. Google weiß im Nachhinein trotzdem, ob das Gerät mal entsperrt worden ist oder nicht.

 

[Snowi]

D.h. Google weiß im Nachhinein trotzdem, ob das Gerät mal entsperrt worden ist oder nicht.

Habe grade mal nachgeguckt, weil es ja durchaus eine berechtigte Frage bzw. ein Problem für den ein oder anderen ist.
Eine offizielle Angabe finde ich leider nicht, aber viele inoffizielle die sagen, dass das flashen eines Custom ROM wohl nie ein Problem war, wenn man die Garantie nutzen wollte.
Ich vermute, dass Google da evtl. selbst schaut ob der Garantiefall damit zusammenhängt, und ggf. darauf basierend die Entscheidung trifft, was aus meiner Sicht als Kunde auch das vernünftigste ist.
Wenn ich das Handy flashe, und es dabei kaputt geht, würde ich sagen, dass das mein Risiko als Kunde / Benutzer ist. Geht aber z.B. ein Speicherbaustein kaputt, was Google evtl. schnell festgestellt (Handy aufgemacht, drauf geguckt, Speicherchip angekohlt o.ä.), wird das eher nicht wegen dem Custom ROM sein, also Garantie.
Ist natürlich nur blöd, dass man da nichts offizielles findet. Man muss sich also drauf verlassen, dass Google das einfach weiter so handhabt in Zukunft.

 

[jenzen]

Bevor der Bootloader entsperrt werden kann, verbindet sich das Smartphone mit Google, um die Seriennummer o.Ä. zu übertragen. D.h. Google weiß im Nachhinein trotzdem, ob das Gerät mal entsperrt worden ist oder nicht.

Der Grund, warum die Internetverbindung zu Google an der Stelle "nötig" ist, ist, damit Google verifizieren kann, ob das Gerät überhaupt OEM unlocked werden kann oder nicht. Manche Provider wie z.B. Verizon verkaufen Android-Phones mit Vendor-Lock. Die teilen das Google mit, welche S/Ns oder IMEIs das sind, die gesperrt sein sollen. Und Google hat das alles in ner DB hat und kann/muss nachschauen, ob das Gerät überhaupt entsperrt werden darf oder nicht. Warum das die Provider an Google ausgelagert haben, keine Ahnung, aber wie immer ist Google halt in weitaus mehr involviert als man denkt.

 

[siggi%%44]

Wenn ich eine Beta aufs Pixel flashen will, muss ich auch den Bootloader dazu öffnen. Die Beta kommt offiziell von Google und daher wird es dabei keine Probleme geben können.

 

[Haldi]

Eine offizielle Angabe finde ich leider nicht, aber viele inoffizielle die sagen, dass das flashen eines Custom ROM wohl nie ein Problem war, wenn man die Garantie nutzen wollte.

Oder...
Google ist einfach wesentlich Kulanter als man denkt.
Die 5-10% Aller käufer die ihren Bootloader entsperren und von diesen weniger prozent wird es vielleicht 0.05% Schaffen ihr Gerät in einen HardBrick zu verwandeln.
Was kümmert es da Google sich wegen diesen par wenigern Geräten gross probleme zu machen?

Zumal es beinahe unmöglich ist durch einen falschen Flash ein Gerät KOMPLET Zu zerstören.
Selbst WENN die komplette Boot Partition und alles flöten geht. Die war bei dem Zusammenbau des gerätes auch nocht nicht vorhanden und wurde erst später drauf geflasht.
Ich vermute mal die OEM's haben da noch wesentlich mehr möglichkeiten ein Gerät zu retten.

 

[ReactivateMe347]

Man muss dabei halt bedenken, dass AOSP bei Sicherheitsupdates hinterher hinkt, weil Graphene OS und andere Nicht-Google-Partner keine Vorab-Info von Google bekommen und daher die Patches nicht testen können, bevor sie im AOSP ankommen - und damit auch Angreifern bekannt werden. Wenn es dadurch nicht verzögert wird, dann hat man eben ein ungetstetes OS, das entsprechend instabil sein könnte.

Ergänzung (21. Oktober 2023)

Zur Garantie: So wie ich https://support.google.com/pixelphone/answer/9218411?hl=de verstehe hat man eh nur die Gewährleistung (in DE dann mit Beweislastumkehr nach 1 Jahr) - bei Gewährleistung kann Google sich nur rauswinden, wenn sie dir beweisen, dass das Custom ROM Ursache für das Problem ist - das wird es 1. in der Regel nicht sein und der Beweis ist 2. schwer zu führen - das 1 Jahr ist also kein Problem und mehr hat man offenbar eh nicht - was bei 7 Jahren Updates schon traurig ist. (Alternative: Google kriegt es nicht hin, ordentlich zwischen Garantie, also freiwilliger Leistung, und Gewährleistung, also gesetzlicher Verpflichtung, zu unterscheiden.)

 

[Snowi]

Man muss dabei halt bedenken, dass AOSP bei Sicherheitsupdates hinterher hinkt, weil Graphene OS und andere Nicht-Google-Partner keine Vorab-Info von Google bekommen und daher die Patches nicht testen können, bevor sie im AOSP ankommen

Das stimmt leider, allerdings stammen viele Patches ja aus dem AOSP Projekt selbst, also ganz so kritisch würde ich das nicht sehen. Zudem sind die Entwickler sehr flott bei sowas.

Falls sich übrigens jemand fragt, warum die Entwickler keinen Zugriff auf die Internen Updates von Google hat, wie es die ganzen OEMs haben (Das sind Aussagen der Entwickler, nicht meine):
Die Entwickler hatten mal eher inoffiziell durch die Android Entwickler bei Google Zugriff auf diese Sachen, weil die Graphene Entwickler wohl auch immer ihre Bugfixes ins AOSP Projekt eingebracht haben. Irgendwann haben sie dann aber den Offiziellen Zugang beantragt, die Entwickler waren dafür,
die "Business-Leute", wie sie es so schön beschrieben haben, waren dagegen. Seitdem haben sie keinen Vorabzugriff mehr auf die Releases, und seitdem pushen sie auch selbst ihre Fixes nicht mehr aktiv Upstream, weil Google an mehreren Stellen auf Entscheidungsträgerpositionen eher gegen das Projekt entscheidet. Ob absichtlich oder unbewusst, will ich aber nicht bewerten. Bei großen Firmen geht viel unter, kann mir schon vorstellen, dass da einfach die eine Hand nicht weiß, was die andere tut. Ist bei allen großen Firmen so.

 

[ReactivateMe347]

Das stimmt leider, allerdings stammen viele Patches ja aus dem AOSP Projekt selbst, also ganz so kritisch würde ich das nicht sehen. Zudem sind die Entwickler sehr flott bei sowas.

Soweit mir bekannt werden Sicherheitspatches vertraulich behandelt, damit Angreifer keinen Vorsprung haben, bevor es überhaupt den monatlichen Patch gibt. Ob dieser Patch dann im AOSP ist (und dort den normalen Nutzer verborgen bleibt) oder ob er erst mit Veröffentlichung des Security Bulletin ins Repo gepusht wird macht ja dann effektiv keinen Unterschied.

 

[_tnt_]

AFWall+ (openSource Firewall)

Genau so etwas habe ich gesucht. Erinnert mich etwas an die Datura Firewall von CalyxOS.