Nothing Special   »   [go: up one dir, main page]

WebAssembly

standardisiertes Bytecode-Format zur Einbindung in HTML-Umgebungen

WebAssembly (Wasm[2]) ist ein offener Standard, der vom W3C festgelegt wurde. Er definiert einen Bytecode zur Ausführung von Programmen innerhalb von Webbrowsern, kann aber auch außerhalb von diesen genutzt werden. Ziel der Entwicklung war es, leistungsstärkere Webanwendungen als bisher zu ermöglichen, sowohl was die Ladezeiten als auch die Ausführung betrifft. Das Projekt wird von allen großen Entwicklern von Browserengines, also Mozilla, Microsoft, Google und Apple, unterstützt.[3][4]

WebAssembly
Logo von Webassembly
Basisdaten
Erscheinungsjahr: 2017
Designer: World Wide Web Consortium
Entwickler: Bytecode Alliance
Aktuelle Version 2.0[1] (1. Juni 2022)
Beeinflusst von: asm.js, Google Native Client
Lizenz: Apache-Lizenz
webassembly.org

Seit März 2017 wird die Version 1 standardmäßig mit Chrome, Firefox, Edge und Webkit ausgeliefert.[5][6] Der Standard wurde am 5. Dezember 2019 offiziell festgelegt.[7][8] Weitere Funktionen wurden einzeln standardisiert und sind in Entwicklung oder in einigen Implementierungen bereits enthalten.[9] Eine Version 2 der Spezifikation liegt seit April 2022 als Entwurf vor.[10]

Bytecode Alliance

Bearbeiten

Zur Unterstützung der Entwicklung gründeten im November 2019 Mozilla, Fastly, Intel und Red Hat die Bytecode-Allianz.[11] Im April 2021 wurde diese offiziell als Non-Profit-Organisation registriert und nahm neue Mitglieder auf.[12] Im Oktober 2022 hatte sie bereits 32 Mitglieder.[13]

Entwicklung von WebAssembly-Code

Bearbeiten

Die Entwicklung von Webassembly-Code ist in einer Reihe von Programmiersprachen möglich, für weitere Sprachen gibt es Laufzeitsysteme als WebAssembly.[14]

Neben dem Bytecode (wasm) gibt es eine Textform (wat), aus der der Bytecode mit Hilfe des Kommandos wat2wasm unmittelbar erzeugt werden kann.[15]

Außerdem werden die Programmiersprachen C und C++ unterstützt.[16] Das Tool Emscripten ist hierbei in der Lage, nahezu jeden C- und C++-Quellcode in ein WebAssembly-Modul zu kompilieren. Zusätzlich wird der notwendige JavaScript-Code zum Laden und Ausführen dieses Moduls sowie ein HTML-Dokument zur Anzeige generiert.[17] Auch die Entwicklungsumgebung Unity verwendet Emscripten, um WebAssembly-Code (z. B. für Browserspiele) zu erzeugen.[18]

Auch kompilieren Rust, Go und Zig nativ nach WebAssembly.[19][20][21][22] Umfragen zufolge ist Rust die beliebteste Sprache für Wasm-Anwendungen.[23]

Beim JWebAssembly-Projekt wird Java-Bytecode nach WebAssembly übersetzt (experimentell).[24][25] Es gibt für Java jedoch auch einen proprietären Compiler namens CheerpJ.[26]

AssemblyScript ist eine Variante des JavaScript basierten TypeScript, die speziell für WebAssembly entwickelt wurde. Sie ermöglicht auch die Integration von Low-Level-Funktionen.[27]

Beim Blazor-Framework (für WebAssembly) wird ein Laufzeitsystem (IL-Interpreter) als WebAssembly geladen, sodass im Endeffekt die Programmiersprachen C# und F# im Browser genutzt werden können. Ab .NET 6 kann die Übersetzung in WebAssembly-Bytecode zum Entwicklungszeitpunkt (AOT) erfolgen, die App ist dann größer.[28]

Über das pyodide-Projekt kann Python im Browser genutzt werden (experimentell).[29]

Jetbrains hat einen Compiler für Kotlin nach WebAssembly implementiert. (experimentell).[30]

Nutzung außerhalb des Browsers

Bearbeiten

