Beiträge von alpha-nbg

Ich hatte dieses Verhalten auch seit dem Update auf 133. Ich benutze eine userChrome.css. Ich hatte dann gleich den Verdacht, dass es an einer meiner css Einstellungen liegt und habe 2 verdächtige Einstellungen auskommentiert.

#urlbar[breakout][breakout-extend] {
  /*left: 0 !important;*/
  /*width: 100% !important;*/
}

Das war wohl in früheren Versionen erforderlich, seit der Version 133 führt es dazu, dass die Adresszeile die ganze Breite des Fensters einnimmt. Jetzt passt die Breite und die Position wieder.

Oh Mann ich hatte das tatsächlich in die userchrome.css reingeschrieben

/*** Privater Modus ***/
#main-window[privatebrowsingmode=temporary] .tabbrowser-tab[selected] {
   color: black !important;
}

#main-window[privatebrowsingmode=temporary] tooltip {
   color: black !important;
}

Ich erinnere mich jetzt auch wieder, ich hatte mal vor langer zeit auf ein Theme gewechselt, wo die Schrift in den Tooltips hell auf einem hellen Hintergrund war. Und da habe ich das in der userChrome korrigiert. Jetzt habe ich ein Theme, wo die Tooltips einen dunklen Hintergrund haben und dann passt diese Einstellung natürlich nicht mehr. Da habe ich mich nicht mehr daran erinnert, ist schon zu lange her.

Also Thema erledigt, vielen Dank für die Unterstützung.

Ja, ich nutze eine userChrome.css

Hallo Andreas,

Ja, ich habe gerade festgestellt, im Fehlerbehebungsmodus taucht der Fehler nicht auf. Dann liegt es wohl an einer meiner Einstellungen.

Da werde ich mich dann mal auf die Suche machen.....

Ich habe jetzt in der Arbeit mal nachgesehen, der Fehler ist auch unter Windows11 vorhanden. Es ist also doch ein allgemeiner Fehler im Firefox und hängt nicht mit meiner Xfce Umgebung zusammen.

Es ist schon ein helles Theme (Qogir-Light) aber die Tooltips haben einen dunklen Hintergrund mit einer weißen Schrift.

Ich wusste gar nicht, dass eine Anwendung deren Aussehen beeinflussen kann. Eine Erweiterung die automatisch zwischen dark und light wechselt verwende ich nicht.
Ist eigentlich auch nicht so tragisch, es ist mir heute nur mal wieder aufgefallen, als ich ein Formular in einer Webanwendung getestet habe, wo ich Tooltips eingebaut habe.
Interessant ist, wenn ich den Privatmode auf dark lasse, werden manche Tooltips mit einem hellen Hintergrund dargestellt.

Aber möglicherweise ist das gar kein Firefox Problem, sondern taucht halt jetzt nur in meiner Umgebung auf.

Hallo,

Ich habe den privaten Modus vom Firefox auf hell gestellt.

Jetzt werden im privaten Modus manche Tooltips mit dunklem Hintergrund und weißer Schrift, manche Tooltips aber mit dunklem Hintergrund und schwarzer schrift dargestellt. Hier mal z.B. home und reload:

Auf Webseiten wird immer die dunkle Schrift angezeigt:

Weiß jemand ob sich das fixen lässt? Das Problem taucht nur im privaten Modus auf.

Gruß,
Armin

Ich habe es herausgefunden, ich muss das "@media" Element einfach nur weglassen, dann funktioniert es.

.menupopup-arrowscrollbox {
   border-radius: 0 !important;
}


menu, menuitem, menucaption {
  appearance: none !important;
  border-radius: 0 !important;
}

Funktioniert leider nicht.

Die Menüs, welche jetzt abgerundet wurden, die werden zumindest was die Farbe des ausgewählten Items angeht vom Betriebssystem gesteuert. Weil dieses Blau habe ich überall in den Menüs von meinem Xfce Desktop. Die Menüs in der Menüleiste sind also auch betroffen. Deswegen kann ich die vermutlich im Firefox nicht umstellen. Die Abrundung lässt sich aber rückgängig machen. Die Einstellung wird in der menu.css gemacht. Diese Datei finde ich aber nicht in meinem Profil. In der Toolbox lässt sich das umstellen.

Hallo,

Mit dem letzten Update ist das Kontextmenü abgerundet worden.

Das Menü selber habe ich schon wieder gerade bekommen, mit dieser Einstellung:

.menupopup-arrowscrollbox {
   border-radius: 0 !important;
}

