Syftet med detta arbete var att undersöka möjligheterna att använda högnivåspråket Swift utanför iOS i webbläsaren och i Android. Detta för att minska mängden kod som skrivs och därmed minska utvecklingstiden för att skapa applikationer för iOS, webbläsaren samt Android. För att hitta lämpliga verktyg som löser frågeställningen har en undersökning av tidigare arbeten och metoder gjorts. Resultatet från undersökningen ledde till användningen av ramverket Tokamak tillsammans med WebAssembly för att återanvända Swift i webbläsaren och verktyget SwiftKotlin för att återanvända Swift i Android. En applikation med designmönstret Model-View-ViewModel (MVVM) skapades i avsikt att testa återanvändbarheten. Resultatet visade att Tokamak tillsammans med WebAssembly möjliggör återanvändning av ursprungliga koden för iOS-applikationen komplett förutom plattformsspecifika funktioner som lokalt sparande och nätverksanrop. SwiftKotlin möjliggör återanvändning av modellklassen i applikationen med små justeringar, medan vymodell och vyklasserna behöver skrivas manuellt. / The purpose of this work was to study the possibilities of using the high-level language Swift outside of iOS in the browser and on Android. This is to reduce the amount of code written thus reducing development time to create applications for iOS, browser, and Android. To find suitable tools to solve the problem, a study on previous works and methods has been made. The results of the study led to the use of the framework Tokamak together with WebAssembly to reuse Swift in the browser and the tool SwiftKotlin to reuse Swift on Android. An application using the Model-View-ViewModel (MVVM) design pattern was created with the intention of testing reusability. The results showed that Tokamak with WebAssembly made it possible to use all the code from the original iOS application except platform-specific functions such as local saving and network calls. SwiftKotlin made it possible to reuse the model class with some small adjustments while the viewmodel and view classes must be manually written.

Syftet med denna studie är utforska möjligheterna att återanvända modellkod, skriven i C, över flera plattformar, nämligen iOS, Android och HTML5. Målet är att undersöka kodstorlek och komplexitet vid återanvändning av modellkod skriven i C på plattformarna. Genom en noggrann granskning av tidigare forskning och existerande metoder identifierades lämpliga verktyg och metoder. Det som framkom är att WebAssembly var det rekommenderade verktyget för att koppla C- kod till HTML5. För Android var Java Native Interface (JNI) det mest lämpliga verktyget för att koppla C-kod till Kotlin. Swift, å andra sidan, har inbyggda verktyg för interoperabilitet som möjliggör koppling mellan Swift-kod och C. Därav påvisade resultaten att det är möjligt att återanvända modellkod skriven i C på Android, iOS och HTML5. Dock, för Android krävdes det tillsats av extra kod för att hantera kopplingen mellan Kotlin och C-modellkod. Eftersom dessa språk hanterar datatyper och minneshantering på olika sätt. Inom iOS krävdes inte lika mycket extra kod som på Android för att hantera kopplingen mellan Swift och C eftersom Swift är utvecklat med naturligt stöd för C. I HTML5 behövdes inte lika mycket extra kod som på Swift och Android eftersom Emscripten möjliggjorde automatisk generering av en omvandling från modellkod skriven i C till JavaScript. Detta underlättade utvecklandet av bindningen mellan C-baserad modellkod och HTML5-applikationen. / The purpose of this study was to explore the possibilities of reusing model code, written in C, across multiple platforms, specifically iOS, Android, and HTML5. The objective was to investigate code size and complexity when reusing model code written in C on these platforms. Through a thorough review of previous research and existing methods, suitable tools and methods were identified. It was found that WebAssembly was the recommended tool for linking C code to HTML5. For Android, the Java Native Interface (JNI) was the most appropriate tool for linking C code to Kotlin. Swift, on the other hand, has built-in tools for interoperability that allow for the connection between Swift code and C. The results indicated that it is possible to reuse model code written in C on Android, iOS, and HTML5. For Android, additional code was required to manage the connection between Kotlin and C model code, as these languages handle data types and memory management differently. However, within iOS, there was not needed additional code compared to Android, to manage the linkage between Swift and C. Since Swift is developed with inherent support for C. For HTML5, there was not as much additional code required as in Swift and Android, primarily because Emscripten enabled automatic conversion of model code written in C to JavaScript. This facilitated the development of the binding between C-based model code and the HTML5 application.

