Notes: Building a Better Web Browser
These are my cursory notes from a talk given by James Mickens of Microsoft Research, in March 2015, titled "Building a Better Web Browser".
Notes legibility estimate: MEDIUM
The State of Progress
Chrome, Opera isolate the renderer in separate processes -- this allows tabs to crash on their own. ...but the issue is that the browswer is still a monolithic kernel.
Servo -- extra threading! ...but still monolithic.
The problem: Browser developers take the monolithic design as a given, and tinker around the edges.
The Problem
What is a browser trying to do? Provide services for origins -- render, computation, i/o + messaging
- It provides
origin = <protocol, host, port>
Render: HTML CSS MathML Aria WebGL video canvas images
IO: XHR DOM IndexedDB Cookies FileReader BrowserCache AppCache
Currently: providing services for origins, but they're high-level and complex. You wouldn't ask your operating system to implement Emacs in the kernel. ...well, you might. That was a test; I've already called the police on you.
Kernel: network, UI, storage (concurrency)
Usercode: rendering, javascript, parser
Atlantis
Taglines: security, performance, robustness
But first, some depressing things...
Browsers offer many opportunities for parallelism! ex: HTML parsing, rendering, network and disk IO. But current architectures limit concurrency, suffer from races.
But the DOM model says: JS is single-threaded, and cannot see browser locks. So: JS execution should biglock the DOM. What does happen: NOT THAT.
But in reality, there's just no concurrency re: the DOM. None. more at: Race Detection for Web Applications -- Petrov et al., PLDI '12
idiosyncratic abstraction (n.) an abstraction that is inconsistently applied throughout an application.
HTML5 screen-sharing attacks: SOP should prevent attacker.com from opening and screen-scraping bank.