The meteoric increase in the popularity of JavaScript and a large developer community has led to the emergence of a large ecosystem of third-party packages available via the Node Package Manager (NPM) repository which contains over one million published packages and witnesses a billion daily downloads. Most of the developers download these pre-compiled published packages from the NPM repository instead of building these packages from the available source code. Unfortunately, recent articles have revealed repackaging attacks to the NPM packages. To achieve such attacks the attackers primarily follow three steps – (1) download the source code of a highly depended upon NPM package, (2) inject malicious code, and (3) then publish the modified packages as either misnamed package (i.e., typo-squatting attack) or as the official package on the NPM repository using compromised maintainer credentials. These attacks highlight the need to verify the reproducibility of NPM packages. Reproducible Build is a concept that allows the verification of build artifacts for pre-compiled packages by re-building the packages using the same build environment configuration documented by the package maintainers. This motivates us to conduct an empirical study (1) to examine the reproducibility of NPM packages, (2) to assess the influence of any non-reproducible packages, and (3) to explore the reasons for non-reproducibility. Firstly, we downloaded all versions/releases of 226 most-depended upon NPM packages, and then built each version with the available source code on Github. Secondly, we applied diffoscope, a differencing tool to compare the versions we built against the version downloaded from the NPM repository. Finally, we did a systematic investigation of the reported differences. At least one version of 65 packages was found to be non-reproducible. Moreover, these non- reproducible packages have been downloaded millions of times per week which could impact a large number of users. Based on our manual inspection and static analysis, most reported differences were semantically equivalent but syntactically different. Such differences result due to non-deterministic factors in the build process. Also, we infer that semantic differences are introduced because of the shortcomings in the JavaScript uglifiers. Our research reveals challenges of verifying the reproducibility of NPM packages with existing tools, reveal the point of failures using case studies, and sheds light on future directions to develop better verification tools. / Master of Science / Software packages are distributed as pre-compiled binaries to facilitate software development. There are various package repositories for various programming languages such as NPM (JavaScript), pip (Python), and Maven (Java). Developers install these pre-compiled packages in their projects to implement certain functionality. Additionally, these package repositories allow developers to publish new packages and help the developer community to reduce the delivery time and enhance the quality of the software product. Unfortunately, recent articles have revealed an increasing number of attacks on the package repositories. Moreover, developers trust the pre-compiled binaries, which often contain malicious code. To address this challenge, we conduct our empirical investigation to analyze the reproducibility of NPM packages for the JavaScript ecosystem. Reproducible Builds is a concept that allows any individual to verify the build artifacts by replicating the build process of software packages. For instance, if the developers could verify that the build artifacts of the pre-compiled software packages available in the NPM repository are identical to the ones generated when they individually build that specific package, they could mitigate and be aware of the vulnerabilities in the software packages. The build process is usually described in configuration files such as package.json and DOCKERFILE. We chose the NPM registry for our study because of three primary reasons – (1) it is the largest package repository, (2) JavaScript is the most widely used programming language, and (3) there is no prior dataset or investigation that has been conducted by researchers. We took a two-step approach in our study – (1) dataset collection, and (2) source-code differencing for each pair of software package versions. For the dataset collection phase, we downloaded all available releases/versions of 226 popularly used NPM packages and for the code-differencing phase, we used an off-the-shelf tool called diffoscope. We revealed some interesting findings. Firstly, at least one of the 65 packages as found to be non-reproducible, and these packages have millions of downloads per week. Secondly, we found 50 package-versions to have divergent program semantics which high- lights the potential vulnerabilities in the source-code and improper build practices. Thirdly, we found that the uglification of JavaScript code introduces non-determinism in the build process. Our research sheds light on the challenges of verifying the reproducibility of NPM packages with the current state-of-the-art tools and the need to develop better verification tools in the future. To conclude, we believe that our work is a step towards realizing the reproducibility of NPM packages and making the community aware of the implications of non-reproducible build artifacts.

