GrapheneOS verweigert Alterskontrollen im Betriebssystem


Kommentare zu folgendem Beitrag: GrapheneOS verweigert Alterskontrollen im Betriebssystem

Im verschiedenen Staaten will man auf Basis des Betriebssystems das Alter aller Nutzer überprüfen. GrapheneOS verweigert diesen Schritt.

Wirklich? Das sehen wohl nicht alle so, außer Linux und systemd ist kein „freies“ System mehr:

https://github.com/systemd/systemd/pull/40954

Das Problem wird zukünftig ja nicht das Betriebssystem selbst sein, sondern die einzelnen Programme, die eventuell eine Alterskontrolle verlangen.

Vielleicht kann anfangs noch ein Alter „Gefaket“ werden, aber spätestens, wenns um Zertifikate und Verschlüsselung geht, ist es rum.

Dann wird kein freies System mehr davor haltmachen können, wenn es aktuelle Programme verwenden will.

Ich ja schon bei einigen Banken Programmen so, das sie nicht auf jedem System oder mit Offenem Bootloader laufen.

Jap…was wird die Folge sein? Die Banking-App wird bestimmt nicht mehr „downgraded“, um wieder überall zu laufen!

Immer mehr Telefon-Hersteller werden immer mehr Modelle rausbringen mit:

#Closed Bootloader#

Und von diesen Smartphones haben wir aktuell schon massig in der freien Wildbahn! Da kann man die Hersteller anbetteln und die lassen konsequent die Dinger zu! Auch über den Zeitraum hinaus, wo sie noch zu FW-Updates verpflichtet sind, quasi bis Weltuntergang. Ob diese Entwicklung dann den Entwicklern von Custom ROMs in die Karten spielt - wohl eher nicht…das Gegenteilige wird natürlich der Fall sein.
Spätestens dann holt dieser Umstand auch Graphene in diesem Bereich wieder ein.
Natürlich kann man Graphene aus bekannten Gründen, nicht mit jedem 08/15 CROM vergleichen! Aber obs dann in Zukunft die Hersteller interessiert, obwohl diese so oder so ihre Kohle einfahren…
:thinking: :joy:

