Downloadfenster anpassen

"Enterprise Policy Generator" kann das festlegen und sperren. So und ähnlich könnte ich mir das vorstellen:

Zitat

Microsoft Windows:

erstellen Sie ein Verzeichnis mit dem Namen „distribution“ in dem Verzeichnis, in welchem sich die Datei firefox.exe befindet und platzieren Sie die Datei „policies.json“ dort.

Apple macOS:

erstellen Sie ein Verzeichnis mit dem Namen „distribution“ in http://Firefox.app/Contents/Resources/ und platzieren Sie die Datei „policies.json“ dort.

Linux:

erstellen Sie ein Verzeichnis mit dem Namen „distribution“ in dem Verzeichnis, in welchem sich Firefox befindet und platzieren Sie die Datei „policies.json“ dort.

Alles anzeigen

{
  "policies": {
    "BlockAboutAddons": true,
    "BlockAboutConfig": true,
    "BlockAboutProfiles": true,
    "BlockAboutSupport": true,
    "DefaultDownloadDirectory": "\\\\server\\share",
    "DisableDeveloperTools": true,
    "DisableFirefoxStudies": true,
    "DisableProfileImport": true,
    "DisableProfileRefresh": true,
    "DisableSafeMode": true,
    "DisableSecurityBypass": {
      "InvalidCertificate": true,
      "SafeBrowsing": true
    },
    "DisableTelemetry": true,
    "DownloadDirectory": "\\\\server\\share",
    "Preferences": {
      "security.ssl.errorReporting.enabled": false
    },
    "SearchEngines": {
      "PreventInstalls": true
    }
  }
}

Telemetrie, Studies als auch TLS-Fehler werden nicht zurückgemeldet, kann u.U. mit dem Datenschutz eures Systems kollidieren.

Wenn eh ein fertiges Profil als Grundlage erstellt wird, kann man es so anpassen, dass da, was man will, oder nicht will, bereits eingestellt ist, und dann verhindert man, dass Benutzer es verändert.

Zur Klarstellung: Der Enterprise Policy Generator kann eine Richtlinie für das Downloadverzeichnis bereitstellen. Der Großteil dessen, was hier angefragt wurde, ist damit nicht möglich. DefaultDownloadDirectory und DownloadDirectory braucht man jedenfalls nicht beide. Es sollte nur das eine oder das andere genutzt werden.

Sachen wie die Abschaltung von Telemetrie oder security.ssl.errorReporting.enabled auf false sollten nur gemacht werden, wenn es dafür einen sehr guten Grund gibt, in der Regel also eine entsprechende Unternehmenspolitik. Ich verstehe allerdings nicht, was das in diesem Thread zu suchen hat, da das ja mit den Downloads überhaupt nichts zu tun hat.

Zitat von Sören Hentzschel

in der Regel also eine entsprechende Unternehmenspolitik.

Hatte ich oben zwar anders geschrieben, aber genau das gemeint. Es gibt Dinge, die gehen Mozilla nichts an, so nett ich den Verein auch finde. Warum? Weil's passte und den Blickwinkel gleichzeitig zur Thematik erweitert. Ich denke jedoch, dass es mehr oder weniger schon gewusst wurde, aber schaden kann es doch nicht?

Was noch?

Downloadfenster anpassen

Das ist für mich nicht richtig formuliert, weil Benutzer ja weder das Fenster sehen soll noch was an den Downloads ändern soll:

Zitat

Weiters vergeben wir innerhalb des dann zu verwendenden Profils den Downloadpfad fest, der User soll den nicht ändern können. Was noch viel wichtiger ist, der User soll nicht sehen wohin der Download erfolgt ist. Zusätzlich sollte auch der Dialog via STRG + J nicht aufpoppen, oder leer bleiben. Am liebsten ist uns, wenn das Icon nicht sichtbar ist und auch nicht aktiviert werden kann.

Dialog ist eines, Strg+J ist Downloads in der Bibliothek, das sind zweierlei.

Wenn man Firefox per policies mitteilen kann, dass Benutzer nichts an der Oberfläche ändern darf, ist die Sache mit den Download-Popup doch schon abgefrühstückt, bliebe noch die Bibliothek, ob die ohne die Downloads sichtbar sein soll oder nicht. Bei CSS sehe ich die Gefahr, dass Benutzer den Schalter für userChrome/userContent in den prefs - falls nicht gesperrt, abschaltet und Firefox ganz einfach neu startet. Die policies können das verhindern.