Blockchain-based cryptocurrencies is a fairly new concept with a worldwide spread, and there is a massive amount of currencies. Several of them involve so-called currency mining, a feature of Proof-of-Work based blockchains. One problem with currency mining is that it can be performed when visiting websites in the user's browser, exploiting the user's resources and consuming energy. This has spawned a wide variety of crypto mining detection algorithms in the research. A particular issue that can make detection difficult is if the code of the miner has been obfuscated. Because of the limited research on detecting obfuscated miners, this thesis selects a state-of-the-art detection algorithm and uses it to analyze crypto miners obfuscated with various obfuscation techniques. A dataset of Wasm binaries is constructed by filtering out miners with the help of the detection algorithm. The result indicates that multiple obfuscation techniques, all trivial to implement with basic find-and-replacement, are highly effective at hindering the miner detector. Some techniques lower the detection rate by 100% on the dataset. The effectiveness seems to depend primarily on how many lines are modified in the program, and secondly on what modifications exactly are performed. Also, the obfuscated samples do not take a longer time to analyze, on the contrary, the mean execution time of the detection algorithm becomes primarily shorter. The conclusion is that more research must be done in constructing detection algorithms robust towards code obfuscation, and that the detection rate of today's algorithms might be misleading if there is a large amount of obfuscated miners on the web. / Blockkedjebaserade kryptovalutor är ett relativt nytt koncept som spridit sig globalt, och det finns en uppsjö med kryptovalutor. Flera av dem involverar mining (”valutagrävning”), en företeelse hos Proof-of-work-baserade blockkedjor. Ett problem med mining är att det kan genomföras när en användare besöker webbsidor i webbläsaren, och därmed utnyttja användarens resurser och förbruka onödig energi. Detta har lett till forskning på flera olika typer av detektorer för mining. Ett särskilt problem som kan försvåra detektering är om miner-koden har obfuskerats. På grund av den begränsade forskningen på att detektera obfuskerade miner-program väljs i detta examensarbete en state-of-the-art-algoritm för detektering, och denna används för att analysera miner-program obfuskerade med olika obfuskeringstekniker. Ett dataset av Wasm-binärer konstrueras genom att filtrera ut miner-program med hjälp av detekteringsalgoritmen. Resultatet indikerar att flera obfuskeringstekniker, samtliga triviala att implementera med grundläggande hitta-och-ersätt-operationer, är mycket effektiva för att hindra detektorn. Vissa tekniker minskar detekteringsgraden med 100% på det dataset som används. Effektiviteten verkar primärt bero på hur många rader som är modifierade i programmet, och sekundärt på exakt vad för slags modifikation som genomförs. Dessutom tar de obfuskerade programmen inte längre tid att analysera, i själva verket är genomsnittstiden för detekteringsalgoritmen i huvudsak kortare jämfört med de ej obfuskerade. Slutsatsen är att mer forskning måste genomföras för att konstruera detekteringsalgoritmer som är robusta mot kodobfuskering, och detekteringsgraden hos dagens detekteringsalgoritmer kan vara vilseledande om det finns en stor mängd obfuskerade miner-program på webben.

One of the latest tools in the strive troughwards a fast and secure Web is called WebAssembly. It is a low-level, assembly-like language that can run in the browser alongside JavaScript. WebAssembly is designed to load fast and aims to execute at near-native speed. Being a compilation target for system languages like C, C++, and Rust, WebAssembly is not very accessible from a Web developer perspective. This project explores ways to generate WebAssembly directly from JavaScript code, in order to lower the learning curve, and allow for a more widespread adoption of WebAssembly. This has resulted in a utility tool called Esmbly, which can turn simple JavaScript programs into WebAssembly binaries by collecting and utilizing type information from various flavours of statically typed JavaScript.