Das Problem wird wohl zunehmend größer, wenn man sein schickes GrapheneOS‑Smartphone nicht zu Hause lässt (https://www.derstandard.de/consent/tcf/story/3000000278495/katalanische-polizei-geht-gezielt-gegen-nutzer-von-pixel-smartphones-vor).

Hinzu kommt, dass SoCs mit ihrem proprietären Code immer mehr zur Herausforderung werden. Es bleibt abzuwarten, wie lange ein freies Betriebssystem da noch mithalten kann. Auf dem Desktop sieht man die Entwicklung ja bereits: Für aktuelle Hardware gibt es kein Libreboot mehr, und mit Pluton dürfte es auch für Coreboot zunehmend schwierig werden.

Am Ende fehlt nur noch, dass Hardware überhaupt nicht mehr verkauft wird, sondern nur noch als Hardware‑as‑a‑Service verfügbar ist.

In verschiedenen Staaten will man

Im Bereich der Telefone hat man dieses „Service-Modell“ doch über zig Jahre erfolgreich getestet gehabt.
Thema → Subventionierte teure Handys, die mit Knebelverträgen der Provider und vielen Kundenfallen an die Menschen abgegeben wurden. Zuerst noch mit dem Eigentümerwechsel bei Vertragsende, was dann auch noch gestrichen wurde! Also quasi wirklich ein Mietgerät, wenn man es dem Anbieter nicht zu überhöhten Preisen abkauft…
Diese Phones waren alle durch die Bank mit #Closed Bootloader# ausgestattet. Zwar wurde dieses Geschäftsmodell in den letzten Jahren step by step aus dem Verkehr gezogen, was aber keinesfalls heißt, dass man dies nicht RuckZuck wieder reaktivieren kann und dann wieder schleichend mit künstlicher Verknappung der „freien“ Geräte, in den Markt bringt!
Wo haben die Provider das sehr gut gelernt…natürlich bei der Deutschen Post, die jahrzehnte lang nur ihre eigenen Festnetz-Telefone zugelassen hatte, um sie über etliche Jahre ihren Kunden zwangsvermietet in die Rechnung zu schreiben.
Das diese uralten Mietverträge der Post (i.V. Telekom) manchmal erst heute noch gekündigt werden, wenn Oma stirbt o.ä., ist ein weiteres Zeichen dafür, dass „Hardware-as-a-Service (HaaS)“ prima funktioniert!
Im PC-Bereich erinnere ich mich noch an Versuche von Nvidia und Konsorten, GraKas zu vermieten… :wink:

BTW → SLAs im Bereich Support werden dann ausschließlich nur noch so ablaufen:

:joy:

1 „Gefällt mir“

Ich meinte damit vor allem den geschlossenen Code, der direkt im SoC läuft und dort grundlegende Sicherheitsmechanismen etabliert. Früher gab es TPM‑Module, die man deaktivieren oder zumindest extern beobachten konnte, um alternative Software zu installieren. Mit Pluton sitzt diese Funktionalität nun direkt im Chip und lässt sich nur noch nach Gutdünken des Hardwareherstellers abschalten – oder kommuniziert ausschließlich mit von Microsoft zertifizierter Software.

Wir erinnern uns: Microsoft trat mit Paladium [1] an, um das Internet sicherer zu machen – so zumindest die Marketinglinie. Dann kam TPM und das Netz und Windwos ist heute immer noch nicht besser geworden. Für viele Nutzer wirkte es eher wie ein weiterer Schritt in Richtung geschlossener Systeme. Lenovo hat bei Pluton ja gleich zu Beginn demonstriert, wie einfach sich Linux blockieren lässt, sobald das Betriebssystem nicht signiert ist.[2]

Im Mobilbereich ist das bisher weniger strikt umgesetzt, sonst wären Custom-ROMs längst unmöglich. Auch GrapheneOS interagiert letztlich nur über die von Android bereitgestellten Schnittstellen; was im Silizium selbst passiert, bleibt intransparent. Wenn Hersteller dort zusätzliche Sicherheitsmechanismen verankern, könnten alternative Betriebssysteme gezwungen sein, sich zertifizieren zu lassen – oder sie bleiben außen vor.

Bei Grafikkarten sehen wir eine ähnliche Entwicklung: Man kauft sie nicht mehr unbedingt, sondern mietet Rechenleistung über Cloud-Dienste. Das ist nicht mehr Hardware-as-a-Service, sondern im Grunde Infrastructure-as-a-Service. Wer KI nutzen will, greift entweder auf solche Cloud-Angebote zurück oder auf geschlossene Systeme wie Apples Mac Studio, Jetson Thor oder Nvidia DGX Spark. Dort ist man durch die Architektur praktisch an das vorgegebene Betriebssystem gebunden. Kombiniert man das mit HaaS‑Modellen, kann man zwar lokal KI-Modelle ausführen, aber der Anbieter bestimmt, was erlaubt ist.

Auch im Konsolenbereich ist man ohne Cloud-Dienste kaum noch handlungsfähig. Wer ein Custom-ROM nutzt, wird oft automatisch ausgeschlossen – siehe Nintendo.[3] Die Mechanismen existieren also längst. Bei Smartphones hat man sie teilweise wieder gelockert, aber wie du selbst sagst: Mit neuen Generationen könnten sie jederzeit zurückkehren oder einfach wie bei Nintendo per Softwareupdate.

Damit wäre ein System wie GrapheneOS schnell außen vor, und die Anmeldung könnte nur noch mit staatlich vorgeschriebenem Altersnachweis funktionieren. Überspitzt gesagt: Dann kann man auch gleich jedem Haushalt einen Zigarettenautomaten hinstellen, der das Alter prüft und die Information per API an alle Geräte weitergibt. Die Industrie würde sich freuen, und die Nutzer hätten „Sicherheit“, weil sie sich angeblich nie wieder um Schadsoftware sorgen müssten.

Zurück zum Thema: GrapheneOS ist letztlich vom Wohlwollen der Hersteller abhängig und kann sich einer verpflichtenden Alterskontrolle nicht entziehen. Wenn der Staat solche Vorgaben macht und Apple, Google & Co. sie umsetzen, bleiben alternative Betriebssysteme außen vor, sofern sie sich dem Diktat nicht beugen.

[1] https://www.eff.org/wp/trusted-computing-promise-and-risk#:~:text=%2D%2D%20originally%20called-,Palladium,-and%20now%20referred
[2] https://mjg59.dreamwidth.org/59931.html
[3] https://www.giga.de/artikel/nintendo-switch-homebrew-was-ihr-ueber-hacks-wissen-solltet/

Also beides MS. Derv Chip (Crypto) wurde von direkten MS-Tochterunternehmen entwickelt und in der Fertigung überwacht. Die Firmware für den Prozzi ist ebenfalls von Microsoft! Somit hat sich hinsichtlich der völligen Überwachung seitens MS der Kreis geschlossen…

Microsoft Pluton ist derzeit auf Geräten mit den folgenden Chipsätzen verfügbar, die auf Windows 11 ausgeführt werden:

  • AMD: Prozessoren der Ryzen-Serie™ 6000, 7000, 8000, 9000 und Ryzen™ KI-Serie
  • Intel®: Core™ Series Prozessoren – Ultra 200V Series, Ultra Series 3 und Series 3 Prozessoren
  • Qualcomm: Snapdragon® 8cx Gen 3- und Snapdragon-Prozessoren® der X-Serie
  • etc. pp. In diese Map lässt sich MS nur ungern reinschauen

Dabei ist die TPM - Überwachung bzw. Unterstützung nur ein kleiner Anteil, wenn man sich deren Roadmap anschaut.
Nun ja, MS hat damit zumindest zugegeben, dass TPM 2.0 nicht ausareichend dimensioniert ist bzw. alleine für kommende Aufgaben als nicht geeignet erscheint!
Microsoft Pluton kann als TPM oder mit einem TPM verwendet werden. Obwohl Pluton Sicherheit direkt in die CPU integriert, können Gerätehersteller diskretes TPM als Standard-TPM verwenden, während Pluton für das System als Sicherheitsprozessor für Anwendungsfälle außerhalb des TPM verfügbar ist.
Der Prozzi ist in das SoC-Subsystem integriert und bietet eine flexible, aktualisierbare Plattform für die Ausführung von Firmware, die End-to-End-Sicherheitsfunktionen implementiert, die von Microsoft erstellt, gewartet und aktualisiert werden.
Chip-zu-Cloud-Sicherheitstechnologie sagt man in Redmond einfallslos dazu…Zero Trust everywhere and 24 / 7 / 365!

Wie der ganze Rotz bei MS jetzt schon in der Compliance steht, war es auch nicht verwunderlich, dass mich mein Chef letztes Jahr ganz dringend zur Zertifizierung geschickt hatte, da er jemanden braucht mit höherwewrtiger ENTRA >Admin ID

Oktober / November '25 → SC-300 / T00-A
Danach brennt einem wirklich der Helm, wenn man den Ausgang im Entra Admin Center wieder findet! :smiley:

Hiier mal eine der vielen Zielsetzungen, die Pluton mit bewerkstelligen soll…

https://learn.microsoft.com/de-de/entra/identity/conditional-access/policy-all-users-device-compliance

Das Problem sind nicht die Betriebssysteme das Problem sind die staatlichen Vorgaben.
Firmen die sich im Land aufhalten müssen sich an die Gesetze halten.
Nicht jede ist dazu in der Lage sich dem territorial zu entziehen.
Um auch das zu unterbinden fordert die EU/D einen Vertreter vor Ort.

Aber Hut ab das Graphene da standhaft bleibt.

Da ich nicht tief in der Microsoft-Welt verwurzelt bin, die Hardware-Ebene aber stark davon geprägt ist, kurz zu meinem Verständnis:

Entra ID (ehemals Azure AD) übernimmt die Identitätsverwaltung, Intune die Geräte-Compliance und Pluton agiert quasi als ‚gehärtetes TPM‘ direkt im Prozessor, um Hardware-Manipulationen auszuschließen.

Wo ich früher mit einem klassischen TPM und Coreboot/Heads den Bootprozess unabhängig absichern konnte, stellt sich mir die Frage: Verliert man mit Pluton die Hoheit über diese Kette? Da Pluton tief in die Microsoft-Sicherheitsarchitektur integriert ist, scheint ein Einsatz für Projekte wie HEADS ja nur noch möglich zu sein, wenn Microsoft die entsprechenden Schnittstellen für externe Hashes öffnet, um die Hardware-Integrität zu garantieren."

Da freue ich mich ja als Open-Source Nutzer das Microsoft, so auf mein Wohl achtet.

Kurz zusammengewfasst → Im groben ->JA! Durch Qualcomm z.B. kommen wir dem Smartphone-Markt im mittleren und oberen Preisbereich schon recht nah!

Microsoft Intune und Microsoft Entra arbeiten zusammen, um Ihre Organisation über Richtlinien zur Gerätekompatibilität und bedingten Zugriff zu sichern. Gerätecompliancerichtlinien stellen sicher, dass Benutzergeräte mindestkonfigurationsanforderungen erfüllen. Die Anforderungen können durchgesetzt werden, wenn Benutzende auf Dienste zugreifen, die durch Richtlinien für bedingten Zugriff geschützt sind.

Einige Organisationen sind möglicherweise noch nicht bereit, die Einhaltung der Geräteanforderungen für alle Benutzer vorzuschreiben.

Die ersten 5 Zeilen aus meinem Link (Learn)…

Das geht ja aktuell schon soweit, dass es sich bis in die tiefsten Administrator-Zugänge ausbreitet.
Deswegen steht die neue Entra-ID / Struktur ja sogar über den Admins von Active Directories, Domänen, MASCHINEN…einfach alles! Siehe hier das Pic1

Voll administrative Berechtigungen, die bislang in AD-Netzwerken die oberste Instanz für Software & Hardware war, werden quasi von ENTRA-PRIVILEGIEN geschluckt und neu vergeben, verboten, als nichtig erklärt usw.
Anstatt die massenhaft bestehenden Microsoft AD-Netzwerke von Grund auf zu modernisieren, wird Entra als Alllzweckwaffe oben drüber gestülpt, die letzten Endes alles kontrollieren und bestimmen wird!!

https://learn.microsoft.com/de-de/entra/identity/conditional-access/policy-all-users-device-unknown-unsupported

Wenn du nur in diesem einen Link mal die Themenüberschriften liest, beantwortet sich deine Frage:

…einfach mit JA :bangbang:

#Closed Bootloader#

Und von diesen Smartphones haben wir aktuell schon massig in der freien Wildbahn! Da kann man die Hersteller anbetteln und die lassen konsequent die Dinger zu!

Das ist nicht das Problem. Graphene läuft mit closed Bootloader.
Was du vermutlich meinst, ist die immer striktere Weigerung bestimmter Apps auf Phones zu starten, deren Integrität nicht durch „offizielle“ Stellen grantiert wurde.

Ich geb mal ein paar Stichworte. Play Protect Certification / Android Compatibility Test (CTS / Play Integrity API aka SafetyNet Attestation / …
Mit dem Bootloader Status hat das nur am Rande zu tun, die können dich auch sperren wenn der locked ist.

Das habe ich ja nicht bestritten, aber darum gings mir auch nicht. Sondern um die Installation beliebiger CustomROMs als Betriebssystem! :wink:

Wenn ein Gerät nicht entsperrbar ist, dann liegt es im ermessen des Herstellers das zu ändern. Es gibt nun mal auch gute Gründe dafür, wenn er das nicht will.
Als Anwender kannst du dich frei entscheiden wo deine Prio liegt. Wünschen darfst du dir auch was, aber wie das mit Wünschen ist weißt du ja selber.

Ich hätte zB gerne ein Windows Phone mit aktuellem System, viel lieber als eins mit Android. Egal ob jetzt pure AOSP oder mit GSF. Aber wie es mit Wünschen nun mal so ist …

https://tarnkappe.info/forum/t/grapheneos-verweigert-alterskontrollen-im-betriebssystem/18802/7

Das war ja kein Wunsch in dem Sinne, sondern eine Begründung zum akt. Marktgeschehen!
:wink: