As more and more time is spent accessing and producing content online, libraries need to position themselves to offer Internet privacy to patrons as well. This column reviews tactics for securing web browsers, from selecting a high-quality piece of software to strong default settings to add-ons that extend the capabilities of the browser.

With the rising popularity of Web-based applications, the Web browser platform is becoming the dominant environment in which users interact with Internet content. We investigate methods of discovering information about network performance characteristics through the use of the Web browser, requiring only minimal user participation (navigating to a Web page). We focus on the analysis of explicit and implicit network operations performed by the browser (JavaScript XMLHTTPRequest and HTML DOM object loading) as well as by the Flash plug-in to evaluate network performance characteristics of a connecting client. We analyze the results of a performance study, focusing on the relative differences and similarities between download, upload and round-trip time results obtained in different browsers. We evaluate the accuracy of browser events indicating incoming data, comparing their timing to information obtained from the network layer. We also discuss alternative applications of the developed techniques, including measuring packet reception variability in a simulated streaming protocol. Our results confirm that browser-based measurements closely correspond to those obtained using standard tools in most scenarios. Our analysis of implicit communication mechanisms suggests that it is possible to make enhancements to existing “speedtest” services by allowing them to reliably determine download throughput and round-trip time to arbitrary Internet hosts. We conclude that browser-based measurement using techniques developed in this work can be an important component of network performance studies.

Current web browsers are ill-prepared to manage execution of scripts embedded in web pages, because they treat all JavaScript code executing in a page as one unit. All code shares the same namespace, same security domain, and shares uncontrolled access to the same heap; some browsers even use the same thread for multiple tabs or windows. This lack of isolation frequently causes problems that range from loss of functionality to security compromises. ScriptSpace is an abstraction that provides separate, isolated execution environments for parts or all of a web page. Within each ScriptSpace, we maintain the traditional, single-threaded JavaScript environment to provide compatibility with existing code written under this assumption. Multiple ScriptSpaces within a page are isolated with respect to namespace, CPU, and memory consumption. The user has the ability to safely terminate failing scripts without affecting the functionality of still-functional components of the page, or of other pages. We implemented a prototype of ScriptSpace based on the Firefox 3.0 browser. Rather than mapping ScriptSpaces to OS-level threads, we exploit a migrating-thread model in which threads enter and leave the ScriptSpaces associated with the respective sections of the document tree during the event dispatching process. A proportional share scheduler ensures that the number of bytecode instructions executed within each ScriptSpace is controlled. Our prototype can isolate resource-hogging gadgets within an iGoogle Mashup page as well as across multiple pages loaded in the browser and still retain interactive response. / Master of Science

Det här arbetet innefattar html 5 i avseendet beträffande användning av dess nya taggar/attribut redan nu, även fastän år som 2022 eller 2014 har nämnts av vissa när det gäller utvecklingsspråkets färdigställande. Intresset bakom arbetet uppstod baserat på några olika saker. Först och främst vid studerandet inom kursen "Webbteknisk Introduktion" (som läses i samband med Webbprogrammerare-programmets första år (hösten 2009), hos Linnéuniversitet) där användning av nya taggar, och påståenden avseende att språket redan då kunde börja användas, samt även utvecklingsspråkets namn (eftersom innefattningen av språket består av mycket mer än taggar/attribut) bidrog. Av de nytillkomna taggarna/attributen, har automatiska tester (via Javascript) gentemot de senaste versionerna av webbläsarna (Maj 2011 samt Augusti 2011) bestående av Internet Explorer, Opera, Mozilla Firefox, Apples Safari och Google Chrome genomförts. Operativsystemen webbläsarna körts under består av Mac OS X Server 10.6.7 och Windows 7 Professional (x86). Avseende resultatet visar det att webbläsarna överlag har omkring 80 till 90 % stöd för de nytillkommna taggarna, även fastän alla nya attribut stöds olika i webbläsarna. Slutsatsen av testerna visar därmed att det blir en övervägning i avseendet beträffande vad som kan/bör/skall brukas. / This essay is about html 5 and its tags/attributes can be used right now, even if years like 2022 or 2014 has been talked about for dates when the new language can be completely done. The interest behind the essay arose when I’ve studied in a computer course named “Webbteknisk Introduktion” at the Linnaeus University the autumn of 2009, inside the program: “Webbprogrammerare-programmet”. The course was mainly about html, but at one point we’ve also got to have our hands on the new thing – html 5. It was said at the same point in the course, that html 5 was more or less ready to use. Which caught my interest and wanted to get evidence about it. New tags/attributes have in this work been tested with JavaScript towards the latest web browsers (as of May 2011 and August 2011) consisting of: Internet Explorer, Opera, Mozilla Firefox, Apple Safari and Google Chrome. On top of Mac OS X Server 10.6.7 and Windows 7 Professional (x86). According to the final results, it shows that the tested browsers had about 80 to 90 percent support for the new tags, even if the attributes may vary. The final conclusion about the completed tests would then be that it’s more or less a choice of the things in the language he/she wants, or need to use, and so on.