Cette thèse porte sur la spécification, la vérification et la validation de systèmes critiques à l'aide de méthodes formelles, en particulier, B événementiel. Nous avons travaillé sur l'utilisation de B événementiel pour étudier des algorithmes de contrôle du platooning, à partir d'une version 1D simplifiée vers une version 2D plus réaliste. L'analyse critique du modèle du platooning en 1D a découvert certaines anomalies. La difficulté d'exprimer les théorèmes de deadlock-freeness dans B événementiel nous a motivé pour développer un outil, le générateur de théorèmes de deadlock-freeness, pour construire automatiquement ces théorèmes. Notre évaluation a confirmé que les preuves mathématiques ne sont pas suffisantes pour vérifier la correction d'une spécification formelle : une spécification formelle doit aussi être validée. Nous pensons que les activités de validation, comme les activités de vérification, doivent être associées à chaque raffinement. Pour ce faire, nous avons besoin de meilleurs outils de validation. Certains outils d'exécution existants échouent pour certains modèles non-déterministes exprimés en B événementiel. Nous avons donc conçu et implanté un nouvel outil d'exécution, JeB, un environnement de simulation en JavaScript pour B événementiel. JeB permet aux utilisateurs d'insérer du code sûr à la main pour fournir des calculs déterministes lorsque la traduction automatique échoue. Pour atteindre cet objectif, nous avons défini des obligations de preuve qui garantissent la correction de simulations par rapport au modèle formel / This thesis aims at the specification, verification and validation of safety-critical systems with formal methods, in particular, with Event-B. We assessed the usability of Event-B by the development of platooning control algorithms, specially how it scaled up from a simplified 1D version to a more realistic 2D version. The critical analysis of the 1D platooning model uncovered some anomalous behaviors. The difficulty of expressing the deadlock-freeness theorems in Event-B motivated us to develop a tool, the generator of deadlock-freeness theorems, to automatically construct these theorems. Our assessment confirmed that the mathematical proofs are not sufficient to assure the correctness of a formal specification: a formal specification should also be validated. We believe that the validation activities, like the verification activities, should be associated with each refinement during the development. To do that, we need better validation tools. The state-of-the-art tools which can execute Event-B models failed in highly non-deterministic models. Therefore we designed and implemented a new execution tool, JeB, which is a JavaScript simulation framework for Event-B. JeB allows users to safely insert hand-coded pieces of code to supply deterministic computations where the automatic translation fails. To achieve this goal, we have defined a set of proof-obligations which, when discharged, guarantee the correctness of the simulations with respect to the model.

Visualisering av statistik är ett tydligt sätt att presentera data som annars kan ses som svår att tyda och analysera. Med hjälp av visualiseringar på webben kan man nå ut till många och det är ett smidigt sätt att ta med sig och dela med sig av information. Denna rapport bygger på ett experiment där olika JavaScriptbibliotek jämförs baserat på tiden det tar att rita ut diagram av olika storlekar och typer. Linjediagram, punktdiagram och stapeldiagram skapas med de olika biblioteken. Vilka bibliotek som jämförs väljs ut utifrån ett antal kriterier och Chart.js, Google Charts och Plotly.js är de som uppfyller alla krav. Undersökningar där utritningstiden mäts genomförs och resultaten visar att Chart.js är snabbast på att rita ut diagram i de flesta mätningarna. Det finns signifikanta skillnader mellan alla diagrammätningar förutom mellan Linjediagram 2 skapat med Chart.js och Linjediagram 2 skapat med Plotly.js samt Plotly.js Stapeldiagram 1 och Plotly.js Stapeldiagram 5. Mätningarna visar också att diagram som baseras på större datamängd, i de flesta fall, också har längre utritningstid än diagram baserade på mindre datamängd.

