Henry: Neues Firefox Update javascript

Hallo,

beim letzten Update 108.0 schreibt FF:

"Import maps, which allow web pages to control the behavior of JavaScript imports, are now enabled by default."

Was ist das genau (simples Beispiel), bzw sollte man das wirklich als Default akzeptieren, oder falls nicht wo lässt sich das abstellen?

Gruss
Henry

--
Meine Meinung zu DSGVO & Co:
„Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“
  1. Hallo,

    "Import maps, which allow web pages to control the behavior of JavaScript imports, are now enabled by default."

    Was ist das genau (simples Beispiel), bzw sollte man das wirklich als Default akzeptieren, oder falls nicht wo lässt sich das abstellen?

    Beantworten kann ich dir das nicht. Aber vielleicht die Spec?

    Gruß
    Kalk

    1. Hallo Tabellenkalk,

      Beantworten kann ich dir das nicht. Aber vielleicht die Spec?

      Ja danke, ähnliches hatte ich mir schon angeschaut, es bleibt die Frage ob das eine Gefahrenquelle darstellt, weil soweit ich das verstehe das einhergeht mit der perönlichen Kontrolle der Quellverweise. Andererseits, ist das ja bei üblichen Scripten auch nicht wirklich kontrollierbar mit der Ausnahme der "Same-Origin-Policy" Daher die Frage, ob diese dadurch u.U. ausgehebelt werden kann?

      Gruss
      Henry

      --
      Meine Meinung zu DSGVO & Co:
      „Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“
      1. Hallo,

        Beantworten kann ich dir das nicht. Aber vielleicht die Spec?

        Andererseits, ist das ja bei üblichen Scripten auch nicht wirklich kontrollierbar mit der Ausnahme der "Same-Origin-Policy" Daher die Frage, ob diese dadurch u.U. ausgehebelt werden kann?

        ich bin mir nicht sicher, ob ich die Sache verstanden habe, aber mein Eindruck ist, dass du da etwas durcheinanderbringst.

        Die Same Origin Policy regelt, auf welche Daten ein Script aktiv zugreifen darf, wenn es mal läuft. Die Import Maps verstehe ich eher als Wegweiser, woher das Script selber geladen werden soll.

        Der Sinn erschließt sich mir aber noch nicht, denn dazu dient doch eigentlich das src-Attribut des script-Elements.

        Einen schönen Tag noch
         Martin

        --
        Wie man sich bettet, so schallt es heraus.
        1. Hello,

          Beantworten kann ich dir das nicht. Aber vielleicht die Spec?

          Andererseits, ist das ja bei üblichen Scripten auch nicht wirklich kontrollierbar mit der Ausnahme der "Same-Origin-Policy" Daher die Frage, ob diese dadurch u.U. ausgehebelt werden kann?

          ich bin mir nicht sicher, ob ich die Sache verstanden habe, aber mein Eindruck ist, dass du da etwas durcheinanderbringst.

          Die Same Origin Policy regelt, auf welche Daten ein Script aktiv zugreifen darf, wenn es mal läuft. Die Import Maps verstehe ich eher als Wegweiser, woher das Script selber geladen werden soll.

          Der Sinn erschließt sich mir aber noch nicht, denn dazu dient doch eigentlich das src-Attribut des script-Elements.

          Ich verstehe das so, dass dadurch aus einem direkten Verweis (Link) ein indirekter Verweis wird. Damit lassen sich Quelle und Ziel dynamiach entkoppeln.

          Oder bin ich da jetzt auf dem Holzweg?

          Glück Auf
          Tom vom Berg

          --
          Es gibt soviel Sonne, nutzen wir sie.
          www.Solar-Harz.de
          S☼nnige Grüße aus dem Oberharz
        2. Hallo Der,

          Der Sinn erschließt sich mir aber noch nicht, denn dazu dient doch eigentlich das src-Attribut des script-Elements.

          Nicht nur, es auch um import-Statements in ES6-Modulen. Die müssen das zu importierende Script eindeutig adressieren, so wie auch Bilder oder Stylesheets. Entweder mit absolutem oder mit relativem Pfad.

          import someFunc from "https://cdn.example.org/libs/demolib/v4/functions.js";
          import otherFunc from "./modules/foo.js";
          

          Der erste Import zeigt eins der Probleme: Was ist, wenn Du auf demolib V5 umsteigst? Dann musst Du alle imports ändern, die darauf verweisen. Und eigentlich ist es ja auch Käse, den kompletten Pfad im Sourcecode zu haben und nicht nur einen symbolischen Namen.

          Module-Loader wie require.js oder CommonJS (in Node.js) bieten da eine Modul-Registry, mit der Du symbolische Namen festlegst und in den Modulen nicht wissen musst, wo die importierten Module liegen.

          Und genau das wird mit import maps nachgebildet.

          import someFunc from "demolib/functions";
          import otherFunc from "foo";
          

          liest sich doch viel besser, oder?

          Möglich wird das durch diesen Script-Block im HTML Dokument (den man bei Verwendung von PHP includen kann):

          <script type="importmap">
          {
            "imports": {
              "demolib/functions": "https://cdn.example.org/libs/demolib/v4/functions.js",
              "foo": "./modules/foo.js"
            }
          }
          </script>
          

          Da steckt noch eine ganze Menge mehr hinter, ich hab nur keine Zeit dazu einen Wikiartikel zu schreiben.

          Zum Einlesen

          Rolf

          --
          sumpsi - posui - obstruxi
      2. ob das eine Gefahrenquelle darstellt, weil soweit ich das verstehe das einhergeht mit der perönlichen Kontrolle der Quellverweise.

        Was meinst du mit "persönlicher Kontrolle der Quellverweise"?

        Die Zuweisungstabelle kann nur innerhalb des HTML-Dokuments mit einem <script type="importmap" src="bla"> eingebunden werden. Das Gefahrenpotential ist mithin genauso groß wie bei jeder anderen dort per <script> eingebundenen Datei.

        Um auf deine Ursprungsfrage zurückzukommen, Zweck der Aktion ist zweierlei:

        Der Lagerort der einzubindenden Module kann geändert werden, ohne den die Module importierenden Code ändern zu müssen.
        Du schreibst im Code nur import "Beispielmodul" und verbindest "Beispielmodul" mittels importmap mit der tatsächlichen URL "/Beispiel_Version_123.js". Lädst du später Beispiel_Version_124.js hoch, muss nur der importmap-Eintrag geändert werden, aber nicht import "Beispielmodul" im Code.
        Ähnlich einfach kann das Wechseln von lokalen Dateien auf eine Webserver-URL oder ein anderes CDN vonstatten gehen.

        Zweitens kann die Funktionalität des Codes abhängig von der ladenden Webseite geändert werden, ebenfalls wiederum ohne den die Module importierenden Code ändern zu müssen.
        Zum Beispiel könnte eine Funktion, die Längenwerte in einen Text umsetzt, über import "ausgabe" eingebunden werden und mittels importmap-Eintrag wird das Modul "ausgabe" an die Datei "/zollundmeilen.js" für US-Besucher oder "/ausgabe/metrisch.js" für normale Menschen gebunden.

      3. Hallo Henry,

        danke, dass Du unsere Aufmerksamkeit auf dieses Thema lenkst. Das schreit nach einem Blog- oder Wiki-Artikel.

        Die Import-Map muss bei dir im HTML Source stehen. Du kontrollierst sie also selbst.

        Es gibt aber auch die Möglichkeit, das Script-Element mit der importMap darin dynamisch anzulegen, und dann könnte man meinen, dass ein böses Script mit einer Map dafür sorgt, dass Module auf einmal von ganz wo anders geladen werden.

        Aber: Ohne Import-Maps musst Du in import-Statements immer den Modulnamen mit einem Schema, einem / oder einem . beginnen lassen.

           import func from "mymodule.js"
        

        geht meines Wissens ohne eine Import Map nicht. Wenn deine Seite also ECMAScript-Module verwendet und nicht auf Import Maps ausgelegt ist, dann bewirkt eine Import Map gar nichts. Denn Modulnamen mit einem absoluten oder relativen Pfad (also . oder / am Anfang) kann man nicht mappen, wenn ich das richtig verstehe.

        Und eine Import Map ist ein Highlander - es kann nur eine geben. Ist schon eine da, nützt das Hinzufügen einer weiteren Import Map nichts.

        Ob man per Script die alte Importmap löschen und eine neue setzen kann, das habe ich nicht ausprobiert. Es gibt also durchaus Forschungspotenzial für Sicherheitslücken. Magst Du dafür Zeit investieren?

        Rolf

        --
        sumpsi - posui - obstruxi
        1. Hallo Rolf,

          Ob man per Script die alte Importmap löschen und eine neue setzen kann, das habe ich nicht ausprobiert. Es gibt also durchaus Forschungspotenzial für Sicherheitslücken. Magst Du dafür Zeit investieren?

          Danke für dein Vertrauen in meine Fähigkeiten/Möglichkeiten.

          Doch leider ist es damit nicht mehr weit her. IT-Potential ist, zumindest für mich, schlimmer als Klavierspielen. Weil nicht nur mangelnde Übung sich sehr schnell auswirkt in Form von Vergesslichkeit und obendrein sogar ständig neue Techniken/Entwicklungen zeigen mit denen man Schritt halten müsste. Andererseits, wenn ich mich dann mal wieder aufraffe und ein paar Monate am Ball bleibe(wofür ich aktuelle gar keine Zeit und Motivation habe) bin ich dann aber wieder erstaunt was doch noch so versteckt im Hirn schlummert.

          Also kurz gesagt, aktuell bin ich nicht dafür geeignet.

          Gruss
          Henry

          --
          Meine Meinung zu DSGVO & Co:
          „Principiis obsta. Sero medicina parata, cum mala per longas convaluere moras.“