Über eine Schnittstelle namens WASI kann WebAssembly auch außerhalb von Browsern benutzt werden.[31] Hierbei startet das Kommando wasmtime eine Stand-Alone Laufzeitumgebung für WebAssembly. Die Laufzeitumgebung für WebAssembly kann außerdem in verschiedene Sprachen eingebettet werden.[32][33] Daneben gibt es auch eine Micro Runtime mit reduzierter Speichernutzung.[34] Beide stehen unter der Apache-Lizenz 2.0.

Mit Wasmer gibt es zudem eine weitere Implementierung einer Laufzeitumgebung für WebAssembly für verschiedene Nutzungsarten, die im Januar 2021 erstmalig mit einer stabilen Version erschien.[35][36][37][38] Die Implementierung steht unter der MIT-Lizenz. Wasmer Inc. ist dabei auch der Firmenname der Herausgeber. Weitere Komponenten wie ein Paketmanager (WAPM) wurden später ergänzt.[39][40] Mit WASIX wurde WASI erweitert, dies ist jedoch kein Standard.[41]

Compiler

Bearbeiten

WebAssembly-Implementierungen verwenden in der Regel entweder die AOT- oder die JIT-Kompilierung, können aber auch einen Interpreter verwenden. Während die ersten Implementierungen in Webbrowsern gelandet sind, gibt es auch Nicht-Browser-Implementierungen für allgemeine Zwecke, darunter Wasmer, Wasmtime oder WAMR, wasm3, WAVM und viele andere.

Da die ausführbaren Dateien von WebAssembly vorkompiliert sind, können sie mit einer Vielzahl von Programmiersprachen erstellt werden, entweder durch direkte Kompilierung nach Wasm oder durch Implementierung der entsprechenden virtuellen Maschinen in Wasm. Es gibt etwa 40 Programmiersprachen, die Wasm als Kompilationsziel unterstützen.

Emscripten kompiliert C und C++ nach Wasm unter Verwendung von Binaryen und LLVM als Backend. Das Emscripten SDK kann den Quellcode jeder LLVM-unterstützten Sprache (wie C, C++ oder Rust u. a.) in eine Binärdatei kompilieren, die in der gleichen Sandbox wie JavaScript-Code läuft.[Anmerkung 1] Emscripten bietet Bindungen für mehrere häufig verwendete Umgebungsschnittstellen wie WebGL.

Ab Version 8 kann ein eigenständiges Clang C und C++ zu Wasm kompilieren. Ursprünglich war es das Ziel, die Kompilierung von C und C++ zu unterstützen, aber die Unterstützung für andere Quellsprachen wie Rust, .NET-Sprachen und AssemblyScript (TypeScript-ähnlich) ist ebenfalls im Kommen.

Nach der MVP-Veröffentlichung fügte WebAssembly Unterstützung für Multithreading und Garbage Collection hinzu, was die Kompilierung für Programmiersprachen mit Garbage Collection wie C# (unterstützt über Blazor), F# (unterstützt über Bolero mit Hilfe von Blazor), Python und sogar JavaScript ermöglichte, wo die Just-in-Time-Kompilierungsgeschwindigkeit des Browsers als zu langsam angesehen wird.

Eine Reihe anderer Programmiersprachen wird in gewissem Umfang unterstützt, darunter Python, Julia und Ruby.

Eine Reihe von Systemen kann Java und andere Bytecode-Sprachen in JavaScript und WebAssembly kompilieren. Dazu gehören CheerpJ, JWebAssembly und TeaVM. Sie alle nehmen Java-Bytecode-.class-Dateien als Eingabe, sodass auch andere JVM-Sprachen wie Groovy und Scala verwendet werden können. Kotlin unterstützt WebAssembly direkt.

Beschränkungen

Bearbeiten

Im Allgemeinen erlaubt WebAssembly keine direkte Interaktion mit dem Document Object Model (DOM). Alle Interaktionen müssen über JavaScript Interop laufen. (Sicherheitsüberlegungen siehe unten)

WebAssembly wird auf Desktops und Mobiltelefonen unterstützt, aber in der Praxis (für speicherintensive Zuweisungen, wie z. B. bei der Unity-Spielengine) gibt es „schwerwiegende Einschränkungen, die es unmöglich machen, viele Anwendungen zuverlässig auf mobilen Browsern bereitzustellen [...] Derzeit ist die Zuweisung von mehr als ~300 MB Speicher in Chrome auf Android nicht zuverlässig, ohne auf Chrome-spezifische Workarounds zurückzugreifen, und auch nicht in Safari auf iOS.“

