Frage an euch: Viele zögern, #GrapheneOS zu installieren, obwohl es eigentlich recht einfach ist. Wie wäre es, wenn der Kuketz-Blog eine Dienstleistung anbietet, die die Installation gegen eine Aufwandsentschädigung von etwa 50 € übernimmt? Was denkt ihr – gäbe es dafür Interesse?

#android #datenschutz #privacy #customrom

Ja
36%
Nein
32.8%
Keine Ahnung
31.1%
Poll ended at .

@kuketzblog

"Im Prinzip" würde ich so einen Service gerne nutzen, auch wenn ich's selber flashen könnte (Stress, Arbeitszeit sparen).

Dass ich nicht #GrapheneOS verwende liegt an der Zwickmühle, dass nur die Google Pixels derzeit die nötige Sicherheitshardware dafür mitbringen und ich mich nicht so recht überwinden kann, ausgerechnet diesem Konzern Geld zu geben.

@katzenberger @kuketzblog Genau das gleiche Dilemma habe ich auch..

@BafDyce @katzenberger @kuketzblog

Eben. Ein Thema bei #GrapheneOS ist die Limitierung auf #Pixel-Geräte von #Google(!).

@nick @BafDyce @katzenberger Die Unterstützung eines anderen Herstellers würde _aktuell_ zulasten der Sicherheit gehen. Das wird GrapheneOS daher erst machen, wenn ein anderer Hersteller ein vergleichbares Sicherheitsniveau bietet: https://www.kuketz-blog.de/weshalb-grapheneos-aktuell-nur-google-pixel-geraete-unterstuetzt/
Weshalb GrapheneOS aktuell nur Google Pixel-Geräte unterstützt

Für einen Artikel über GrapheneOS habe ich Daniel Micay gefragt, warum derzeit nur Google Pixel Geräte unterstützt werden. Seine Antwort…

@mynacol @BafDyce @katzenberger @nick Es wird ja nicht das Sicherheitsniveau von GrapheneOS allgemein schlechter, sondern es ist nur auf diesen Geräten schlechter als auf den Pixels. Das Sicherheitsniveau von GrapheneOS auf Pixel 8+ ist auch höher als auf Pixel 7, trotzdem wird das Pixel 7 (und mit extended support sogar runter bis Pixel 4) von GrapheneOS noch unterstützt.
@mynacol @BafDyce @katzenberger @nick Die Aussage mit der Sicherheit ist einfach vorgeschoben: Es sind deshalb die Pixels weil Google da den Großteil der gerätespezifischen Arbeit schon übernommen hat. Bei anderen Herstellern müsste man entweder viel Arbeit reinstecken oder mit dem Rest der Community zusammenarbeiten - und Kooperation mit anderen ist jetzt nicht gerade die Stärke von GrapheneOS...
@pixelschubsi @BafDyce @katzenberger @nick
Das ist schlicht falsch. Zunächst haben "Community-Lieblinge" wie Fairphone, Shift oder OnePlus immer wieder gezeigt, dass sie Verified Boot in Produktivgeräten fehlerhaft einstellen und damit ein gutes Stück der gesamten Android-Sicherheitsarchitektur kaputt machen. Diese Hersteller kann man also vorerst vergessen.