Das Blockieren diverser about Seiten tönt ins gleiche Horn - mittels about:support könnte ein Benutzer feststellen, was alles eingestellt wurde. Ausserdem sind dort weitere about-Seiten hinterlegt, zusätzlich eine Möglichkeit, den Inhalt einer user.js einzusehen. Das hat den alles nicht zu interessieren, wie Firefox vorkonfiguriert wurde. Es gibt immer mindestens einen Nutzer, der das alles kennt und weiss, wie er es aushebeln könnte, obwohl er seinen Arbeitsplatz damit riskiert - muss man nicht provozieren.

Das mit der Bib habe ich gestern nicht mehr auf die Schnelle gefunden. Dazu müsste ich die ADM genauer einsehen, im Generator las ich dazu nichts.

Man kommt ja über diverse Wege an die Bib, sei es Menü, Tastenkombi, Anwendungmenü (Hamburger).

Die Tastenkombi dürfte wohl der Knackpunkt sein, wobei man sowas mit Userscript abfangen kann.

Der Aufwand ist erstmal höher, aber langfrstig stabil bei Esr.

Zitat von .DeJaVu

Es gibt Dinge, die gehen Mozilla nichts an, so nett ich den Verein auch finde. Warum? Weil's passte und den Blickwinkel gleichzeitig zur Thematik erweitert. Ich denke jedoch, dass es mehr oder weniger schon gewusst wurde, aber schaden kann es doch nicht?

Wie gesagt, das ist eine komplett eigene Thematik und hat mit dem Thema hier gar nichts zu tun. Und eben weil das keine Einstellungen sind, die jemand leichtfertig verändern sollte, finde es nicht gut, solche Ratschläge ungefragt in den Raum zu werfen. Wie sehr das nun schadet, ist sicher relativ, aber Tatsache ist dann eben doch, dass solche Feedback-Mechanismen, deren Abschaltung du vorgeschlagen hast, in erster Linie einem selbst zu Gute kommen. Die Formulierung "gehen Mozilla nichts an, so nett ich den Verein auch finde" zeigt leider ein in meinen Augen bereits fehlerhaftes Grundverständnis. Mozilla hat überhaupt kein höheres Interesse an solchen Daten. Am Ende des Tages ist es der Endanwender, der keine Probleme haben möchte. Und gerade im Unternehmensumfeld, wo vor allem Server-, Netzwerk- und Sicherheits-Konfigurationen gerne mal spezieller sind, wäre es halt schon besonders relevant, Mozilla Probleme beim Verbindungsaufbau mitzuteilen. Leider gibt es Firmenpolitiken, die explizit jegliche Kommunikation nach außen untersagen. Das muss dann auch berücksichtigt werden. Aber gibt es eine solche Politik nicht, kann ich nur eine etwas rationalere Betrachtungsweise ans Herz legen.

Einen solchen Hinweis gibt es aus dem ganz einfachen Grund nicht, dass der Anwender die JSON-Ausgabe nicht selbst weiter verarbeiten muss und dementsprechend keine Kenntnisse über die JSON-Syntax erforderlich sind. Als Anwender kann man darauf vertrauen, dass der Enterprise Policy Generator ein valides Ergebnis ausliefert.

Glücklicherweise hat das nichts mit einer persönlichen Sichtweise zu tun. JSON ist sehr strikt, da gibt es nur eine korrekte Schreibweise. Ein Backslash muss zwingend doppelt stehen. Bei nur einem Backslash würde ein Syntax-Fehler vorliegen und die Datei könnte von Firefox dementsprechend auch nicht verarbeitet werden. Wie gesagt: Als Anwender kann man sich darauf verlassen, dass der Enterprise Policy Generator eine valide JSON-Ausgabe erzeugt. Was der Enterprise Policy Generator erzeugt, wird niemals in einem Syntax-Fehler resultieren, das ist technisch durch meine Implementierung ausgeschlossen.

hmm, bei allem Beispielen mit Variablen und JSON steht es noch anders

@{HOME}/dir

zB

Visual Studio Code Variables Reference

Visual Studio Code variable substitution reference

code.visualstudio.com

Oder gilt das nur für URI?

Ein Slash (/) ist etwas anderes als ein Backslash (\). Unter macOS und Linux verwendet man einen Slash in Pfadangaben, unter Windows einen Backslash. Und ein Backslash muss in JSON im Gegensatz zu einem Slash maskiert werden, weil der Backslash in JSON eine Escape-Sequenz ist. Das heißt, erst durch den zweiten Backslash wird wirklich der Backslash als Zeichen erkannt und nur ein einzelner Backslash, auf den ein unzulässiges Zeichen folgt, führt zu einem Syntax-Fehler. Als Anwender ist dieses Wissen aber wie gesagt vollkommen unerheblich, weil der Enterprise Policy Generator technisch überhaupt kein invalides JSON erzeugen kann, nicht einmal versehentlich. Das erlaubt meine Implementierung nicht.