This paper will explore the speed of execution, memory foot-print and the maturity of WebAssembly Runtimes (WasmRT).For this study, the WasmRT will be Wasmer1and Wasmtime.2Initially, benchmarks were run on a Raspberry Pi 3 model Bto simulate a more hardware capable IoT-device. Tests per-formed on a Raspberry Pi shows that there are many instanceswhere a WasmRT outperforms a similar Docker+C solution.WasmRT has a very clear use case for IoT devices, specifi-cally short jobs, the results from our research will show thatWasmRT can be up to almost 70 times as fast as a similarDocker solution. WasmRT has a very strong use case thatother container solutions can not contend with. This paperwill show how effective a lightweight, portable, and fast Was-merRT can be, but also to highlight its pain points and whenother container solutions may make more sense

WebAssembly is a new binary code specification, which was initially designed to complement JavaScript in web applications. WebAssembly is inherently portable and small, designed for multiplatform usage. Therefore, WebAssembly modules can be created to support embedded system-based biomedical sensor operation. However, WebAssembly has its own limitations to compensate with its portability. In this thesis, we show how WebAssembly modules can be applied to the basic biomedical modalities of body temperature, heart rate, and breathing pattern.  We show how the implementation performed, and what challenges were met during the development. It is concluded that WebAssembly can be applied for achieving safe and effective biomedical sensor devices, although with some limitations. / WebAssembly är ett nytt binärt maskinkodsformat, ursprungligen skapat för att komplettera JavaScript i webbapplikationer.  WebAssemblys kod är liten och kan lätt användas på flera plattformar. Därför kan WebAssembly-moduler skapas för att stödja inbyggda system för biomedicinska sensorer. WebAssembly har dock sina egna begränsningar på grund av sin portabilitet.  I denna avhandling visar vi hur WebAssembly-moduler kan användas på enkla biomedicinska mätningar av kroppstemperatur, hjärtfrekvens och andningsmönster. Vi visar hur implementeringen genomfördes och vilka utmaningar som möttes under utvecklingen. Slutsatsen är att WebAssembly kan tillämpas för att skapa säkra och effektiva biomedicinska sensorenheter, även om det finns en del begränsningar.

WebAssembly is an instruction set designed for a stack based virtual machine, with an emphasis on speed, portability and security. As the use cases for WebAssembly grow, so does the desire to target WebAssembly in compilation. In this thesis we present Rasm, a Racket to WebAssembly compiler that compiles a select subset of the top forms of the Racket programming language to WebAssembly. We also present our early findings in our work towards adding a WebAssembly backend to the Chez Scheme compiler that is the backend of Racket. We address initial concerns and roadblocks in adopting a WebAssembly backend and propose potential solutions and patterns to address these concerns. Our work is the first serious effort to compile Racket to WebAssembly, and we believe it will serve as a good aid in future efforts of compiling high-level languages to WebAssembly.

Racket is a modern, general-purpose programming language with a language-oriented focus. To date, Racket has found notable uses in research and education, among other applications. To expand the reach of the language, there has been a desire to develop an efficient platform for running Racket in a web-based environment. WebAssembly (Wasm) is a binary executable format for a stack-based virtual machine designed to provide a fast, efficient, and secure execution environment for code on the web. Wasm is primarily intended to be a compiler target for higher-level languages. Providing Wasm support for the Racket project may be a promising way to bring Racket to the browser. To this end, we present an incremental approach to the development of a Racket- to-Wasm compiler. We make use of an existing backend for Racket that targets a portable bytecode known as PB, along with the associated PB interpreter. We per- form an ahead-of-time static translation of sections of PB into native Wasm, linking the chunks back to the interpreter before execution. By replacing portions of PB with native Wasm, we can eliminate some portion of interpretation overhead and move closer to native Wasm support for Chez Scheme (Racket’s Backend). Due to the use of an existing backend and interpreter, our approach already supports nearly all features of the Racket language – including delimited continuations, tail-calling behavior, and garbage collection – and excluding threading and FFI support for the time being. We perform benchmarks against a baseline to validate our approach, to promising results.