Aber mal von den Forderungen von GrapheneOS für ein neues Modell drauf geschaut ([hier nachzulesen](https://grapheneos.org/faq#future-devices)):
- Welcher Hersteller bietet monatlich 5 Jahre lang (Sicherheits-)Updates vom Verkaufsstart an? Und zwar pünktlich innerhalb Tage nach Release und zwar jeden Monat? Selbst Samsung bekommt das ja nicht hin (am Ende kommen Updates nur noch jedes halbe Jahr!). Fairphone braucht manchmal 2 Jahre nach Veröffentlichung, bis sie ein großes Android-Update (das auch Sicherheitslücken schließt) veröffentlichen. Schon bei diesem Punkt scheitert jeder andere Hersteller neben Google (inzwischen mit 7 Jahren Updatesupport). Und nein, GrapheneOS kann das nicht nachbauen, da Teil dieser Updates ja leider auch proprietäre Komponenten sowie Komponenten mit Signaturen sind.
- Es gibt sonst bisher kein anderer Hersteller, der Geräte mit Hardware Memory Tagging ausliefert. Das verhindert die Ausnutzung mancher Sicherheitslücken. Und ja, ein neues Gerät muss sich mit den Besten(=Neusten) der Pixel-Reihe messen lassen.
- Der Punkt "Weaver disk encryption key derivation throttling provided by secure element" könnte vielleicht von Samsung erfüllt werden, die fallen aber schon aus anderen Gründen raus. Dieser Punkt verhindert das Auslesen von Gerätedaten von Software wie Cellebrite oder Graykey. Hier sind Pixel-Geräte seit Längerem stärker als iPhones und andere Android-Geräte, auch wegen dem Titan 2 "Sicheren Element". Siehe https://grapheneos.social/@GrapheneOS/112826067364945164

Ich hab noch bei einer anderen Frage ähnlich ausgeholt, siehe hier: https://social.mynacol.xyz/notice/AobY6Sw4e0Camb23NY

Du siehst hoffentlich, dass all diese Punkte immer auch einen Bezug zu Hardwarefunktionen haben, die in diesem Gesamtpaket kein anderer Hersteller bereitstellt. Wenn GrapheneOS nicht groß in das Hardware-Herstellergeschäft einsteigen möchte, bleiben aktuell nur Pixel-Geräte übrig.
GrapheneOS (@[email protected])

Attached: 3 images Here's the Cellebrite Premium 7.69.5 iOS Support Matrix from July 2024. 404media recently published an article based on the same April 2024 docs we received in April and published in May. Many tech news sites including 9to5Mac made incorrect assumptions treating that as current.

GrapheneOS Mastodon
@mynacol @BafDyce @katzenberger @nick
Deine Argumente zusammengefasst:
- Ein Hersteller hat in der Vergangenheit mal Fehler gemacht, deshalb sind neue Geräte, bei denen diese Fehler nicht mehr gemacht wurden, aus Prinzip auch nicht gut.
- Sichere Software sollte es nur für die geben, die sich auch sichere Hardware leisten, obwohl das eigentlich nix miteinander zu tun hat. Andere Anforderungen als Sicherheit (z.B. Nachhaltigkeit) sind bei Hardware-Anschaffungen grundsätzlich irrelevant.
@mynacol @BafDyce @katzenberger @nick Du würdest wahrscheinlich auch unterstützen wenn Debian so wie Windows 11 aus Prinzip nur noch auf Geräten mit TPM 2.0 läuft, weil das halt sicherer ist?
@pixelschubsi @BafDyce @katzenberger @nick
Debian priorisiert Sicherheit niedriger als GrapheneOS und lässt Hardwaresicherheit (z.B. Evil Maid) fast vollständig außen vor. Entsprechend ergibt es für Debian gar keinen Sinn, ein TPM vorauszusetzen.

Was mir tatsächlich fehlt, ist ein Linux-System, das auch meinen anderen Anforderungen genügt, aber ansonsten konsequent auf Sicherheit setzt. Dieses hypothetische System könnte ein TPM voraussetzen, um damit z.B. die sichere Verwahrung von Geheimnissen zu realisieren (und ja, ein TPM kann Geheimnisse wie private Schlüssel by design sicherer verwahren als ein übliches System auf dem normalen nichtflüchtigen Speicher).
@pixelschubsi @BafDyce @katzenberger @nick

> "Deine Argumente zusammengefasst"

Nein, da waren noch ein paar andere Punkte, die ich jetzt nicht wiederhole.

> "Ein Hersteller hat in der Vergangenheit mal Fehler gemacht, deshalb sind neue Geräte, bei denen diese Fehler nicht mehr gemacht wurden, aus Prinzip auch nicht gut."

Ich habe das kaputte Verified Boot beim Fairphone 3 erwähnt, da ich mich damals etwas näher beschäftigt habe. Aber von dem was ich sonst im Internet sehe, ohne feste Zahlen parat zu haben, liefert Fairphone immer noch ziemlich verspätet (manchmal mehrere Monate) und teilweise unvollständig Sicherheitsupdates und 1-2 Jahre verspätet große Android-Upgrades. Und ja, hier ist auch entscheidend, wie schnell die Updates bei älteren, noch offiziell unterstützten Geräten ankommen.
Auch möchte ich anmerken, dass ein solch gravierendes Problem davon zeugt, dass die Firma nicht einmal ein grundsätzliches Verständnis von Androids Sicjerheitsmodell zu haben scheint. Und das aufzubauen braucht vor allem Wille und Zeit. Ich hoffe, dass Fairphone in Zukunft bei Sicherheit kompetitiv werden, aktuell sind sie aber noch weit davon entfernt.

> "Sichere Software sollte es nur für die geben, die sich auch sichere Hardware leisten, obwohl das eigentlich nix miteinander zu tun hat. Andere Anforderungen als Sicherheit (z.B. Nachhaltigkeit) sind bei Hardware-Anschaffungen grundsätzlich irrelevant."

Software-Sicherheit fußt immer auf Möglichkeiten der Hardware. Ganz grundsätzlich sind das unterschiedliche Privilegienlevel, bei x86 ist das mit ring 0 - 3 und dann noch ring -1 bis -3 gelöst, und einer MMU zur Isolation von Prozessen durch virtuelle Arbeitsspeicheradressen. Und die Fortsetzung davon sind erweiterte Hardwaremöglichkeiten wie z.B. einer IOMMU oder im Fall von Android siehe https://social.mynacol.xyz/notice/AobY6Sw4e0Camb23NY
Natürlich kann auch schlaue Software bestehende Hardwaremechanismen besser nutzen und Softwaresicherheit dadurch erhöhen. Die sicherheitsrelevanten Hardwarefunktuonen in GrapheneOS können aber nicht ohne die Hardwareunterstützung realisiert werden, ohne die Performance um ein Vielfaches zu verschlechtern.

Dass Menschen auch andere Anforderungen an Smartphones haben, verstehe und akzeptiere ich, siehe https://social.mynacol.xyz/notice/Aoc5kAclRSs83sXZZ2
Aber wir diskutieren hier über die Sicherheit von Smartphones, und da schneidet GrapheneOS ziemlich unumstritten als Gewinner ab. Um es ganz deutlich sagen: Du wirst mit einem Smartphone ohne GrapheneOS ein weniger sicheres System haben, und du wirst ohne einem Google Pixel (aber mit einem alternativen System, Stichwort Samsung) ein Smartphone mit weniger sicherheitsrelevanten Hardwarefunktuonen haben. Wenn du aufgrund anderer Präferenzen ein anderes Gerät vorziehst kannst du das gerne machen, ändert aber nichts an dem vorangegangenen Satz.
Mynacol (@[email protected])

@PC_Fluesterer @BafDyce @katzenberger @nick @kuketzblog Sicherheit misst sich nicht nur an der Menge an proprietären Komponenten, eigentlich hat das Kriterium Open Source/Proprietär gar nichts _di...

@pixelschubsi @BafDyce @katzenberger @nick
Das Ziel von GrapheneOS ist halt nicht zuvordererst, möglichst viele Geräte zu unterstützen, sondern vielmehr eine (kleine) Auswahl an Geräten zu verschiedenen Preisen zu unterstützen und dabei ein Maximum an Sicherheit bereitzustellen, während die App-Kompatibilität möglichst vollständig sichergestellt wird.

Das Argument mit den unterschiedlichen Sicherheitsniveaus von z.B. Pixel 7 zu 8 ist technisch korrekt, doch gehört es nun mal zur Verlässlichkeit von GrapheneOS, ein einmal unterstütztes Gerät während seines Supportzeitraums ebenfalls zu unterstützen. Teil der CIA in der IT-Security ist auch Availability, hier also die Verfügbarkeit von Updates für offiziell unterstützte Geräte. Ohne diese Garantie wäre GrapheneOS ja nicht Praxistauglich wenn man nicht ~jedes Jahr ein neues Handy kaufen möchte.

Und dann kommt noch der Aufwand, den jedes zusätzlich unterstütztes Modell erfordert. Daher muss sich ein neu zu unterstützendes Modell auch immer mit dem aktuellen Stand der Technik messen lassen. Siehe auch meine andere Antwort: https://social.mynacol.xyz/notice/AobxquAaDcOjQG3kDw
Mynacol (@[email protected])

@pixelschubsi @BafDyce @katzenberger @nick Das ist schlicht falsch. Zunächst haben "Community-Lieblinge" wie Fairphone, Shift oder OnePlus immer wieder gezeigt, dass sie Verified Boot in Produktiv...

@mynacol

Ich habe im Prinzip nichts gegen hohe Anforderungen, nur wenn unter dem Strich dann nur ein einziger Hersteller übrig bleibt, der das erfüllt, dann ist das zumindest für den Moment äußerst unglücklich; und wenn es Google ist, dann ein KO-Kriterium (für mich).

@BafDyce @nick @pixelschubsi

@katzenberger
Solange du die vollen Kosten dieser Entscheidung kennst, hier den Verzicht auf eine Liste an Sicherheitsmechanismen und super Datenschutz by default, akzeptiere und unterstütze ich das vollständig.