In this report, a number of different Javascript-frameworks have been compared. The study is conducted at CSN (Centrala studiestödsnämnden). The study consists of two main parts, an evalua- tion through the literature study and an evaluation of the implementa- tion. The first part of the survey has Javascript-frameworks Angular2, Aurelia, Ember, Meteor and React comparisons. Together with CSN, a few criteria have been developed which will then be awarded points between one and five depending on how well a Javascript-framework meets a specific criterion. Five points are given when the Javascript- framework meets the entire criterion, one point is given when it partial- ly meets the criterion. After the first part of the investigation, Angular2 and Aurelia found that they would move on to the implementation phase. The implementation consists of a couple of windows from the existing service "Mina tjänster". In the evaluate implementation measures time for implementation, web browsing time, and number of code rows. From this it was found that Aurelia has less number of code rows than Angular 2. The reading time for Angular 2 is three times longer than Aurelia. In the evaluation of how difficult it is to implement the two frameworks, Angular 2 is considered to be "Average" and Aurelia to "Hard". The Javascript-framework recommended for CSN is Angular 2. This is because much more documentation about Angular 2 is available, and the difficulty is lower for Angular 2. The startup of a project is also much easier in Angular 2, which means that it requires less time to get into the framework. / Sammanfattning: I denna rapport har ett par olika Javascript-ramverk jämförts. Studien är utförd på CSN (Centrala studiestödsnämnden). Undersökningen består av två huvuddelar, en utvärdering genom litteraturstudie samt en utvärdering av implementation. I första delen av undersökningen har Javascript-ramverken Angular2, Aurelia, Ember, Meteor och React jämförts. Tillsammans med CSN har ett par kriterier tagits fram som det sedan kommer att delas ut poäng mellan ett till fem beroende på hur väl ett Javascript-ramverk uppfyller ett specifikt kriterium. Fem poäng ges ut då Javascript-ramverket uppfyller hela kriteriet, ett poäng ges ut då det delvis uppfyller kriteriet. Efter första delen av undersökningen kom det fram till att Angular2 och Aurelia skulle gå vidare till implemente- ringsfasen. Implementeringen består utav ett par fönster från den befintliga tjänsten ”Mina tjänster”. I utvärderingen av implementation mäts tid för implementering, inläsningstid för webbapplikationen samt antalet kodrader. Ur detta konstaterades det att Aurelia har mindre antalet kodrader än Angular 2. Inläsning tiden för Angular 2 är tre gånger längre än Aurelia. Men i bedömningen om hur svårt det är att implementera de bägge ramverken bedöms Angular 2 till nivån ”Me- del” och Aurelia till ”Svår”. Det Javascript-ramverk som rekommende- ras till CSN är Angular 2. Detta grundas på att det finns betydligt mycket mer dokumentation om Angular 2, samt att svårighetsgraden är lägre för Angular 2. Uppstarten av ett projekt är även mycket enklare i Angular 2, vilket betyder att det kräver mindre tid för att sätta sig in ramverket.

När fler och fler väljer att lära sig programmering kan det vara bra att öva på attlösa problem, genom att skriva funktioner som sedan kan testas för att se omanvändaren har lyckats. Function Practice är en tjänst för att kunna öva programmeringpå just detta sätt, genom att lösa uppgifter med att skriva funktioneri olika programmeringsspråk, de språk som kommer kunna användas ärJava, C++ och Python. Det ger även ett lätt och smidigt sätt att skapa sådanauppgifter. Syftet med projektet är att utveckla denna tjänst, genom att skapa enwebbtjänst som kan kompilera och köra funktioner för de olika språken, enhemsida som användarna kan skriva och testa kod på, samt ett sätt att definierauppgifterna som ska lösas, detta testas sedan med hjälp av ett användartest i enmindre grupp för att se om hur användarvänlig den är, samt att funktionalitetentestas och jämförs med några tidigare lösningar. Tjänsten testas för att se om ytterligaresäkerhet behövs genom att försöka att köra kommandon på värdsystemet.Slutsatsen av projektet är funktionaliteten bakom tjänsten fungerar dock atthemsidan behöver vara lite tydligare för att den ska vara mer användarvänlig,samt att användaren borde kunna få felmeddelanden utifall något inte fungerarför att de lättare ska veta vad de behöver göra. Säkerheten visar sig vara en viktigdel då det går att köra kommandon på värdsystemet vilket ger användarnafull kontroll på systemet. / As more and more people choose to learn programming it may be good to practicesolving problems by writing functions that can then be tested to see if theuser has succeeded. Function Practice is a service to be able to practice programmingin exactly this way, by solving tasks of writing functions in differentprogramming languages, the languages that will be used is Java, C ++ andPython. It also provides an easy and convenient way to create such tasks. Theaim of the project is to develop this service by creating a Web service that cancompile and run functions for the different languages, a website that users canwrite and test code, as well as a way to define the tasks to be solved, this is thentested with a user test in a smaller group to see how user-friendly it is, and thefunctionality is tested and compared with some previous solutions. The serviceis tested to see if additional security is needed by trying to run commands onthe host system. The conclusion of the project is that the functionality behindthe service works, however, that the website needs to be a little clearer for it tobe more user-friendly, and that the user should be able to get error messages incase something does not work to make it easier to know what they need to do.Security proves to be an important part when it is possible to execute commandson the host system which gives users full control of the system.

