# WebAssembly

WebAssembly (soms afgekort tot Wasm, niet te verwarren met de Open Watcom Assembler) definieert een draagbaar binair codeformaat en een overeenkomstig tekstformaat voor uitvoerbare programma's, evenals software-interfaces om interacties tussen dergelijke programma's en hun hostomgeving te vergemakkelijken.
Het belangrijkste doel van WebAssembly is krachtige toepassingen op webpagina's mogelijk te maken, "maar het maakt geen webspecifieke aannames of biedt geen webspecifieke functies, dus het kan ook in andere omgevingen worden gebruikt." Het is een open standaard en heeft tot doel elke taal op elk besturingssysteem te ondersteunen, en in de praktijk hebben alle populaire talen al op zijn minst een bepaald niveau van ondersteuning.
WebAssembly werd aangekondigd in 2015 en voor het eerst uitgebracht in maart 2017. Op 5 december 2019 werd het een aanbeveling van het World Wide Web Consortium en in 2021 ontving het de Programming Languages Software Award van ACM SIGPLAN. Het World Wide Web Consortium (W3C) handhaaft de standaard met bijdragen van Mozilla, Microsoft, Google, Apple, Fastly, Intel en Red Hat.

## Geschiedenis

WebAssembly is vernoemd naar het concept van assembleertaal, een term die dateert uit de jaren 1950. De naam suggereert om assembler-achtige programmering naar het web te brengen, waar het aan de clientzijde zal worden uitgevoerd — door de computer van de websitegebruiker via de webbrowser van de gebruiker. Om dit te bereiken, moet WebAssembly veel meer hardware-onafhankelijk zijn dan een echte assembleertaal.
WebAssembly werd voor het eerst aangekondigd in 2015 en de eerste demonstratie was het uitvoeren van Unity's Angry Bots in Firefox, Google Chrome, en Microsoft Edge. De voorlopertechnologieën waren asm.js van Mozilla en Google Native Client, en de initiële implementatie was gebaseerd op de functieset van asm.js. De asm.js-technologie biedt al near-native code-uitvoeringssnelheden en kan worden beschouwd als een levensvatbaar alternatief voor browsers die WebAssembly niet ondersteunen of om veiligheidsredenen hebben uitgeschakeld.
In maart 2017 werd het ontwerp van het minimaal levensvatbare product (MVP) als voltooid verklaard en eindigde de preview-fase. Eind september 2017 is Safari 11 uitgebracht met ondersteuning. In februari 2018 publiceerde de WebAssembly Working Group drie openbare werkconcepten voor de kernspecificatie, de JavaScript-interface en de web-API.
In juni 2019 werd Chrome 75 uitgebracht met standaard ingeschakelde WebAssembly-threads.
Sinds april 2022 bevindt WebAssembly 2.0 zich in de conceptstatus, wat veel SIMD-gerelateerde instructies en een nieuw v128-datatype toevoegt, de mogelijkheid voor functies om meerdere waarden te retourneren en het initialiseren/kopiëren van het massageheugen.

## Implementaties

Hoewel WebAssembly oorspronkelijk was ontworpen om near-native code-uitvoeringssnelheid in de webbrowser mogelijk te maken, wordt het ook daarbuiten als waardevol beschouwd, in meer algemene contexten. Omdat de runtime-omgevingen (RE) van WebAssembly low-level virtuele stackmachines zijn (vergelijkbaar met JVM of Flash VM) die kunnen worden ingebed in hosttoepassingen, hebben sommigen van hen een manier gevonden om op zichzelf staande runtime-omgevingen zoals Wasmtime en Wasmer te gebruiken.

### Webbrowsers

In november 2017 kondigde Mozilla ondersteuning aan "in alle grote browsers", nadat WebAssembly standaard was ingeschakeld in Edge 16. De ondersteuning omvat mobiele webbrowsers voor iOS en Android. Sinds oktober 2022 ondersteunt 96% van de geïnstalleerde browsers WebAssembly (versie 1.0). Maar voor oudere browsers kan Wasm worden gecompileerd in asm.js door een JavaScript-polyfill.

## Compilers