Software Fault Isolation (SFI) is a form of software sandboxing that refers to the technique of isolating faults such as failures and vulnerabilities to a specific area in a software system. Together with other software sandboxing techniques, SFI remains a widely used practice in many types of software, ranging from web browsers to cloud infrastructure. Therefore, there are often different requirements on throughput, latency, and resource usage that have to be met. To this end, we have evaluated the usage of WebAssembly, a virtual instruction set architecture which has a design that makes it a suitable compilation target for enforcing SFI. Our findings show that WebAssembly compared to native x86-64 code performs favorably on memory-intensive workloads, but poorly on numerically intensive workloads. However, its main strength was found to be in communication between the host environment and the sandboxed environment. We found that communication across the sandbox boundary using WebAssembly-based sandboxing was up to several orders of magnitude faster than inter-process communication methods commonly used in process-based sandboxing. Additionally, we discuss the security model of WebAssembly and how it compares to other sandboxing methods.

With the current developments in modern web browsers, WebAssembly has been a rising trend over the last four years. Aimed at replacing bits of JavaScript functionality, it attempts to bring extra features to achieve portability and sandboxing through virtualisation. After the release of the WebAssembly System Interface, more and more projects have been working on using it outside web pages and browsers, in scenarios such as embedded, serverless, or distributed computing. This is thus not only relevant to the web and its clients, but also to applications in distributed systems. Considering the novelty of the topic, there is currently very little related scientific literature. With constant changes in development, proposals and goals, there is a large gap in relevant research. We aim to help bridge this gap by focusing on Rust and Arc-Lang, a domain-specific language for data analytics, in order to provide an overview of how far the technology has progressed, in addition to what runtimes there are and how they work. We investigate what kind of use case WebAssembly could have in the context of distributed systems, as well as how it can benefit data processing pipelines. Even though the technology is still immature at first glance, it is worth checking whether its proposals have been implemented, and how its performance compared to that of native Rust can affect data processing in a pipeline. We show this by benchmarking a filter program as part of a distributed container environment, while looking at different WebAssembly compilers such as Cranelift and LLVM. Then, we compare the resulting statistics to native Rust and present a synopsis of the state of WebAssembly in a distributed context. / I takt med den nuvarande utvecklingen av moderna webbläsare har WebAssembly stigit i trend under de senaste fyra åren. WebAssembly har som syfte att ersätta och utöka JavaScript med funktionalitet som är portabel och isolerad från omvärlden genom virtualisering. Efter lanseringen av WebAssembly System Interface har fler och fler projekt börjat applicera WebAssembly utanför webbsidor och webbläsare, i scenarier som inbäddade, serverlösa eller distribuerade beräkningar. Detta har gjort WebAssembly till ett språk som inte bara är relevant för webben och dess användare, utan även för applikationer i distribuerade system. Med tanke på ämnets framkant finns det för närvarande väldigt lite relaterad vetenskaplig litteratur. Ständiga förändringar i utveckling, förslag och mål har resulterat i stort gap i relevant forskning. Vi strävar efter att hjälpa till att överbrygga denna klyfta genom att studera WebAssembly i perspektivet av Rust och Arc-Lang, ett domänspecifikt språk för dataanalys, för att ge en översikt över hur långt tekniken har kommit, och samt utreda vilka exekveringssystem som finns och hur de fungerar. Vi undersöker vilken typ av användning WebAssembly kan ha i samband med distribuerade system, samt hur det kan gynna databehandlingspipelines. Även om tekniken fortfarande är ny vid första anblicken, är det värt att kontrollera om dess förslag har implementerats och hur dess prestanda gentemot Rust kan påverka databehandling i en pipeline. Vi visar detta genom att benchmarka ett filtreringsprogram som en del av en distribuerad containermiljö, samtidigt som vi tittar på olika WebAssembly-kompilatorer som exempelvis Cranelift och LLVM. Vi jämför resultaten med Rust och presenterar en sammanfattning av WebAssemblys tillstånd i sammanhanget av distribuerade system.