Context - Software applications on the web are more commonly used nowadays than before. As a result of this, the performance needed to run the applications is increasing. One method to increase performance is writing multi-threaded code using Web Workers in JavaScript. Objectives - We will investigate how using Web Workers can increase responsiveness, raw computational power and decrease load time. Additionally, we will conduct a survey that targets software developers to find out their opinions about performance in web applications, multi-threading and more specifically Web Workers. Realization (Method) - We created three experiments that concentrate on the areas mentioned above. The experiments are hosted on a web server inside an isolated Docker container to eliminate external factors as much as possible. To complement the experiments we sent out a survey to collect information of developers' opinions about Web Workers. The criteria for the selection of developers were some JavaScript experience. The survey contained questions about their opinions on switching to a multi-threaded workflow on the web. Do they experience performance issues in today's web applications? Could Web Workers be useful in their projects? Results - Responsiveness shifted from freezing the website to perfect responsiveness when using Web Workers. Raw computational power increased at best 67% when using eight workers with tasks that took between 100 milliseconds and 15 seconds. Over 15 seconds, sixteen workers improved the computational power further with around 3% - 9% compared to eight workers. At best the completion time decreased with 74% in Firefox and 72% in Chrome. Using Web Workers to help with load time gave a big improvement but is somewhat restricted to specific use cases. Conclusions - Using Web Workers to increase responsiveness made an immense difference when moving tasks that is affecting the users responsiveness to background threads. Completion time for big computational tasks was quicker in use cases where you can split the workload to separate portions and use multiple threads in parallel to complete the tasks. Load time can be improved with Web Workers by completing some tasks after the page is done loading, instead of waiting for all tasks to complete and then load the page. The survey indicated that many have performance in mind and would consider writing code in a multi-threaded way. The knowledge about multi-threading and Web Workers was low. Although, most of the participants believe that Web Workers would be useful in their current and future projects, and are worth the effort to implement.

Background. Web tracking is a constant threat to our privacy when browsing the web. There exist multiple methods of tracking, but browser fingerprinting is more elusive and difficult to control. Browser fingerprinting works by a website collecting all kinds of browser and system information on visiting clients and then combining those into one set of information that can uniquely identify users. Objectives. In this thesis, we tested three of today's most used web browsers for the desktop platform to determine their ability to utilize one type of countermeasure, attribute spoofing. We aimed at determining how the browsers perform in two cases. The first case is when running with a default configuration. The second case is when the attribute spoofing is improved with the help of both altered settings and installed extensions. We also aimed at determining if the choice of browser matters in this aspect. Methods. The method for determining these goals was to conduct an experiment to collect 60 fingerprints from each browser and determine the effectiveness of the attribute spoofing via a weight-based system. We also used statistics to see the value range for spoofed attributes and to determine if any browser restart is required for certain spoofing to occur. Results. Our results show little to no attribute spoofing when browsers run in their default configuration. However, significant improvements were made through anti-fingerprint extensions. Conclusions. Our conclusion is, if the tested browsers' do not utilize any other type of countermeasure than attribute spoofing, using browsers at their default configuration can result in a user being alarmingly vulnerable to browser fingerprinting. Installing extensions aimed at improving our protection is therefore advised.

Browser security indicators show warnings when sites load without HTTPS, but more malicious sites are using HTTPS to appear legitimate in browsers and deceive users. We explore a new approach to browser indicators that overcomes several limitations of existing indicators. First, we develop a high-level risk assessment framework to identify risky interactions and evaluate the utility of this approach through a survey. Next, we evaluate potential designs for a new risk indicator to communicate risk rather than security. Finally, we conduct a within-subjects user study to compare the risk indicator to existing security indicators by observing participant behavior and collecting feedback. Our results suggest that risk indicators make users more confident in judging their risk and that participants prefer risk indicators over current security indicators. In addition, users take fewer risks in the presence of risk indicators, making this a promising direction for research and implementation into web browsers.