Users of internet browsers are constantly monitored, without their consent. By using the JavaScript APIs, it is possible to obtain various information about the browser, which together form a browser fingerprint, which can then be misused. Therefore, the goal of this work is to use a robust fingerprint protection solution of Brave browser and port it to the JavaScript Restrictor extension. In this work, the problematics of obtaining an fingerprint and countermeasures in the Brave browser are analyzed and then compared with the current protection in the JSR extension. The method of porting of Brave's countermeasures is presented and subsequently the procedure of implementation of these defense elements into the browser extension is described. The resulting implementation has been tested and evaluated, with the new protection appearing to be effective.

Denna rapport vänder sig till de som har ett affärs- eller/och teknikintresse i utvecklingen av gränssnitt till affärssystem från SAP. Det har skett en omfattande förändring de senaste åren med hur vi alla dagligen använder oss av internet och mobila enheter. Vi har alla vant oss vid snygga, användarvänliga och flexibla gränssnitt. Vi gör våra bankärenden och använder sociala medier från vår smartmobil. Vi tar sedan för givet att vi också lika lätt ska kunna använda dessa gränssnitt på vår läsplatta. Denna beteendeförändring har även hänt hos användarna av gränssnitt till SAP:s affärssystem. De tar därför för givet att gränssnitten ska vara lika intuitiva, användarvänliga och visas lika lätt på sina smartmobiler och läsplattor som på deras bärbara datorer. Dock så har gränssnitt till SAP:s affärssystem begränsade möjligheter att användas på mobila enheter. Även gränssnittens utseende och användarvänlighet har haft begränsningar. SAP har insett att användarna inte kommer att acceptera gränssnittens begränsningar länge till och har därför utvecklat en ny teknologi som de kallar SAPUI5. SAP påstår att denna teknologi löser användarnas nya behov. På uppdrag av Claremont AB har jag fått i uppgift att undersöka om SAPUI5 verkligen löser användarnas nya behov och att ställa den nya teknologin mot väggen. Jag har i undersökningen byggt tre olika gränssnitt som motsvarar de viktigaste nya behoven som användarna har. Med de gränssnitt jag utvecklat har jag visat att SAPUI5 är en mycket kompetent teknologi. Den kan mycket väl användas för att utveckla framtidssäkra användarvänliga gränssnitt som både kan användas på stationära samt mobila enheter. För att kunna sätta mig in i hur SAPUI5 skiljer sig från de befintliga teknologierna så gjorde jag en kvalitativ intervju med två seniora SAP-utvecklare som använder de äldre teknologierna. Resultatet av intervjun använde jag sedan till att jämföra de äldre teknologierna med den nya. Jämförelsen bekräftade att SAPUI5 är en teknologi som löser många av de behov som de äldre teknologierna har begränsningar med. Dessutom kom jag fram till att om du står i valet och kvalet att välja en av dessa teknologier gör du rätt i att grundligt undersöka vilka behov som ställs på det nya gränssnittet. De olika teknologierna löser olika typer av användares behov och det är därför väsentligt att sätta sig in i vad användarna behöver kunna utföra med hjälp av det nya gränssnittet. / This report is aimed at those who have a business or/and technical interest in the development of interfaces to Enterprise Resource Planning (ERP) systems from SAP. There has been a substantial change in recent years with how we daily make use of the internet and mobile devices. We have all become accustomed to sleek, user-friendly and flexible interface. We make our banking and use social media on our smartphone. We then take for granted that we just as easily can use these interfaces in our tablet. This behavioral change has also happened among the users of interfaces to SAP ERP systems. The users take for granted that the interfaces should be as intuitive, user-friendly and can be used as easily on their smartphones and tablets as their laptops. However, the current interfaces to SAP ERP systems have limited possibilities to be used on mobile devices. Even the interfaces look and ease of use have had its limitations. SAP has recognized that users will not accept the limitations of the interfaces any longer and have therefore developed a new technology that they call SAPUI5. SAP claims that this technology solves the user’s new needs. On behalf Claremont AB, I have been asked to investigate whether SAPUI5 really solve the user’s emerging needs and to nail down the new technology. I have in the study built three different interfaces that correspond to the new key requirements of the users. With the interface I developed, I have shown that SAPUI5 is a highly competent technology. It can very well be used to develop future-proof user-friendly interfaces that can be used both on desktop and mobile devices. To research how SAPUI5 differs from the existing technologies I made a qualitative interview with two senior SAP developers using the older technologies. I used the result of the interview to compare the old with the new technologies. The comparison confirmed that SAPUI5 is a technology that solves many of the needs the older technologies have limitations with. Moreover, I came to the conclusion that if you are going to choose one of these technologies you do well to thoroughly research the needs imposed on the new interface. The different technologies solve different types of user needs and it is therefore essential to gain an understanding of what the users need to be able to perform using the new interface.

