https://www.heise.de/news/Android-Google-verbietet-anonyme-Apps-10617479.html
Ist das ein weiterer Schritt in die oben besagte Richtung?
1 „Gefällt mir“
Ja, aber der Artikel ist nicht mehr ganz aktuell. Gibt hier einen Thread dazu irgendwo, vielleicht editiere ich nachher noch den Link rein 
1 „Gefällt mir“
Dürfte Geräte mit GOS ja aber nicht betreffen, meinem Verständnis nach, oder? Die laufen ja wahlweise auch komplett ohne Google?
2 „Gefällt mir“
Kann mir jemand diesen Diskussionsstrang erklären?
https://x.com/GrapheneOS/status/1994662988742365348
Da geht es um die Play Integrity Meldung, die auch bei mir hin und wieder bei bestimmten Apps aufploppt.
GOS sagt hier etwas von “Spoofing” und “Permitting individuals to spoof it is fine to them [Google]”.
Kann mir das jemand technisch erklären, was hier gemeint ist? Was wird gespooft und von wem und woher ist sich GOS sicher, dass Google tatsächlich “fine” damit ist?
Es ist halt von Google geduldet, aber nicht ganz offiziell. Von Betrug kann man nicht sprechen, weil alle es seit Ewigkeiten wissen und niemand sich aufgeregt hat deswegen. Also ortsübliche Sitte und Brauch auf diesem Planeten.
1 „Gefällt mir“
Meines Wissens arbeitet der Dev Strang von Google gelegentlich tatsächlich mit GrapheneOS zusammen wenn es um Sicherheit geht. Google würde da wohl auch gerne mehr machen aber der wirtschaftliche Zweig Googles möchte das eher nicht so gerne
2 „Gefällt mir“
Ne du bist definitiv nicht die einzige, es gab schon eine Menge Projekte, durchaus auch welche mit größeren Playern dahinter. Mozilla OS, Ubuntu Touch, postmarketOS, aktuell noch PinePhone oder Librem.
Das Problem liegt einfach an der schlechten Hardware- und Marktsituation. Für gängige SoCs gibt es keine Unterstützung, es gibt nicht ansatzweise soviel problemlos benutzbare Hardware wie im Desktopbereich, für ein echtes komplett funktionieredes Mobile-Linux braucht man daher eigene Hardware, und die wäre dann aufgrund der vergleichsweise kleinen Stückzahl um ein Vielfaches teurer als vergleichbare Geräte mit Android. Dafür gibt’s dann aber wiederum nicht genügend Abnehmer. Und dann kommt noch das große Problem dazu, dass die überwältigende Mehrheit der Nutzer*innen mit ihrem Smartphone fast ausschließlich proprietäre Apps und Dienste verwendet (WhatsApp, Instagram, Tiktok, Spotify) die kein Interesse daran haben, ein drittes Betriebssystem zu unterstützen das nicht hunderte Millionen Nutzer vorweisen kann. Daher gibt es ja nicht nur kein brauchbares mobiles Linux sondern de facto überhaupt keine Konkurrenz für Android und iOS, obwohl der Markt gigantisch ist, und jeder große Hersteller außer Apple mehr als froh wäre, nicht mehr so krass von Google abhängig zu sein.
6 „Gefällt mir“
12 Beiträge wurden in ein neues Thema verschoben: Digitale Forensik (Voraussetzung Bildung Bezahlung)
Um mal wieder etwas mehr zum eigentlichen Threadtitel zurückzukommen:
Folgenden “Bug” bemerke ich seit dem neusten GOS Update und der ist sehr gefährlich:
Manchmal erscheint, nachdem GOS automatisch neustartet (bei mir ist es eingestellt auf Auto-Neustart nach 4h), einfach keine Tastatur mehr, um das Passwort eingeben zu können und BFU zu entsperren.
Zwar habe ich eine Custom-Tastatur (Microsoft Swiftkey) installiert, aber ich bin mir nicht sicher, ob DAS die Ursache sein soll, denn die SwiftKey Tastatur wird überhaupt nicht verwendet, um den BFU Modus zu entsperren. WENN die Tastatur nämlich dann mal doch erscheint, ist es nie Swiftkey, sondern immer die ursprüngliche Tastatur.
Manchmal hilft ein Neustart, aber gerade eben half nicht mal das mehr. Ich wäre jetzt fast nicht mehr in mein Handy reingekommen, weil bei der PW-Abfrage im BFU Mode einfach keine Tastatur mehr da war. Habe das Gerät dann statt neugestartet einfach mal ausgeschalten und danach wieder eingeschalten. Dann war glücklicherweise wieder die Tastatur da, aber seitdem bin ich jetzt sehr misstrauisch und traue dem Ganzen nicht mehr.
Ob es mit der Custom-Tastatur (Swiftkey) zu tun hat, weiß ich nicht. Wie gesagt, eigentlich wird diese Tastatur immer erst geladen, sobald BFU entsperrt ist und man sich im AFU Mode befindet. Kann aber natürlich trotzdem sein, dass hier irgendwelche Konflikte zwischen ursprünglicher und Swiftkey Tastatur vorliegen und es deshalb zu diesem Phänomen kommt.
Jedenfalls ein sehr gefährlicher Bug, der einen ohne es zu ahnen jederzeit trotz aller Passwörter und Pins dauerhaft vom Handy aussperren kann, Komplettdatenverlust inklusive - denn mein USB-Port ist im BFU-Mode nur auf “laden” eingestellt - da hilft dann nämlich auch keine externe USB-Tastatur mehr oder sowas.
Sollte unbedingt ans GOS-Team weitergeleitet werden. Soweit ich es einschätzen kann, trat dieses Problem bei mir erst nach dem jüngsten GOS-Update auf. Vorher nicht, obwohl im GOS-Community-Forum auch schon vor dem Update von ähnlichen Problemen berichtet wurde.
@Peverell, das hatte ich oben weiter schon mal angemerkt. Bei mit hilft nur herunter fahren uns dann neu starten. Nur Neustart klappt nicht bei mir.
1 „Gefällt mir“
Danke dir. Der Neustart hat bisher geklappt, aber gerade vorhin nicht mehr. Da ging’s auch nur noch mit komplett ausschalten.
Bin jetzt aber trotzdem misstrauisch. Was, wenn es selbst dann mal nicht mehr klappt? Dann ist man für immer ausgesperrt und Daten sind weg?
Ist glaube ich ein gutes Beispiel dafür, wie im Worst Case zuviel Sicherheit manchmal eben auch die Freiheit killt.
1 „Gefällt mir“
Weiß nicht ob das mit anderen Systemen nicht ähnlich passieren kann. Mein S7 hatte sich eine Zeitlang mehrmals so aufgehangen, das überhaupt nix mehr ging. Nur noch reebot mit bestimmten Tasten Kombinationen.
Also mir persönlich ist so ein Bug (zumindest an einer solch kritischen Stelle wie bei Entsperrung) bei bisherigen Geräten noch nie vorgekommen. Und vor dem letzten GOS Update wie gesagt auch da nicht. Ob es mit dem neusten Update zusammenhängt und/oder mit dem Vorhandensein einer alternativ installierten Tastatur, obwohl beim BFU ja gar nicht die alternative Tastatur eingeblendet wird, keine Ahnung.
Hab gerade nochmal nachgesehen: es wird beim BFU aber auch nicht die primäre / Stock-Tastatur eingeblendet. Die sieht nämlich auch anders aus. Bei mir wird im BFU-Mode eine ganz eigene Tastatur eingeblendet, weder die primäre Stock-Tastatur, noch meine installierte Custom-Swiftkey.
Kann das jemand bestätigen? Was für eine Tastatur kommt bei euch im BFU-Mode? Vielleicht lassen sich ja darüber ein paar Hypothesen aufstellen… Alles in allem sollte das aber irgendwie mal ans GOS-Team gemeldet werden, damit die sich das anschauen können. Ist nämlich in meinen Augen nur eine Frage der Zeit, bis da mal jemand trotz vorhandener Passwörter gar nicht mehr reinkommt.
1 „Gefällt mir“
Das schrieb @phone-company oben dazu 
Wäh.
Es gibt ein offenes Item dazu. Gern selber lesen, aber für mich klingt das … ziemlich gefährlich. Gefährlich genug, nur AOSP Tastatur zu behalten? Weiß noch nicht…
https://github.com/GrapheneOS/os-issue-tracker/issues/6373
If the active keyboard can’t be loaded because it crashes or doesn’t refer to an available keyboard (e.g. when booting into safe mode or after manually setting default_input_method to a bogus value), GrapheneOS doesn’t automatically switch to another keyboard. Instead, no keyboard is shown (leading to bug #4662 for example). This seems to be your situation.
Finde das auch sehr gefährlich, da man Gefahr läuft, von 1 Sekunde auf die andere sämtliche Daten und den Zugang komplett zu verlieren. Anscheinend taucht der Bug auch willkürlich auf - ich konnte bislang jedenfalls noch keine reproduzierende Regelmäßigkeit feststellen. Eine tickende Zeitbombe also.
Wie ich ja weiter oben beschrieben habe, scheint (zumindest bei mir) die originale STOCK-Tastatur im BFU-Mode bei der PW-Eingabe gar nicht zum Einsatz zu kommen. Die Stock-Tastatur sieht bei mir ganz anders aus als jene, die nach Neustart im BFU-Mode geladen wird. Es ist aber auch nicht meine Swiftkey Custom-Tastatur.
Scheint irgendso ein eigenes Ding zu sein, das extra nur für die PW-Eingabe im BFU-Mode geladen wird? Eventuell liegt der Bug nämlich dann auch hier und weder an der Custom-Tastatur noch an der primären Stock-Tastatur.
Deswegen fragte ich weiter oben ja, ob das mal jemand überprüfen kann, ob die Tastatur im BFU-Modus dieselbe ist wie die Stock-Tastatur, oder ob da auch eine ganz eigene geladen wird.
Die Antwort vom Entwickler-Team im obigen Github-Thread auf die Frage, ob das bald gefixt werden könne, ist ja auch ernüchternd:
Yes, but we have a LOT of stuff we need to work on and it’s not really clear what’s wrong. It may be fixed in Android 16 QPR1 but we don’t have access to that yet.
Also sorry, aber wenn DAS keine absolute Priorität vor allem anderen hat, dann weiß ich auch nicht. Dieser Bug kann von jetzt auf gleich sämtliche GOS-User aus ihren Geräten aussperren, wo dann oftmals nichts weiteres bleibt, als ein Reset inklusive Datenverlust… Also sowas sollte trotz “a LOT of stuff we need to work on” doch absolute Prio haben…
1 „Gefällt mir“
Ja, sehe ich auch so… wobei vermutlich ein Deaktivieren aller dritten Tastaturen reicht, um nicht erwischt zu werden. Es gibt also aus Entwicklersicht vermutlich mindestens einen Workaround, der die Sicherheit gewährleistet.
Ich habe bei mir jetzt als Hintertürchen die Exploit Protection so gewählt, dass auch BFU die USB-Verbindung möglich ist. Damit reduziere ich Sicherheit, aber im persönlichen Bedrohungsmodell ist “Tastatur geht kaputt” im Moment als wahrscheinlicher angesetzt als “jemand will mit Cellebrite ran”.
So wie ich den Github-Thread oben verstehe, scheint das aber gar nicht primär etwas mit den Primär- oder Sekundärtastaturen zu tun zu haben. Offenbar gibt’s da irgendeinen Bug, der einfach im BFU-Modus manchmal überhaupt keine Tastatur lädt und GOS schafft es dann auch nicht, auf eine (falls vorhandene) weitere Tastatur zu wechseln, weshalb dann in diesem Fall einfach überhaupt keine mehr geladen wird.
GOS-Team hat sich gerade geäußert dazu:
Is it still an issue in Android 16 QPR1? There’s a high chance it will be fixed in Android 16 QPR2. It’s very likely not caused by anything GrapheneOS changes.
Nun, dasselbe haben sie vorher auch schon gesagt bzgl. QPR1…
Solange das “issue” nicht gelöst ist könnte man ja auch vom Passwort auf eine 6 stellige oder längere (wenn das geht) PIN wechseln.
Oder lädt es beim booten den Ziffernblock zur PIN Eingabe auch nicht?