Back

@kuketzblog Kann man machen, wenn man die Firmenpolitik hinter Brave ignoriert:
https://en.wikipedia.org/wiki/Brendan_Eich (CEO von Brave)

@thoralf Im Brave-Beitrag gibt es dazu unter Ziffer 3. einen Absatz.

https://www.kuketz-blog.de/brave-und-firefox-sichere-und-datenschutzfreundliche-browser-teil-2/

@kuketzblog Wer liest das (tatsächlich)?

Die meisten Leute sehen die Empfehlung und das war's.
Muss man ja nicht gut finden, ist aber leider so.

Ich kann die Anzahl der Leute, die ein "Oops, das wusste ich ja gar nicht!" geantwortet haben, nachdem ich ihnen das gesagt habe, kaum noch zählen.

@thoralf Es ist nicht meine Schuld, wenn das nicht gelesen wird.

Lesen ist eine Grundvoraussetzung, um informiert zu sein und fundierte Entscheidungen treffen zu können.

@kuketzblog Ich fände es besser, wenn das deutlich markiert wäre, gleich oben und auch im Toot hier.

Wie gesagt: Muss man nicht gut finden, dass die Leute es nicht lesen.
Aber es ist nunmal die Realität.

@thoralf Im Beitrag geht es um Fennec und Mull. Daher sehe ich von einer Markierung ab. Letztendlich muss jeder selbst entscheiden.

@giggls @kuketzblog

Die sind Chromium-basiert, nicht Chrome-basiert. Extension-Support ist nicht eingebaut. Ich weiß von einem Browser, der das dazu patcht, aber aus anderen Gründen nicht empfehlenswert ist. Wenn dir Adblocking wichtig ist, solltest du einen verwenden der das schon eingebaut hat (z.b. Brave), oder auf DNS-Ebene blockieren.

@hweimer Wie kommst du denn zu dieser Einschätzung?

@kuketzblog Praktisch alle Browser-Bugs für remote code execution betreffen Javascript-Code (z.B. CVE-2023-37450, CVE-2023-3420, CVE-2024-3833). Selten ist wie in CVE-2023-4863 sowas wie eine Bildbibliothek betroffen.

Wenn du eine typische Webseite gehst (z.B. Zeit), dann werden da 10-20 Javascript-Elemente von externen Unternehmen nachgeladen, und das ist nur die erste Ebene. Das erhöht massiv die Angriffsoberfläche und Chrome unter Android bietet keine Möglichkeit, sich davor zu schützen.

@hweimer Daher nutzt man ja auch keinen Chrome, sondern eine andere Empfehlung hiervon: https://www.kuketz-blog.de/sichere-und-datenschutzfreundliche-browser-meine-empfehlungen-teil-1/

Das kann auch ein Brave sein.

@kuketzblog Brave unter Android unterstützt auch keine Extensions, es ist exakt dasselbe Problem wie bei Chrome.

@hweimer Die Installation von weiteren Add-ons in Brave ist sowieso nicht empfehlenswert. Stichwort Fingerprinting. Brave hat ebenfalls bereits einen Adblocker installiert: Brave Shields.

Insgesamt zählt Brave gemeinsam mit Vanadium zu den sichersten Browsern auf Android.

@kuketzblog Wenn die externen Unternehmen den Request gar nicht zu Gesicht bekommen, dann können sie auch kein Fingerprinting machen. Das ist also ein weiterer Grund, nicht von überall Javascript-Code auszuführen. Adblocker erwischen vielleicht gerade einmal die Hälfte der externen Inhalte.

Bei Brave ist zudem indiskutabel, dass es außerhalb des Play Stores keine automatischen Updates gibt.

@hweimer Korrekt. Daher empfehle ich meist Firefox (oder für Fortgeschrittene LibreWolf/Mull) in Kombination mit uBlock Origin oder Brave mit integriertem Brave Shields.

Und JavaScript heutzutage auszuschalten, ist leider wenig praktikabel.

Man kann Brave über den Aurora Store aktualisieren. Ich selbst nutze #GrapheneOS auf einem Pixel 8 ohne Play Services.

@Scorpion8741 @kuketzblog Wirklich überzeugend ist das nicht. Sandboxing gegen remote code execution hat noch nie richtig funktioniert. Ein Renderer muss z.B. in der Lage sein, auf lokale Dateien zuzugreifen (Up-/Downloads) und Netzwerkkommunikation zu betreiben (Fetch API und Co.). Das kann der kompromittierte Prozess dann auch. Wenig überraschend steht auch in der Chromium-Dokumentation an der Stelle "TODO: need to research".

Wird Zeit, dass aus @servo was wird: https://servo.org/

@hweimer @kuketzblog

Nein, die Renderer-Prozesse in Chromium haben eben keinen direkten Zugriff auf Dateien und Netzwerkkommunikation. Das ist ja gerade der Sinn einer Multi-Prozess-Architektur mit Sandboxing. Eine RCE reicht deshalb nicht, sondern es wird noch ein SBX-Escape benötigt (bei JIT sogar 2). Aber auch innerhalb des Renderers ist RCE in Chromium schwerer zu erreichen, dank CFI und anderen Mitigations, die Firefox immer noch vermissen lässt. (Renderer nach Chromium-Bezeichnung)

@Scorpion8741 @kuketzblog Also, jetzt wird es langsam ein bisschen albern. Natürlich unterstützt die Javascript-Engine von Chrome die Fetch API, mit der es möglich ist, Daten an einen externen Server zu übermitteln. Es mag sein, dass da bei Chrome noch ein weiterer Prozess zwischengeschaltet ist, aber wenn der kompromittierte Prozess diesem sagt, er solle bitte etwas an einen externen Server schicken, dann wird er dies ohne Murren tun, das ist schließlich sein Job. Geht ja gar nicht anders.

@hweimer

Albern? Sagte derjenige, der denkt, dass der Renderer-Prozess in Chromium einfach so bei einem RCE, ohne zusätzlichen SBX-Escape, Zugriff auf lokale Nutzerdateien hat? Sorry, aber das ist Browser-Wissen von vor 10 Jahren.

Und bitte mein "direkt" im vorigen Kommentar nicht überlesen. Interaktion mit dem Netzwerk geht nur indirekt über IPC mit dem Browser-Prozess. Dadurch können Sicherheitsmechanismen wie SOP, CORS, CSP und Site Isolation eingehalten werden.

@kuketzblog

@Scorpion8741 @hweimer Ich würde mich freuen, wenn die Diskussion sachlich bleibt.

@kuketzblog

Ja, das würde mich auch freuen. Aber wenn eigentlich korrekte Kommentare von fachfremden Personen als "albern" bezeichnet werden, und das Ganze noch Meinungsstark mit Browserwissen aus der Steinzeit garniert wird, darf man auch einmal ein wenig Gegenwind entgegensetzen. Ansonsten verbreitet sich Falschinformation immer weiter.

@hweimer

@hweimer @kuketzblog

Ich sehe schon, das wird nichts. Keine technischen Argumente, gravierende Fehlverständnisse über moderne Browserarchitektur, aber Behauptungen wie "Sandboxing funktioniert nicht" und "Daten über reguläre APIs abfließen" aufstellen. Ich bin dann mal raus.