Das ausgewählte Menüitem wird aber auch noch abgerundet dargestellt. In der Browser Toolbox konnte ich das bereits korrigieren.

@media (-moz-gtk-non-native-menus) {
  menu,
  menuitem,
  menucaption {
    appearance: none;
    border-radius: 4px;
  }
}

Wenn ich da den border-radius auf 0 setze, wird es eckig. Allerdings funktioniert das so nicht in der userChrome.css.

Wie muss ich das in die userChrome.css reinschreiben? Ich würde auch gerne noch die Farbe von dem ausgewählten Menüitem von jetzt blau auf ein grau ändern, weil es bei den anderen Menüs auch grau ist.

Gruß,

Armin

Mein letzter Beitrag war eigentlich nur zu Korrektur gedacht, weil meine Aussage dass der Dateiname random ist halt nicht zutrifft und ich wollte nicht dass da was falsches im Forum steht. Ich möchte halt bei so neuen Funktionen immer genau wissen wie es funktioniert, deshalb habe ich ja die ganzen Fragen hier gestellt, z.B. wo genau wird das Zeug konkret gespeichert usw.

Dann habe ich halt selber angefangen zu recherchieren und dachte mir, dass es möglicherweise auch für Andere interessant ist, deshalb meine vielen Beiträge zu diesem Thema. Also ich steigere mich da nicht rein, das ist einfach nur meine Neugierde und jetzt wo ich weiß wie es genau gemacht wird habe ich auch keine Bauchschmerzen damit. Es hat mich eben am Anfang wo ich noch nichts darüber wusste etwas getriggert.

Zitat

Selbst wenn ich wüsste, wie ein Hash zu einem bestimmten Dateinamen auszusehen hätte, wüsste ich ja trotzdem nicht, ob diese Datei bei dir existiert, geschweige denn könnte ich darauf zugreifen.

social engineering ?

Aber jetzt habe ich glaube ich alles zu dem Thema herausgefunden deswegen schreibe ich jetzt auch nichts mehr dazu, versprochen

Da habe ich mich doch schon wieder getäuscht. Ich habe fälschlicherweise gedacht, dass der auf der Platte gespeicherte Dateiname (dieser 52 stellige String) random erzeugt wird. Jetzt habe ich jedoch festgestellt, dass der gleiche Dateiname (z.B. evilshit.sh) auch immer den gleichen String erzeugt. Ich habe das auf mehreren VMs getestet.

Der Dateiname:

evilshit.sh

erzeugt immer diesen String:

DKUOV7VWNAKRKAPT3M6RRIASSRYNLTWZH5P72VFYVKX2O74GS7DQ

Wenn ich jetzt noch die Profilbezeichnung von jemanden kenne – und die steht ja z.B. in den abbout:support Informationen, welche häufig zu Support Zwecken auch in Foren gepostet werden – Dann kann ich den gesamten Pfad meines Payloads rekonstruieren.

Wäre interessant, wenn das mal jemand bei sich ausprobiert ob das wirklich reproduzierbar ist. Der Inhalt der Datei spielt dabei keine Rolle, nur der Dateiname ist entscheidend.

Es sieht so als wäre das einfach nur eine Hashfunktion auf den Dateiname.

Zitat

Sobald Mozilla die Mechaniken zur verschlüsselten Speicherung hat, können sie für OPFS darauf vermutlich aufbauen.

Bleibt zu hoffen, dass dies in Bälde gemacht wird, dann wäre dieses Problem gefixt. Wenn die Datei verschlüsselt abgespeichert würde, dann würde dies die Sicherheit erheblich erhöhen.

Nochmal eine kurze Ergänzung zu dem Thema.

Ich hatte jetzt noch ein wenig mehr Zeit zum Testen und habe mir einen Editor für Arme gebastelt um ein paar Tests mit OPFS zu machen.

Meine Aussage, dass mozilla die Dateien in die Sqlite Datenbank schreibt war nicht ganz richtig. Das war nur so, weil ich da nur leere Dateien erzeugt habe. Mit meinem Editor kann ich diese jetzt auch mit Text füllen und dann wird im gleichen Pfad in dem die Datenbank ist noch ein Unterverzeichnis mit einer Datei angelegt.

