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,[2] evenals software-interfaces om interacties tussen dergelijke programma's en hun hostomgeving te vergemakkelijken.[3][4][5][6]
WebAssembly | ||||
---|---|---|---|---|
Paradigma | imperatief programmeren, gestructureerd programmeren | |||
Verschenen | 2015 (8 jaar) | |||
Ontwikkeld door | W3C, Mozilla, Microsoft, Google, Apple | |||
Huidige versie | 2.0[1] | |||
Beïnvloed door | asm.js, Google Native Client | |||
Besturingssysteem | Platform onafhankelijk | |||
Licentie | Apache-licentie | |||
Bestandsextensies | wast, wasm | |||
Website | (en) Webpagina | |||
|
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."[7] Het is een open standaard[8] en heeft tot doel elke taal op elk besturingssysteem te ondersteunen,[9] 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[10][11][12] en in 2021 ontving het de Programming Languages Software Award van ACM SIGPLAN.[13] Het World Wide Web Consortium (W3C) handhaaft de standaard met bijdragen van Mozilla, Microsoft, Google, Apple, Fastly, Intel en Red Hat.
Geschiedenis
bewerkenWebAssembly 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[14][15] 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.[16]
Sinds april 2022 bevindt WebAssembly 2.0 zich in de conceptstatus,[17][18] 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
bewerkenHoewel 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.[19][20] 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.[21]
Webbrowsers
bewerkenIn 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
bewerkenWebAssembly-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[22] of WAMR, wasm3, WAVM en vele anderen.[23]
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
bewerken- 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."[24]
Er is geen directe toegang tot het Document Object Model (DOM); het is echter mogelijk om hiervoor proxyfuncties aan te maken, bijvoorbeeld via stdweb[25] of web_sys[26] 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.[27] In de praktijk kan WebAssembly niet worden gebruikt in Chrome zonder "unsafe-eval",[28][29] terwijl er een werkthread-oplossing beschikbaar is.[29]
Beveiligingsoverwegingen
bewerkenIn 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.[30][31][32] Om deze toekomstige taalextensies te verkennen, heeft Google Chrome echter in oktober 2018 experimentele ondersteuning toegevoegd voor het voorstel voor de WebAssembly-thread.[33]
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".[34] De snelheid en verbergbaarheid van WebAssembly hebben geleid tot het gebruik ervan bij verborgen cryptomining op het apparaat van de websitebezoeker.[34][35] 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."[30] 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.[36][37] 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.[38]
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.[39] Huidige inspanningen in deze richting omvatten de symbolische uitvoeringsengine van Manticore.
Zie ook
bewerkenReferenties
bewerken- ↑ Release 2.0 (1 juni 2022). Geraadpleegd op 11 februari 2023.
- ↑ Mozilla, Understanding WebAssembly text format. MDN Web Docs. Geraadpleegd op 9 december 2019.
- ↑ Introduction — WebAssembly 1.0. webassembly.github.io. Geraadpleegd op 18 June 2019. “WebAssembly is an open standard...”
- ↑ Introduction — WebAssembly 1.0. webassembly.github.io. Geraadpleegd op 18 June 2019. “WebAssembly is a ... code format”
- ↑ Conventions — WebAssembly 1.0. webassembly.github.io. Geraadpleegd op 17 May 2019. “WebAssembly is a programming language that has multiple concrete representations (its binary format and the text format). Both map to a common structure.”
- ↑ Introduction — WebAssembly 1.0. webassembly.github.io. Geraadpleegd op 18 June 2019. “... this specification is complemented by additional documents defining interfaces to specific embedding environments such as the Web. These will each define a WebAssembly application programming interface (API) suitable for a given environment.”
- ↑ Introduction — WebAssembly 1.1. webassembly.github.io. Geraadpleegd op 19 februari 2021. “Its main goal is to enable high performance applications on the Web, but it does not make any Web-specific assumptions or provide Web-specific features, so it can be employed in other environments as well.”
- ↑ Haas, Andreas (14 June 2017). Bringing the Web Up to Speed with WebAssembly. SIGPLAN Notices 52 (6): 185–200. ISSN: 0362-1340. DOI: 10.1145/3140587.3062363. “While the Web is the primary motivation for WebAssembly, nothing in its design depends on the Web or a JavaScript environment. It is an open standard specifically designed for embedding in multiple contexts, and we expect that stand-alone implementations will become available in the future.”.
- ↑ Wasmer - The Universal WebAssembly Runtime. wasmer.io. Geraadpleegd op 19 februari 2021. “Compile everything to WebAssembly. Run it on any OS or embed it into other languages.”
- ↑ World Wide Web Consortium, WebAssembly Core Specification. World Wide Web Consortium (W3). Geraadpleegd op 9 december 2019.
- ↑ Couriol, Bruno, WebAssembly 1.0 Becomes a W3C Recommendation and the Fourth Language to Run Natively in Browsers. infoq.com. Geraadpleegd op 9 december 2019.
- ↑ WebAssembly Specification — WebAssembly 1.1. webassembly.github.io. Geraadpleegd op 22 maart 2021.
- ↑ Programming Languages Software Award. www.sigplan.org.
- ↑ Staring at the Sun: Dalvik vs. ASM.js vs. Native. blog.mozilla.org. Geraadpleegd op 7 december 2019. “Even discarding the one score where asm.js did better, it executes at around 70% of the speed of native C++ code.”
- ↑ Arjun, Jangda, Abhinav Powers, Bobby Berger, Emery Guha (25 januari 2019). Not So Fast: Analyzing the Performance of WebAssembly vs. Native Code.
- ↑ WebAssembly Worker Based Threads - Chrome Platform Status. chromestatus.com. Geraadpleegd op 19 februari 2022.
- ↑ WebAssembly Specification — WebAssembly 2.0 (Draft 2022-09-01). webassembly.github.io. Geraadpleegd op 9 september 2022.
- ↑ (en) WebAssembly 2.0 First Public Working Drafts | W3C News. Geraadpleegd op 9 september 2022.
- ↑ Non-Web Embeddings. WebAssembly. Geraadpleegd op 15 May 2019.
- ↑ Non-Web Embeddings. GitHub / WebAssembly. Geraadpleegd op 15 May 2019.
- ↑ Outside the web: standalone WebAssembly binaries using Emscripten · V8. v8.dev. Geraadpleegd op 28 juli 2020.
- ↑ Wasmtime — a small and efficient runtime for WebAssembly & WASI. wasmtime.dev. Geraadpleegd op 18 december 2020.
- ↑ Roadmap. Geraadpleegd op 7 december 2021.
- ↑ (en) Wasm needs a better memory management story · Issue #1397 · WebAssembly/design. GitHub. Geraadpleegd op 15 februari 2021.
- ↑ stdweb - Rust. docs.rs. Geraadpleegd op 5 June 2019. “The goal of this crate is to provide Rust bindings to the Web APIs and to allow a high degree of interoperability between Rust and JavaScript.”
- ↑ web_sys - Rust. docs.rs. Geraadpleegd op 5 June 2019. “Raw API bindings for Web APIs. This is a procedurally generated crate from browser WebIDL which provides a binding to all APIs that browser provide on the web.”
- ↑ (en) WebAssembly/content-security-policy. GitHub. Geraadpleegd op 17 februari 2021.
- ↑ 948834 - chromium - An open-source project to help move the web forward. - Monorail. bugs.chromium.org. Geraadpleegd op 17 februari 2021.
- ↑ a b (en) No way to use WebAssembly on Chrome without 'unsafe-eval' · Issue #7 · WebAssembly/content-security-policy. GitHub. Geraadpleegd op 17 februari 2021.
- ↑ a b (en) Neumann, Robert, In-browser mining: Coinhive and WebAssembly. Forcepoint (19 april 2018). Geraadpleegd op 8 June 2019.
- ↑ (en) Cimpanu, Catalin, Changes in WebAssembly Could Render Meltdown and Spectre Browser Patches Useless. Bleeping Computer (24 June 2018). Geraadpleegd op 8 June 2019.
- ↑ (en) Sanders, James, How opaque WebAssembly code could increase the risk of Spectre attacks online. Tech Republic (25 June 2018). Geraadpleegd op 9 June 2019.
- ↑ R, Bhagyashree, Google Chrome 70 now supports WebAssembly threads to build multi-threaded web applications. Packt Pub (30 October 2018). Geraadpleegd op 9 June 2019.
- ↑ a b Lonkar, Aishwarya, The dark side of WebAssembly. Virus Bulletin (October 2018). Geraadpleegd op 8 June 2019.
- ↑ Segura, Jérôme, Persistent drive-by cryptomining coming to a browser near you. Malwarebytes (29 november 2017). Geraadpleegd op 8 June 2019.
- ↑ Recent Study Estimates That 50% of Websites Using WebAssembly Apply It for Malicious Purposes. InfoQ. Geraadpleegd op 3 november 2019.
- ↑ Musch, Marius (June 2019). Detection of Intrusions and Malware, and Vulnerability Assessment. DOI:10.1007/978-3-030-22038-9_2, "New Kid on the Web: A Study on the Prevalence of WebAssembly in the Wild", 23–42. ISBN 978-3-030-22037-2. Gearchiveerd op 26 juli 2022. Geraadpleegd op 15 February 2022.
- ↑ Aaron Hilbig, Daniel Lehmann, and Michael Pradel (April 2021).
- ↑ (en) Watt, Conrad (8 januari 2018). Mechanising and verifying the WebAssembly specification. Proceedings of the 7th ACM SIGPLAN International Conference on Certified Programs and Proofs CPP 2018: 53–65 (ACM: Los Angeles CA USA). DOI: 10.1145/3167082.