Målet med det här arbetet har varit att utveckla en ljudmotor skriven i JavaScript som underlättar ljuddesign för webbsidor. Ett sekundärt mål har varit att diskutera hur relevant Flash är för ljuddesign på webben och huruvida HTML5 har möjligheten att ersätta Flash i framtiden. En ljudmotor som har fått namnet Klang har utvecklats som ett JavaScriptbibliotek för integration med interaktiva webbsidor. Ljudmotorn använder Web Audio API, den nyligen föreslådda ljudstandarden för HTML5, som bas för uppspelning och processering av ljud. För att anpassa ljuddesignen för olika typer av webbsidor har Klang möjligheten att dynamiskt styra hur musik och ljud spelas upp beroende på vilken typ av webbsida den används för och hur en besökare använder denna webbsida. Klang kommer att behöva fortsatt underhåll i framtiden när Web Audio API växer men ger en god överblick av vad som är ljudmässigt möjligt med HTML5 utan externa plugin. Rapportens slutsats förespråkar utvecklingen av HTML5 och möjligheterna det har infört ur ett ljudperspektiv men medger att Flash än så länge behåller sin plats i webbutvecklarens repertoar. / The primary objective of this work has been developing a JavaScript audio engine to aid in designing audio for the web. This project also covers discussion of whether or not HTML5 may replace Flash for the purpose of sound design for the web in the future. Klang, an audio engine available as a JavaScript plugin has been developed to be integrated with interactive websites. The audio engine uses Web Audio API, the newly proposed audio standard for HTML5, for audio playback and processing. To be able to adapt the audio engine for the web site it is used for, Klang offers a way to dynamically control the behaviour of music and sounds according to the type of web site it is used for and how users interact with the web site. Klang will be in need of updates as the Web Audio API continues to develop but demonstrates the potential of the audio features of HTML5. The conclusion of the report advocates the use of pure HTML5 and the improvements it brings to the web's audio department but recognizes that Flash still has a place in the repertoire of the web developer.