Der Dateiname wird random generiert und besteht aus 52 Stellen (Großbuchstaben und Zahlen). Diese Datei enthält im Klartext den exakten Inhalt, wie er von der Webanwendung geschrieben wurde. Diese Datei kann von der Webanwendung jedoch nicht ausführbar gemacht werden. In der Datenbank stehen nur die Metadaten. Nehmen wir an es würde ein Python Skript von einer Webseite abgelegt, dann könnte dieses niemals direkt von der Webanwendung ausgeführt werden. Der Besucher der Seite jedoch könnte die Datei theoretisch ausführen (was er natürlich nicht tun würde). Mit einfachen Worten, es ist kinderleicht mit Hilfe von OPFS einen payload zu platzieren, dieser kann jedoch nicht ausgeführt werden. Ein Angreifer müsste mich also durch social engineering dazu bringen, seinen payload auszuführen, was ihm aber schwer fallen dürfte, da er den Namen der Datei nicht kennt, da dieser ja random ist. Das ist meines Erachtens ausreichend sicher, jedoch wäre es noch besser, wenn die Dateien – wie ich zuerst angenommen habe – in der Datenbank wären. Jetzt liegen sie in der Tat in meinem lokalen Dateisystem.

mozilla legt im Profil unter storage/default/<domain> verschiede Unterverzeichnisse an:

ls für localstorage

idb für InexedDB

fs für OPFS

cache für Service-Worker Dateien

Damit habe ich eine gute Möglichkeit schnell herauszufinden, welche Domains die ich besucht habe Dateien via OPFS bei mir abgelegt haben:

armin@freedom:storage$ find -type d|grep "/fs"
./default/https+++v22018096896673253.goodsrv.de/fs
./default/https+++v22018096896673253.goodsrv.de/fs/UV

Sobald die Websitedaten für die entsprechende Domain gelöscht werden sind all diese Dateien weg.

Was auch noch interessant ist, im Privaten Modus wird OPFS oder IndexedDB nicht ausgeführt.

Zitat

Mal abgesehen davon, dass ich keine Tipps zur Abschaltung von Webstandards gebe, weil es keinen Vorteil hat und potentiell Probleme verursacht, auf die man später nicht kommt, ist bei Webstandards sowieso immer davon auszugehen, dass der entsprechende Schalter in about:config nur temporär existiert.

Jetzt wo ich weiß wie es im Firefox umgesetzt ist, will ich ja nicht mehr deaktivieren.
Da habe ich mich mal wieder umsonst aufgeregt

Also ich habe es jetzt durch try and error herausgefunden. OPFS speichert unter

.mozilla/firefox<profil>/storage/default

Da wird eine sqlite Datenbank angelegt. Damit macht OPFS nichts anderes als localstorage nur mit dem Unterschied, dass localstorage Strings und Integers speichert, während OPFS BLOBs speichert.

Leider hat der Firefox in den Entwicklerwerkzeugen unter Webspeicher keinen Eintrag für OPFS. Es gibt aber ein externes Tool mit dem ich die sqlite Dateien analysieren kann.

Ich habe ein einfaches Testscript geschrieben, welches ein Verzeichnis erzeugt:

Wenn ich dann die erzeugte sqlite Datenbank analysiere, ist das erzeugte Verzeichnis als BLOB sichtbar:

Da ich jetzt weiß wie es funktioniert, kann ich auch beruhigt auf die 111 updaten.

Die Aussage dass in das lokale Dateisystem geschrieben wird hat mich halt ein wenig irritiert.

Der Thread kann also als erledigt markiert werden.

Viele Grüße,
Armin

File System Access API - Web APIs | MDN

The File System Access API allows read, write and file management capabilities.

developer.mozilla.org

Zitat

Storing data in the OPFS is similar to storing data in any other browser-provided storage mechanism that's private to the origin of the page (for example the IndexedDB API). This means that files in the OPFS differ from files selected using a picker in the following ways:

Permission prompts are not required to access files in the OPFS.
Clearing data for the site deletes the OPFS.
The OPFS is subject to browser quota restrictions.

Laut dieser Aussage von mozilla, die ich gerade gefunden habe soll angeblich die gleiche Quota greifen die auch für die IndexedDB gilt, d.h. max 50% der Partition in welcher die IndexedDB gespeichert ist. Diese befindet sich unter ~/.mozilla/<profile>/storage. Ich würde aus dieser Aussage von Mozilla auch mutmaßen, dass OPFS im gleichen Pfad gespeichert wird. Genau geht das aber aus der Seite nicht hervor.

File System Standard

Zitat

In addition, it defines an API that makes it possible for websites to get access to a file system directory without having to first prompt the user for access.

Ich muss also nicht vorher um Erlaubnis gefragt werden, sondern die Webapplikation kann einfach munter darauf los schreiben.

File System Access