WebAssembly-implementaties gebruiken meestal AOT-compilatie (ahead-of-time) of JIT-compilatie (just-in-time), maar kunnen ook een interpreter gebruiken. Hoewel de eerste implementaties in webbrowsers zijn beland, zijn er ook niet-browserimplementaties voor algemeen gebruik, waaronder Wasmer, Wasmtime of WAMR, wasm3, WAVM en vele anderen.
Omdat de uitvoerbare bestanden van WebAssembly voorgecompileerd zijn, is het mogelijk verschillende programmeertalen te gebruiken. Dit wordt bereikt door directe compilatie naar Wasm of door implementatie van de overeenkomstige virtuele machines in Wasm. Er zijn ongeveer 40 programmeertalen gerapporteerd die Wasm ondersteunen als een compilatiedoel.

## Beperkingen

* Over het algemeen staat WebAssembly geen directe interactie met de DOM toe. Alle interactie moet via JavaScript-interoperabiliteit verlopen.
* Afwezigheid van garbage collection (hoewel er plannen zijn om dit aan te pakken).
* Beveiligingsoverwegingen (hieronder besproken).
WebAssembly wordt ondersteund op desktops en mobiel, maar op de laatste zijn er in de praktijk (voor niet-kleine geheugentoewijzingen, zoals bij de Unity-game-engine) "ernstige beperkingen die het voor veel applicaties onmogelijk maken om betrouwbaar te worden ingezet op mobiele browsers […] Momenteel is het niet betrouwbaar om meer dan ~300 MB geheugen toe te wijzen in Chrome op Android zonder toevlucht te nemen tot Chrome-specifieke tijdelijke oplossingen, en ook niet in Safari op iOS."
Er is geen directe toegang tot het Document Object Model (DOM); het is echter mogelijk om hiervoor proxyfuncties aan te maken, bijvoorbeeld via stdweb of web_sys bij gebruik van de Rust-taal.
Alle grote webbrowsers staan WebAssembly toe als Content-Security-Policy niet is gespecificeerd, of als "unsafe-eval" wordt gebruikt, maar verder gedragen de grote webbrowsers zich anders. In de praktijk kan WebAssembly niet worden gebruikt in Chrome zonder "unsafe-eval", terwijl er een werkthread-oplossing beschikbaar is.

## Beveiligingsoverwegingen

In juni 2018 presenteerde een beveiligingsonderzoeker de mogelijkheid om WebAssembly te gebruiken om browserbeperkingen voor Spectre- en Meltdown-beveiligingskwetsbaarheden te omzeilen zodra ondersteuning voor threads met gedeeld geheugen is toegevoegd. Vanwege deze bezorgdheid hebben WebAssembly-ontwikkelaars de functie in de wacht gezet. Om deze toekomstige taalextensies te verkennen, heeft Google Chrome echter in oktober 2018 experimentele ondersteuning toegevoegd voor het voorstel voor de WebAssembly-thread.
WebAssembly is bekritiseerd omdat het het gemakkelijker maakt om het bewijs te verbergen voor malwareschrijvers, oplichters en phishing-aanvallers; WebAssembly is alleen aanwezig op de computer van de gebruiker in gecompileerde vorm, wat "detectie van malware bemoeilijkt". De snelheid en verbergbaarheid van WebAssembly hebben geleid tot het gebruik ervan bij verborgen cryptomining op het apparaat van de websitebezoeker. Coinhive, een inmiddels ter ziele gegane dienst die cryptocurrency-mining in de browsers van websitebezoekers mogelijk maakt, beweert dat hun "miner WebAssembly gebruikt en met ongeveer 65% van de prestaties van een native miner werkt." Een studie uit juni 2019 van de Technische Universiteit Braunschweig analyseerde het gebruik van WebAssembly in de Alexa top 1 miljoen websites en ontdekte dat het meest voorkomende gebruik was voor kwaadaardige crypto-mining, en dat malware goed was voor meer dan de helft van de onderzochte WebAssembly-gebruikende websites. Uit een studie van de Universität Stuttgart uit april 2021 bleek dat cryptomining sindsdien is gemarginaliseerd en gedaald tot minder dan 1% van alle WebAssembly-modules die zijn verzameld uit een breed scala aan bronnen, waaronder ook de Alexa top 1 miljoen websites.
De mogelijkheid om grote hoeveelheden code effectief te verdoezelen, kan ook worden gebruikt om advertentieblokkering en privacytools uit te schakelen die webtracking voorkomen, zoals Privacy Badger.
Omdat WebAssembly alleen een gestructureerde controlestroom ondersteunt, is het geschikt voor beveiligingsverificatietechnieken, waaronder symbolische uitvoering. Huidige inspanningen in deze richting omvatten de symbolische uitvoeringsengine van Manticore.