Idag utförs arbete ofta på resande fot och då används smarta telefoner och surfplat- tor istället för datorer. Dessa skärmar är oftast mindre än vad en datorskärm är. Där- för efterfrågas en mer dynamisk design av webbsidor som anpassar sig till storleken på skärmen. Webbsidans statiska design var 1000 pixlar bred och innehöll många tabeller vilket skulle få plats i den dynamiska designen med en minsta bredd på 320 pixlar. En del viktig information behövde även lyftas fram och göras tydligare. Det implementerades en ny CSS-mall samt flera nya JavaScript. En del HTML justerades för att passa den nya CSS-mallen. Eftersom en del viktig information behövdes pre- senteras tydligare skapades en helt ny flik. Innehållet blev driftinformation relaterat till den inloggade kunden. Efter simuleringarna i Chrome verifierades responsivite- ten av sidorna på alla skärmstorlekar. Implementeringen av AJAX gjorde att de lång- samma sidorna svarade direkt, men förbättrade inte den totala laddtiden. För att förbättra den skulle en back-end optimering behöva utföras. Projektets webbsida fu- gerade enligt önskemål. / In today ́s society people are working more and more while travelling, which makes them use smartphones and tablets instead of laptops. These screens are usually smaller than a laptop screen. That is why a more dynamic web design has been re- quested in order to fit the screen on the device being used. The static webpage’s width was 1000 pixels and the goal was to fit all the tables and information in the respon- sive version with a width of 320 pixels. Important information also had to be moved to a different page in order to make it more visible. A new CSS-template was imple- mented and several new Java Scripts followed by finer adjustments to the HTML code. Since some information had to be more visible to the user, a new tab was cre- ated in order to fulfill this demand. The new tab contained information about “Net- work Status” only related to the signed in user. After simulating the webpage in Chrome the responsiveness of the page was confirmed on all screen sizes. Sending the webpage asynchronously made the slow pages respond instantly but the total loading time was still slow. To fix this, back-end programming would have been re- quired. The project’s webpage fulfilled all the requirements.

Syftet med denna studie har varit att undersöka ifall det är möjligt att utveckla ett användargränssnitt i form av ett webbläsartillägg för Ladok som är ett resultatsystem för universitet och högskolor i Sverige. En del av studien har också varit att kunna utvärdera minst ett sätt att skapa webbläsartillägg. Enkätundersökningar samt intervjuer gjordes för att kunna förstå vilka typer av funktioner som skulle kunna vara till nytta för studenter samt lärare i ett sådant användargränssnitt. Det gjordes även GUI prototyper i designverktyget Figma som det gjordes användartester på. Den största utmaningen under arbetet har varit att kunna dra en slutsats om det är möjligt att kunna få tillgång till data från Ladok med hjälp av webbskrapning och API-förfrågningar. Datat på Ladok är sekretessbelagt eftersom Ladok innehåller konfidentiell information. Det har därför varit svårt att få tillgång till data under projektets gång. Olika typer av metoder testades under projektets gång för att se om det skulle kunna gå att få tillgång till data för att kunna utveckla ett användargränssnitt för Ladok. Slutsatsen som kan dras för detta projekt är det krävs mer forskning och tid samt att det inte finns någon lösning på detta än. Framtida arbete som är värt att nämna är kunna implementera användarskript som endast körs när studenter är inloggade på Ladok. Ett exempel på ett verktyg som kan användas för detta ändamål är TamperMonkey som är kompatibelt med Google Chrome. GreaseMonkey är motsvarar TamperMonkey, men är kompatibelt med Mozilla Firefox. / The objective of this study has been to examine if it is possible to develop a user interface as a browser extension for Ladok which is a result system that is used by higher education institutions such as colleges and universities in Sweden. A part of the study has also been to be able to evaluate at least one method of developing browser extensions. Interviews and surveys were conducted in order to understand what types of functions that would be beneficial for both students and teachers in such a user interface. GUI mockups were created in the design tool Figma and were later measured through usability tests. The main challenge during the study has been to be able to determine if it is possible to access data from Ladok through web scraping and API requests. As Ladok consists of confidential information about students, the data is private. Due to this it has been very difficult to be able to gather data. Different types of methods and approaches were used in order to determine if it would be possible to develop a user interface for Ladok. The conclusion that can be drawn is that more research and time are needed and that there is no clear solution for this yet. Future work could be to develop user scripts that would only run when Ladok would be used. An example of a tool for user scripts is TamperMonkey, which is compatible with Google Chrome. GreaseMonkey is equivalent to TamperMonkey, but is compatible with Mozilla Firefox.