Notes from Nick Desaulniers on Convergence of the Browser and the OS

notes.md

Convergence of the Browser and OS

Nick Desaulniers (Open Source @ Mozilla)

• What does "Open Source" mean to me?

What would a desktop environment look like if it were implemented entirely in a browser?

• What applications launch at startup? The browser and a terminal, but the terminal could easily be running in the browser.

• If you were forced to write these applications in the browser, could you do it?

Predominant issue is trust. Can I trust an executable from the internet? Browsers provide a nice sandbox; we're more nervous about running applications outside of that sandbox.

• Need to know that what you're downloading is what you actually think you're downloading.

• Software often tricks users into installing it, but good software should be selling itself. Bundled software is not legitimate software. Ask yourself: "would I install it on my own?"

Can I trust that applications are not escalating their own privileges?

• Process isolation is one of the key ideals behind Chrome. Each tab is a separate process with a unique address space. If something breaks, it should be contained. Mozilla is trying hard to implement this but has to overcome a history of running on single-core processors. But it's coming to Firefox Nightly (File > New e10s Window)

• Trust needs to be revocable. Can you take it away once broken? This leads to the idea of (ideally "informed") consent. What are the negative consequences? How bad are they? This is where EULAs, Terms, and Privacy Policies come from. Unfortunately the difficulty we have following their legalese makes them a failure. Firefox has these, but what's the point?

So we have permission models based around applications, and it's up to the OS to decide what applications can do. We can prompt users for their consent, but they either (1) won't understand the consequences or (2) will click through automatically. Even when a prompt asks for permission to read and write to contacts or access non-free services, we tend to blindly accept the terms. It gets pretty bad.

We should be helping users understand what software will do and help them provide informed consent.

Some questions:

• Should we let applications even touch the filesystem?

  • Files differ across operating systems, as to their permission models.

  • In node.js, buffers (raw bytes) and streams (raw bytes in transit) might provide sufficient abstraction. Can we toss these into Sqlite

• Should the application be allowed to connect to hosts other than the one I navigated to? Maybe it needs access to a CDN, but maybe it's visiting a site with an XSS vulnerability

Certain functions (sprintf) shouldn't even exist. They wouldn't pass security review. Desktop computers implement permissions in terms of users. This makes sense for expensive machines that must support multiple users. But how many users use your phone?

We're now moving to application-level permissions. Thinking in terms of rings of protection, a traditional OS has a kernel, drivers, and applications. What if we added an extra layer of protection by forcing users to access software through the (sandboxed) browser? We can give developers access to the machine but disallow anything that introduces new vectors of attack.

But what about performance?

• Why do we have virtual memory? It's slow (embedded programmers know this) but it has value to real users. It takes time to switch CPU modes, but there's a reason: as computers get faster and faster, the benefits of these additional levels of abstraction significantly outweight the cons

• JS itself has gotten faster. It's 100x faster since 2006, and will "blow the doors" off of Ruby, PHP, et. al. Don't bet against it. It's not done advancing on a performance frontier, but we haven't even tapped out our options for runtime optimization

• Many C/C++ (game) developers have a fast codebase, but want to be able to run in the browser. JS needs to be fast--really fast. Fortunately JS, is the biggest target of other languages. Lots of companies are looking into questions of transpiling, cross-compiling; there's help for making other languages run fast in the browser

• Native Client (NaCl) provides a runtime so that functions which would ordinarily make system calls are instead wrapped to act only through secure, portable encapsulation. Overhead is low--5-10%. But the onus falls on the developer to deploy and test their application against different platforms and architectures. Less common architectures don't get targeted.

• Google's introduced a "Portable Native Client" that compiles to a subset of LLVM IR, and then on to NaCl. But LLVM IR is a compiler IR--not a VM. It's sasy to support if you ship a browser with Pepper API support, but implementing the API requires duplicating lots of undocumented Chrome behavior. So it hasn't been adopted by other browser vendors.

• Mozilla asked, "how can we let languages target JS through LLVM, but use a different compiler to get there". Now asm.js: compile from code to an AST, validate, and start generating bytecode. Mozilla runs this on a virtual machine, watches the heat of loops, and runs it through a fast (but not completely optimized) compiler. Code that warms goes to a baseline compiler; waits 10k iterations, and passes it to the optimizing compiler (Ion Monkey)

• Empscripten generates a subset of JavaScript (it will run in all browsers). There's a "hot path", too--if the AST doesn't exceed past it, types can be inferred and code can skip straight to the optimizing compiler

• Mozilla announced support for Unreal 4 and Unity 5; now "Export to ..." has been joined by "Export to the web"

Demo (BananaBread) demonstrates interaction with the web (Twitter), playing games with the game--clearly, performance is getting better. Think about games that are "Powered by Unreal"? Now users can try these games via a shared link. They don't need to buy a console--if their computer has a browser they can play it.

But a common question: why isn't Firefox available on ... Platform?

• In order to ship a VM like SpiderMonkey, you need an OS that will allocate executable memory. Without it you can't ship a Just-in-Time compiler (JIT) and performance benchmarks won't be hit

• What sets ASM.js apart is that it works in all browsers. Even if they don't have a fast-track (like SpiderMonkey) they will still see some benefits from using it

Oh, and standards.

• html5test.com--why does FF release so fast? Faster releases allow vendors to keep their gaps tight. Slowed browsers tend to have bigger gaps with the state of the art

• System Applications Working Group -- Most APIs are stable. The next big showdown for browser vendors will be in the tools used to develop them

Demo (getUserMedia): get a video stream (webcam), load metadata, and call play. Mozilla's App Manager3 gives nearby devices permission to perform remote debugging, shows a list of applications, and lets developers debug their apps remotely. DOM Inspector (on PC) can watch for and update on interactions with an app on a nearby phone. Change a rule, and the device updates too.

Shipping a browser-based OS (it's HTML, CSS, and JavaScript) creates a new generation of hackers. You can hack the homescreen app by changing CSS rules in the debugger. And it's wireless--pretty cool!

Developers still fight two battles (Emacs v. Vim and Browser v. Native) but users don't want to--and shouldn't have to--care.

Demo: apps on Firefox OS can run on any platform where Gecko is available. We can run it on a Firefox OS phone; on Android va the Firefox marketplace; on Windows; on OS X via Desktop Firefox; and get a "Native App experience" throughout--no rewrite needed.

We can build web apps that work offline, don't need the internet, and still play nicely.

What does success look like?

• Last year Chrome OS shipped millions, Firefox OS sold 400k devices, and this is cause for hope

• We're at the beginning. What does a computing environment encapsulated in the browser look like? Take this one home and ponder it

what open source means to me