Alle großen Webbrowser erlauben WebAssembly, wenn keine Content Security Policy angegeben ist oder wenn „unsafe-eval“ verwendet wird, aber ansonsten verhalten sich die großen Webbrowser unterschiedlich. In der Praxis kann WebAssembly in Chrome ohne „unsafe-eval“ nicht verwendet werden, während ein Worker-Thread-Workaround verfügbar ist.

Sicherheitsüberlegungen

Bearbeiten

Im Juni 2018 stellte ein Sicherheitsforscher die Möglichkeit vor, dass WebAssembly verwendet werden kann, um Browser-Abschwächungen für Spectre- und Meltdown-Sicherheitslücken zu umgehen, sobald Unterstützung für Threads mit gemeinsamem Speicher hinzugefügt wird. Aufgrund dieser Bedenken legten die WebAssembly-Entwickler die Funktion auf Eis. Um jedoch diese zukünftigen Spracherweiterungen zu erforschen, fügte Google Chrome im Oktober 2018 experimentelle Unterstützung für den WebAssembly-Thread-Vorschlag hinzu.

WebAssembly wurde dafür kritisiert, dass es Schadsoftware-Autoren, Betrügern und Phishing-Angreifern leichter fällt, Beweise zu verstecken; WebAssembly ist auf dem Rechner des Nutzers nur in kompilierter Form vorhanden, was „[die] Erkennung von Schadsoftware erschwert.“ Die Geschwindigkeit und Unauffälligkeit von WebAssembly haben dazu geführt, dass es für verstecktes Krypto-Mining auf dem Gerät des Website-Besuchers verwendet wird. Coinhive, ein inzwischen eingestellter Dienst, der das Mining von Kryptowährungen in den Browsern von Website-Besuchern ermöglicht, behauptet, sein „Miner verwendet WebAssembly und läuft mit etwa 65 % der Leistung eines nativen Miners.“ Eine Studie der Technischen Universität Braunschweig vom Juni 2019 analysierte die Verwendung von WebAssembly in den Alexa-Top-1-Millionen-Websites und stellte fest, dass die vorherrschende Verwendung für böswilliges Krypto-Mining war und dass Malware mehr als die Hälfte der untersuchten WebAssembly-verwendenden Websites ausmachte.

Eine Studie der Universität Stuttgart vom April 2021 ergab, dass das Krypto-Mining seither an den Rand gedrängt wurde und auf unter 1 % aller WebAssembly-Module gefallen ist, die aus einer Vielzahl von Quellen zusammengetragen wurden, darunter auch die Alexa-Top-1-Million-Websites.

Die Fähigkeit, große Mengen an Code effektiv zu verschleiern, kann auch dazu genutzt werden, um Werbeblocker und Datenschutz-Tools zu umgehen, die das Tracking im Web verhindern, wie Privacy Badger (Zitat).

Da WebAssembly nur einen strukturierten Kontrollfluss unterstützt, eignet es sich für Sicherheitsüberprüfungsmethoden, einschließlich der symbolischen Ausführung. Zu den aktuellen Bemühungen in dieser Richtung gehört die symbolische Ausführungsmaschine Manticore.

Bearbeiten

Einzelnachweise