Background: In the contemporary digital landscape, web browsers have evolved from mere text renderers to sophisticated platforms supporting interactive 3D visualizations, multimedia, and gaming applications. This evolution has been catalysed by the advent of WebAssembly, a binary instruction format designed to enhance browser performance by executing high-level language code with near-native efficiency. This thesis investigates the performance implications of WebAssembly modules generated from programs written in C++ and Rust programming languages. Objectives: The primary aim is to assess the performance of WebAssembly(Wasm) modules generated from Rust and C++ programming languages. This involves conducting a mini literature review on WebAssembly compilation, C++, and Rust semantics and compilation processes. Furthermore, the study aims to evaluate the performance of C++ and Rust Wasm modules encompassing tasks such as sorting and matrix multiplication. Performance metrics including execution time and file size of the obtained Wasm modules are analysed using Chrome’s DevTools. Ultimately, the research endeavours to provide insights into Wasm performance. Method: In this study, the research method relies on a quantitative experimental approach by writing programs like quicksort and matrix multiplication in both C++and Rust programming languages and compiling them into Wasm modules using compilers like Emscripten for C++ and RustC for Rust programs respectively. Since, the Wasm module is a byte code type it is converted into WebAssembly Text Format (WAT) file for obtaining the readable machine instructions. Performance metrics like execution speed, file size, and number of assembly instructions like add, load, loop, etc are evaluated and calculated using Chrome’s DevTools. Results: The study which involves a comparative analysis between Wasm modules of C++ and Rust programming languages showcase that the performance of the Rust Wasm module is more fast and efficient in terms of execution time, file size, etc than C++ Wasm module. The findings aim to assist developers in making informed decisions regarding programming language selection for web development, thereby enhancing the efficiency of web applications. Conclusion: The study has determined that the performance characteristics of WebAssembly modules originating from both C++ and Rust programs vary. The results underscore the superior speed and efficiency of Rust-generated Wasm modules when contrasted with those produced from C++. These insights establish a robust basis for future research and optimization initiatives within the field of web development.

Context: Now a day’s end users are using different types of computer applications like web browsers, data processing tools like MS office, notepad etc., to do their day-to-day works. In the real world scenario, the usage of Open Source Software (OSS) products by both industrial people and end users are gradually increasing. The success of any OSS products depends on its quality standards. ‘Efficiency’ is one of the key quality factor, which portray the standards of product and it is observed that this factor is given little importance during its development. Therefore our research context lies within evaluating the efficiency quality attribute in OSS web browsers. Objectives: As discussed earlier the context of this research lies in evaluating the efficiency of OSS web browsers, the initial objective was to identify the available efficiency measures from the current literature and observe which type of measures are suitable for web browsers. Then our next objective is to compute values for the identified efficiency measures by considering a set of predefined web browsers from all the categories. Later we proposed Efficiency Baseline Criteria (EBC) and based on this criterion and experiment results obtained, the efficiency of OSS web browsers had been evaluated. Therefore the main objective of conducting this research is to formulate EBC guidelines, which can be later used by OSS developers to test their web browsers and ensure that all the quality standards are strictly adhered during the development of OSS products. Methods: Initially Literature Review (LR) was conducted in order to identify all the related efficiency quality attributes and also observe the sub-attribute functionalities, that are useful while measuring efficiency values of web browsers. Methods and procedures which are discussed in this LR are used as input for identifying efficiency measures that are related to web browsers. Later an experiment was performed in order to calculate efficiency values for CSS & proprietary set of web browsers (i.e. Case A) and OSS web browsers (i.e. Case B) by using different tools and procedures. Authors themselves had calculated efficiency values for both Case A and Case B web browsers. Based on the results of Case A web browsers, EBC was proposed and finally an statistical analysis (i.e. Mann Whitney U-test) is performed in order to evaluate the hypothesis which was formulated in experiment section. Results: From the LR study, it is observed that efficiency quality attribute is classified into two main categories (i.e. Time Behavior and Resource Utilization). Further under the category of Time behavior a total of 3 attributes were identified (i.e. Response time, Throughput and Turnaround time). From the results of LR, we had also observed the measuring process of each attribute for different web browsers. Later an experiment was performed on two different sets of web browsers (i.e. Case A and Case B web browsers). Based on the LR results, only 3 efficiency attributes (i.e. response time, memory utilization and throughput) were identified which are more suitable to the case of web browsers. These 3 efficiency attributes are further classified into 10 sub-categories. Efficiency values are calculated to both Case A and B for these 10 identified scenarios. Later from Case A results EBC values are generated. Finally hypothesis testing was done by initially performing K-S test and results suggest choosing non-parametric test (i.e. Mann Whitney U-test). Later Mann Whitney U-test was performed for all the scenarios and the normalized Z scores are more than 1.96, further suggested rejecting null hypothesis for all the 10 scenarios. Also EBC values are compared with Case B results and these also suggest us that efficiency standard of OSS web browsers are not equivalent to Case A web browsers. Conclusions: Based on quantitative results, we conclude that efficiency standards of OSS web browsers are not equivalent, when compared to Case A web browsers and the efficiency standards are not adhered during development process. Hence OSS developers should focus on implementing efficiency standards during the development stages itself in order to increase the quality of the end products. The major contribution from the two researchers to this area of research is “Efficiency Baseline Criteria”. The proposed EBC values are useful for OSS developers to test the efficiency standards of their web browser and also help them to analyze their shortcomings. As a result appropriate preventive measures can be planned in advance. / +91 - 9491754620

This work describes actual state of open-source browsers on the Android platform and compares their features. It describes webpage classification problem and methods how to detect porn websites. It also shows a design of a system for blocking and detection of webpages with adult content and its implementation. For pornography detection there were used text based methods but also methods based on detection in images from web page with deep learning. Implemented solution was tested with experiments and described. The last chapter contains summarization of this work and proposal of improvements.