Was ich nicht verstehe ist:

Zitat von Sören Hentzschel

JSON ist sehr strikt, da gibt es nur eine korrekte Schreibweise. Ein Backslash muss zwingend doppelt stehen. Bei nur einem Backslash würde ein Syntax-Fehler vorliegen und die Datei könnte von Firefox dementsprechend auch nicht verarbeitet werden.

Auch ein String mit nur einem Backslash, unabhängig davon, ob damit irgendwas escaped wird oder nicht, wird innerhalb einer JSON-Datei als valide interpretiert:

Free Online JSON Validator - FreeFormatter.com

Dann lass den Pfad mal mit einem Backslash enden und du siehst auch mit dem verlinkten Validator das Problem. Wie ich es in meinem letzten Beitrag ja auch schrieb: ein einzelner Backslash, auf den ein unzulässiges Zeichen folgt, führt zu einem Syntax-Fehler. Ich habe hier ein entscheidendes Wort fett markiert. Unter Beachtung der ganz einfachen Grundregel, dass man Zeichen, welche eine Escape-Sequenz darstellen, immer maskiert, sind dadurch verursachte Syntax-Fehler ausgeschlossen. Oder anders formuliert, um den Kreis zu meinem vorherigen Beitrag zu schließen: Man muss zwingend immer zwei Backslashes verwenden, um diese Kategorie von Fehler garantiert ausschließen zu können. Andernfalls erfordert man vom Anwender Kenntnis über die Regeln des JSON-Formats. Und genau die soll man als Anwender des Enterprise Policy Generators ja eben nicht benötigen.

Worum es hier ja ursprünglich ging, war die Aussage des Themenerstellers, die Ausgabe des Enterprise Policy Generators wäre falsch und es sollte für den Anwender etwas dokumentiert werden. Aber die JSON-Ausgabe ist nicht falsch, ganz im Gegenteil. Ich lasse Firefox selbst das JSON aus den Daten generieren. Wäre das JSON falsch, wäre Firefox fehlerhaft. Und die Notwendigkeit zur Dokumentation besteht nicht, weil eben dadurch, dass Backslashes konsequent maskiert werden, der Anwender durch seine Eingaben keinen Syntax-Fehler verursachen kann - eben weil doppelte Backslashes verwendet werden.

Ok, das mit dem unzulässigen Zeichen habe ich jetzt verstanden! Naja fast: In dem Beispiel mit dem Backslash als letztem Zeichen müsste der Parser doch eigentlich erkennen, dass nicht das abschließende Anführungszeichen maskiert werden soll, da ja ein öffnendes Anführungszeichen schon vorhanden ist und eine Maskierung doch nur innerhalb des Strings Auswirkungen haben sollte .

Gut, ich kenne jetzt nicht die genaue Spezifikation, von daher wird das dann wohl schon seine Richtigkeit haben...

Ein JSON-Parser könnte eine automatische Fehlerkorrektur implementieren, unabhängig davon, dass es nicht Teil der Spezifikation ist. Von der Idee bin ich aber ehrlich gesagt überhaupt kein Freund. Man führt dafür eine zusätzliche Komplexität ein. Selbst wenn die Logik perfekt implementiert wird und keine Fehler in irgendwelchen Grenzfällen verursacht, wirkt sich die zusätzliche Logik auf jeden Fall negativ auf die Performance aus, was ja gar nicht notwendig ist, wenn man davon ausgehen kann, dass die Daten in jedem Fall korrekt ankommen. Außerdem bleibt das JSON am Ende ja trotzdem falsch und wenn man das JSON an anderer Stelle weiterverarbeiten möchte, müsste dort ja wieder eine Fehlerkorrektur implementiert sein, was gerade für JSON als einem der wichtigsten Datenaustauschformate der heutigen Zeit problemtisch wäre. Als Entwickler bevorzuge ich strikte Strukturen jedenfalls immer ganz klar gegenüber besonders fehlerverzeihenden Strukturen. HTML nenne ich da als ganz großes Negativ-Beispiel aus meiner Sicht. HTML mit all den möglichen Fehlern zu parsen, die der Browser aber verzeiht, ist ein ganz großer K(r)ampf. Das merken derzeit auch die Entwickler des Bergamot-Übersetzers.