Auf einem Shift6mq mit iodé 6 und auf einem Shift8 mit iodé 7.6 zeigen die beiden Apps de.barmer.ecare und de.barmergek.serviceapp dasselbe Verhalten: Die Apps lassen sich installieren. Wenn ich eine der Apps aufrufe, vergrößert sie sich (nimmt den ganzen Bildschirm ein) als ob sie starten wollte, fällt aber dann sofort oder nach wenigen Sekunden wieder in sich zusammen. Ausschalten von iodé (Firewall, Filterung) ändert nichts. Beide Apps tuns auf einem älteren Android (Samsung).
Was kann ich tun, um den Fehler zu finden und - hoffnungsvoll - zu beseitigen?
Ich bin nicht bei der Barmer, habe aber zum Testen “Meine Barmer” installiert. Die App startet normal und fragt die Grundeinstellungen ab. Wenn ich dich richtig verstanden hast, kommst du gar nicht bis zur Abfrage der Einstellungen.
Ich kann dein Problem auf meinem Shift 6mq mit iodeOS 6.15 also nicht bestätigen. (Mein Telefon ist gerooted mit den entsprechenden Einstellungen, root vor Apps zu verstecken.)
Hast du die Apps schon deinstalliert und neu installiert? Manchmal hilft’s.
Meine Barmer wird von Betriebssystem-Versionen unterstützt, die von den Gerätehersteller Google (Android) und Apple (iOS) bereitgestellt werden. Auch abweichende Android-Varianten von Xiaomi oder Huawei werden unterstützt. Mit alternativen Betriebssystemen wie zum Beispiel Lineage, Ubuntu Touch, Sailfish oder Replicant ist eine Nutzung von Meine Barmer nicht möglich.
Oder sind das andere Apps?
That surprises me,
Barmer writes himself:
My Barmer is supported by operating system versions provided by the device manufacturers Google (Android) and Apple (iOS). Deviating Android variants of Xiaomi or Huawei are also supported.
With alternative operating systems such as Lineage, Ubuntu Touch, Sailfish or Replicant, it is not possible to use Meine Barmer.
Könnte sein, dass in meinem Test auf meinem gerooteten Gerät iodeOS/LineageOS nicht erkannt wird, weil ja versucht wird, das Rooten und andere Änderungen vor den Apps zu verstecken. Dann läge es nicht daran, dass die App auf Custom-ROMs nicht funktionieren würde, sondern daran, dass die Barmer das verhindern will.
Bei Plexus gibt es widersprüchliche Bewertungen zur Funktionsfähigkeit auf ROMs mit und ohne microG.
Danke für deinen Versuch. Deinstallieren und erneut installieren hat nichts gebracht. Auch nicht mit abgeschaltetem iodé. Bei dir könnte es am root liegen. Du benutzt magisk, richtig?
Root kommt hier nicht in Frage. Erstens ist die neue Benutzerin des 6mq, auf das die Barmer soll, eine Enduserin. Zweitens würde rooten die schon vorhandene Einrichtung vernichten.
Ja, ich benutze Magisk und entsprechende Module, um es zu verstecken. Das funktioniert nicht 100%-ig, aber offensichtlich bei der Barmer-App schon. Auch meine Banking-Apps funktionieren damit. Das Rooten hat natürlich auch seine Nachteile, weil man immer wieder nachjustieren muss.
Da kann ich mich nur anschließen. Leider ändern die iodé-Entwickler nichts an LineageOS, außer den beschriebenen Privacy-Features. Alle Probleme mit dem LineageOS-ROM fürs 6mq sind also auch in iodeOS enthalten.
Auch das Verstecken des Rootens wird z.B. dadurch erschwert, dass Lineage dem Namen des Android-Kernel “-lineage+” hinzufügt, auf dem 6mq z.Zt. “4.9.337-lineage+”. Auch das wird nicht geändert, weil sowohl Lineage als auch iodé schreiben, dass sie das Rooten nicht unterstützen. Brauchen sie auch gar nicht, es würde schon reichen, es nicht noch zu erschweren.
Ein “-lineage+” scheint hier nicht schuldig zu sein, siehe Screenshot.
Aaaber, was verrückt ist: Auf einem plain vanilla VollaOS (= LOS mit MicroG und ein paar Extras) auf dem Volla 22 (~ Gigaset GS5) tut es die “Meine Barmer” in exakt derselben Version! Nix root, keine weiteren Sperenzien.
Es kann an Volla liegen, dass es funktioniert. Soll heißen, dass ROM-Entwickler versuchen können, das System zu “verstecken” - das, was die Root-Module bei mir machen. Iodé tut das leider nicht. Wie sowohl der E-Mail-Support als auch @rik hier im Forum geschrieben haben, setzten sie nur die Datenschutz-Features auf LineageOS drauf und verändern sonst nichts. (Keine Kapazität)
@Merlin, nur zur Sicherheit: Hast du in microG „Device Attestation“ und „Google device registration“ aktiviert? Das bewirkt mehr, als man zunächst denkt, da es zusätzliche Funktionen von ih8sn („I hate safetynet“, obwohl SafetyNet selbst mittlerweile von Google deaktiviert wurde) usw. integriert. Ich bin mir ziemlich sicher, dass es beispielsweise verhindert, dass Apps erkennen, dass dein Bootloader entsperrt ist. Stelle auf jeden Fall sicher, dass diese und andere microG-Optionen unter „Self-Check“ alle aktiviert sind (vielleicht hast du das ja schon getan).
@Merlin just checking to make sure you have “Device Attestation” and “Google device registration” enabled in microG? This does more than first thought, as it integrates additional bits from ih8sn (“I hate safetynet” even though SafetyNet itself is now deactivated by Google), etc. I am pretty sure it prevents apps from knowing your bootloader is unlocked, for example. Anyway, do make sure those and other microG items under “Self-Check” are all enabled (maybe you already did).
Ja gut, das heißt, dass Volla einen Weg gefunden hat, die Erkennung “dies ist kein original Android” durch Apps zu verhindern. Pluspunkt für Volla, schade für LOS, /e/OS und iodéOS.
Auf der anderen Seite kämpfen wir hier an der falschen Front, nämlich beim Endgerät und seinem OS. Der wirkliche Übeltäter ist doch der Anbieter der überempfindlichen App, in diesem Fall Barmer. Ich habe mal ein bisschen recherchiert und dies gefunden:
Vor sieben Jahren hat Barmer eine App für die ePA ausgeschrieben. Vermutlich ist daraus die “Barmer eCare” entstanden. Der Witz an dieser Ausschreibung, wenn man denn darüber lachen mag, ist, dass FOSS ausdrücklich ausgeschlossen wurde! Nicht zu fassen. Barmer: Freie Software für ePA nicht erlaubt? - Pro-Linux
So ein Sch…-Laden.
Aber dann Custom-ROMs ausschließen, das haben wir gerne! Jedes Custom-ROM schützt die Privatsphäre und die Daten besser als jedes hergelaufene original Android. Ich werde mal eine geharnischte Beschwerde verfassen.
OT: Da gebe ich dir Recht - aber wir kämpfen mit /e/OS, iodeOS, Volla (kannte ich noch gar nicht) die ganze Zeit an der “falschen Front” - nämlich dass wir gegen Googles Monopol mit der Manipulation eines Google-Produkts arbeiten. Das ist doch schräg. Damit schafft man sich Ruhm als Partisanenkämpfer, aber keine wirklichen Lösungen.
Wenn all die OS-, Root- und andere Tricks-Entwickler an einem Strang ziehen statt jeder sein persönliches Süppchen kochen würden (ich habe keine Kompetenzen in dem Bereich), unterstützt von europäischen Mandatsträgern und Investoren, wäre sicher die Kapazität für ein drittes OS neben Android und iOS vorhanden. Aber das werde ich mit meinen Ende-60 kaum noch erleben.
Vor allem: Die Alternative gibt es schon, nämlich Linux. Technisch kann das nicht so schwer sein, schließlich beruht AOSP im Kern auch auf Linux. Auch die Entwicklung von Apps für Linux dürfte ähnlich der für Android sein, also müsste das Rad nicht neu erfunden werden.
Zwei Probleme behindern das wachsen eines Biotops für Linux-mobile: Erstens die Marktmacht und -interessen der beiden großen Player, zweitens das Streben nach Geheimniskrämerei vieler App-Anbieter (zu denen gehört auch die Barmer). Security by Obscurity hat noch nie funktioniert, aber dennoch halten viele an diesem mittelalterlichen Rezept fest. Zukunftsorientierte Anbieter wissen, dass man auch FOSS wasserdicht sicher machen kann. Beispiele sind Bitwarden oder Signal.
Den Ansatz von Sailfish finde ich vielversprechend: Eine Linux-Basis und zusätzlich eine (kostenpflichtige) Kompatibilitätsschicht für Android-Apps. Aber auch Sailfish ist leider eine Nischen-Veranstaltung, nur auf wenigen Geräten verfügbar.
ja, Geräte-Registrierung war und ist an mit Profil “Automatisch: Nativ”
Geräte-Zertifizierung war und ist an. Allerdings darunter “Apps, die SafetyNet verwenden” steht als erstes MicroG-Dienste. Wenn ich da reingehe, ist “Anfragen zulassen” ausgeschaltet. Ich kann es einschalten, aber das wird nicht gespeichert. Wenn ich zurück gehe und wieder rein, ist es wieder aus. “SafetyNet-Zertifizierung testen” scheitert mit Fehlermeldung. Wäre der Code hier interessant?
reCAPTCHA testen läuft ewig, aber tut nichts. Ich muss es manuell abmurksen.
Beides auch bei ausgeschaltetem iodé-Schutz. Ich habe kein Konto bei Guugel.
Die SafetyNet-Zertifizierung ist veraltet und von Google deaktiviert. Das kann nur scheitern. Das wurde ersetzt durch Play Integrity und ist in microG noch nicht integriert. Der Schalter bei microG für die Gerätezertifizierung reagiert bei mir genauso. Ich vermute, dass der auch nicht hilfreich ist, weil jede App selbst anfragt.
Wenn ich den Hauptschalter für die Gerätezertifizierung an habe, gibt nur der Play Integrity API Checker (im Aurora Store erhältlich) ein positives Ergebnis, bei allen anderen Apps, die es versuchen, scheitert es. Ich vermute, dass der Tipp von @rik nicht weiterhilft.
Ja, die Safety-Net-Server wurden deaktiviert, deshalb schlagen diese Tests fehl. Und ja, die höheren Stufen von „Basic“ bei Play Integrity werden noch nicht unterstützt. Aber wie bereits erwähnt, gibt es „andere Funktionen“, die der Schieberegler für die Gerätebescheinigung über Safety-Net hinaus bietet. Deshalb wollte ich nur sicherstellen, dass er aktiviert ist.
Aber ja, viele Apps funktionieren ohne die vollständigen „Google Play Services“ nicht richtig, und diese scheint eine davon zu sein
Yes, Safety Net servers have been disabled, those tests fail because of that. And also, yes, the higher levels beyond “basic” for Play Integrity are not supported yet. But as noted, there are “other things” that the Device Attestation slider do beyond SafetyNet. So I just wanted to make sure it was enabled.
But also, yes, many apps will not work correctly without full “Google Play Services” and this seems to be one
Als ein Addendum, da technisch am besten gleich in English:
I took a logcat from an health app that’s also saying my device is insecure. It’s stumbling at
system/security/keystore2/src/remote_provisioning.rs:98 - Failed to get rkpd key: system/security/keystore2/src/remote_provisioning.rs:132: Trying to get IRPC name.
06-18 08:01:18.239 916 25279 W keystore2:
06-18 08:01:18.239 916 25279 W keystore2: Caused by:
06-18 08:01:18.239 916 25279 W keystore2: 0: system/security/keystore2/src/globals.rs:446: Failed to get rpc for sec level r#TRUSTED_ENVIRONMENT
06-18 08:01:18.239 916 25279 W keystore2: 1: Error::Km(r#HARDWARE_TYPE_UNAVAILABLE)
06-18 08:01:18.297 916 25279 E keystore2: system/security/keystore2/src/error.rs:184 - system/security/keystore2/src/security_level.rs:680
Jedes Custom-ROM schützt die Privatsphäre und die Daten besser als jedes hergelaufene original Android. Ich werde mal eine geharnischte Beschwerde verfassen.
Zukunftsorientierte Anbieter wissen, dass man auch FOSS wasserdicht sicher machen kann. Beispiele sind Bitwarden oder Signal.