Bearbeiten
  1. Release 2.0. 1. Juni 2022 (abgerufen am 11. Februar 2023).
  2. WebAssembly Core Specification, Introduction. Abgerufen am 9. Juni 2022.
  3. Peter Bright: The Web is getting its bytecode: WebAssembly. In: Ars Technica. 18. Juni 2015, abgerufen am 6. Juli 2017 (englisch).
  4. Sebastian Grüner: Webassembly: Browserhersteller wollen einheitlichen Bytecode fürs Web. In: Golem.de. 18. Juni 2015, abgerufen am 6. Juli 2017.
  5. Luke Wagner (lwagner@mozilla.com): WebAssembly consensus and end of Browser Preview from Luke Wagner on 2017-02-28 (public-webassembly@w3.org from February 2017). Abgerufen am 8. Juni 2018 (englisch).
  6. Roadmap - WebAssembly. Abgerufen am 8. Juni 2018.
  7. heise online: Web-Anwendungen: WebAssembly ist nun ein fertiger W3C-Standard. Abgerufen am 30. April 2020.
  8. World Wide Web Consortium (W3C) brings a new language to the Web as WebAssembly becomes a W3C Recommendation. Abgerufen am 30. April 2020.
  9. Features to add after the MVP - WebAssembly. Abgerufen am 8. Juni 2018.
  10. WebAssembly Core Specification. Abgerufen am 22. April 2022.
  11. New Bytecode Alliance Brings the Security, Ubiquity, and Interoperability of the Web to the World of Pervasive Computing. 12. November 2019, abgerufen am 3. Juni 2021 (englisch).
  12. The Bytecode Alliance Calls for New Members In Mission to Build Safer Software Foundations for the Internet. 28. April 2021, abgerufen am 3. Juni 2021 (englisch).
  13. Bytecode Alliance. Abgerufen am 25. Oktober 2022 (englisch).
  14. appcypher: appcypher/awesome-wasm-langs. 9. Juni 2021, abgerufen am 9. Juni 2021.
  15. WABT(1). Abgerufen am 5. Juni 2021.
  16. WebAssembly High-Level Goals. In: webassembly.org. Abgerufen am 6. Juli 2017 (englisch).
  17. WebAssembly Concepts. In: developer.mozilla.org. Abgerufen am 3. März 2019 (englisch).
  18. Unity Technologies: Unity - Manual: Getting started with WebGL development. Abgerufen am 5. Juni 2021 (englisch).
  19. bors: rustbuild: Enable WebAssembly backend by default by alexcrichton – Pull Request #46115 – rust-lang/rust. In: GitHub. 25. November 2017, abgerufen am 4. Februar 2018 (englisch).
  20. Paul Krill: Direct WebAssembly compilation comes to Rust language.
  21. Go 1.11 Release Notes - The Go Programming Language. Abgerufen am 27. August 2018.
  22. Web Assembley - Zig supports building for WebAssembly out of the box. Abgerufen am 12. Februar 2023.
  23. heise online: State of WebAssembly 2021: Beliebteste Sprache für Wasm-Anwendungen ist Rust. Abgerufen am 24. Juni 2021.
  24. i-net-software/JWebAssembly. i-net /// software, 8. Juni 2021, abgerufen am 9. Juni 2021.
  25. WebAssembly für Java - eine Revolution. In: W-JAX 2021. 23. März 2020, abgerufen am 9. Juni 2021 (deutsch).
  26. Java to WebAssembly Compiler | CheerpJ. In: Leaning Technologies. Abgerufen am 9. Juni 2021 (amerikanisches Englisch).
  27. Introduction | The AssemblyScript Book. Abgerufen am 24. Juni 2021.
  28. guardrex: Hosten und Bereitstellen von ASP.NET Core Blazor WebAssembly. Abgerufen am 9. November 2021 (deutsch).
  29. pyodide. In: GitHub. 9. Juni 2021, abgerufen am 9. Juni 2021.
  30. Kotlin Wasm | Kotlin. Abgerufen am 8. Juni 2023 (amerikanisches Englisch).
  31. heise online: Mozilla startet Standardisierungsprozess für WebAssembly außerhalb des Webs. Abgerufen am 28. März 2019.
  32. bytecodealliance/wasmtime. Bytecode Alliance, 3. Juni 2021, abgerufen am 3. Juni 2021.
  33. Wasmtime Tutorial. Bytecode Alliance, abgerufen am 3. Juni 2021 (englisch).
  34. bytecodealliance/wasm-micro-runtime. Bytecode Alliance, 4. Juni 2021, abgerufen am 4. Juni 2021.
  35. Wasmer - The Universal WebAssembly Runtime. Abgerufen am 4. Juni 2021.
  36. Release 1.0.0 · wasmerio/wasmer. Abgerufen am 4. Juni 2021 (englisch).
  37. heise online: WebAssembly-Runtime: Major Release 1.0 von Wasmer erschienen. Abgerufen am 4. Juni 2021.
  38. Tom Preston-Werner: Semantic Versioning 2.0.0. Abgerufen am 16. Januar 2023.
  39. heise online: WebAssembly: Wasmer 3.0 erstellt native Executables für Windows, Linux und macOS. Abgerufen am 24. November 2022.
  40. Wasmer - The Universal WebAssembly Runtime. Abgerufen am 24. November 2022.
  41. Paul Krill: WASIX undermines WebAssembly System Interface spec, Bytecode Alliance says. 21. Juni 2023, abgerufen am 15. September 2023 (englisch).