Zitat

Other than files in the origin private file system, files written by this API are not subject
to storage quota. As such websites can fill up a users disk without being limited by
quota, which could leave a users device in a bad state (do note that even with storage that is
subject to storage quota it is still possible to fill up, or come close to filling up, a users
disk, since storage quota in general is not dependent on the amount of available disk
space).

Es existiert also nach der Offiziellen Vorgabe keine Quota für dieses Dateisystem.

File System Standard

Zitat

The origin private file system is a storage endpoint whose identifier is "fileSystem", types are « "local" »,
and quota is null.

Das ist aber wie es aussieht kein offizielles W3 Dokument. Bei der W3 läuft das unter der Bezeichnung: File API

File API: Directories and System

Das ist aber schon ein älteres Dokument. Ich frage mich ohnehin, warum das so schlecht dokumentiert ist. Unter dem Begriff OPFS finde ich keinen englischen und auch keinen deutschen Wikipedia Eintrag, was bei offiziellen Webstandards aber eigentlich immer der Fall ist.

Die Frage ist auch wie hat mozilla dieses Dateisystem implementiert, gibt es da eine offizielle Dokumentation von mozilla wo ich das herauslesen könnte?

Bei allem was ich bisher darüber gelesen habe, möchte ich dieses feature auf jeden Fall abschalten, offizieller Webstandard hin oder her. Ich benutze keine Webapplikationen für Bild oder Textbearbeitung. Deshalb nochmal die Frage:

kann ich das im Firefox deaktivieren?

Hallo Sören,

Danke schon mal für die Info. Wie würde das dann ablaufen, wenn so eine Datei ablegt wird – Werde ich dann vom Firefox darüber informiert und muss erst zustimmen oder passiert das unbemerkt im Hintergrund? Und gibt es da eine Quota für die Sandbox oder kann die unbegrenzt groß werden? Für die IndexedDB lässt sich das ja einstellen so weit ich weiß. Es geht mir halt vor allem um die Kontrollierbarkeit, ich möchte halt zumindest feststellen können, wenn eine Webseite Dateien abgelegt hat und wie viel Platz das Ganze einnimmt, damit das nicht aus dem Ruder läuft. Und Anwendungsfälle können halt auch unterschiedlicher Natur sein. Eine attackierende Webseite ist ja – aus der Sicht des Hackers – auch ein Anwendungsfall.

Zitat

Firefox unterstützt jetzt das Origin Private File System (OPFS) der File System Access API. Diese ermöglicht Webapplikationen das Speichern und Lesen von Dateien auf dem Dateisystem des Anwenders in einer Sandbox, ohne dass die Anwendung Zugriff auf die Dateien anderer Anwendungen hat.

Hallo,

Ich möchte nicht, dass eine Webapplikation bei mir im Dateisystem Verzeichnisse und Dateien anlegen kann. Lässt sich diese Funktion abschalten?

Nach meinen Recherchen werden diese Verzeichnisse und Dateien über Javascript Funktionen angelegt. In welchem Pfad liegen diese Dateien dann und kann ich das überprüfen, bzw. Diese Dateien wieder löschen, so wie ich das jetzt schon mit Einträgen im localstorage bzw. IndexedDB machen kann? Ich würde jetzt vermuten, dass die Dateien und Verzeichnisse in meinem Profil landen also unter .mozilla... Besteht da nicht die Gefahr, dass mir jemand über seine Webapplikation mein /home Verzeichnis zu müllen kann oder gar eine Schadware dort ablegen kann? Wenn das eine Sandbox ist vermute ich, dass da wohl eine Art Image erstellt wird, wo diese Dateien und Verzeichnisse dann landen und diese zumindest nicht in meinem System ausgeführt werden können. Ich finde da leider nicht genug Informationen darüber, deshalb würde ich diese Funktion erst mal deaktivieren bevor ich mehr darüber weiß und ob sich das sicher handeln lässt.

Viele Grüße,

Armin

Hallo Sören,

Danke für die schnelle Antwort. Dann muss ich wohl damit leben. Manchmal werden Dinge halt einfach verbessert

Obwohl es für mich nicht so richtig nachvollziehbar ist. Wenn ich die Tastatur benutze, dann habe ich das Datum doch schon über die Eingabefelder eingetippt, warum sollte dann jemand mit der Tastatur noch im Kalender Picker herum Fuhrwerken wollen? Der ist ja eigentlich für die Mauseingabe oder Touch Eingabe gedacht. Für die Tastatureingabe sind doch die Eingabefelder da.