Chrome vs. Everybody

Dated May 19, 2020; last modified on Tue, 12 Oct 2021

Browser Market Share Worldwide (2009 - 2020). Source: statcounter | GlobalStats

Browser Market Share Worldwide (2009 - 2020). Source: statcounter | GlobalStats

At the very least, Chrome is worth studying. Something worked out. I’m biased, I only plan to deeply explore Chromium-based browsers and Firefox.

Stability, Testing and the Multi-Process Architecture

In a single-threaded browser, devs use asynchronous APIs - which may sometimes hold the browser up. Instead of multiple threads, Chromium chose multiple processes: isolation, independent crashes, better asymptotic memory management, identifying expensive sites, etc.

Google indexes a lot of web pages. The chrome bots test out millions of the most popular pages, reporting breaks before the builds reach users.

Firefox has been moving towards a more multi-process architecture. The main push seems to be security improvements by limiting the blast area.

Firefox Containers have gotten more PR, e.g. the Facebook Container as a line of defence against Big Bad Zuck! Data supported by originAttributes is fair game for containerization, e.g. cookies, localStorage, indexedDB, HTTP data cache, image cache (and in the future, history, bookmarks, and security exceptions). Passwords, search & form data, HSTS flags and OCSP responses will still be accessible cross-container. Admittedly, containers are more public facing and user-oriented, but they seem to offer no protection against process-wide attacks. Furthermore, containers can be added to Chromium, but will they?

In 2019, Chrome implemented Site Isolation, an architecture that locks each renderer process to documents from a single site and filters certain cross-site data from each [renderer] process. Previously, evil.com could load an iframe for bank.com and exploit vulnerabilities in the renderer process to steal sensitive information.

Interesting that in the “one-site-per-process” policy, site refers to the public suffix, ignoring subdomains. For instance, https://google.com and https://mail.google.com will probably land in the same process.

Speed: WebKit and V8

The WebKit Project is an OSS project by Apple composed of a rendering engine for HTML and CSS, a JS engine, and a high-level API for embedding the engine into browsers). Google forked it to create Blink, citing different multi-process architecture. Browsers on iOS are still required to use WebKit as their rendering engine.

V8 is the OSS JavaScript virtual machine by Google. It beats other JS engines by using hidden classes for [classless] objects that end up with the same properties, generating machine code instead of being interpreted, and exercising incremental garbage collection.

References

  1. Browser Market Share Worldwide (2009 - 2020). statcounter | GlobalStats. https://gs.statcounter.com/browser-market-share#yearly-2009-2020 .
  2. Google Chrome: I. Stability, Testing and the Multi-Process Architecture. https://www.google.com/googlebooks/chrome/small_02.html .
  3. Site Isolation: Process Separation for Web Sites within the Browser. Charles Reis; Alexander Moshchuk; Nasko Oskov. https://www.usenix.org/conference/usenixsecurity19/presentation/reis . hhttps://www.chromium.org/developers/design-documents/site-isolation . 2019. ISBN: 978-1-939133-06-9.
  4. Security/Contextual Identity Project/Containers. https://wiki.mozilla.org/Security/Contextual_Identity_Project/Containers .
  5. Google Chrome: Speed: WebKit and V8. https://www.google.com/googlebooks/chrome/small_12.html .
  6. Google going its own way, forking WebKit rendering engine. Peter Bright. https://arstechnica.com/information-technology/2013/04/google-going-its-own-way-forking-webkit-rendering-engine/ . Apr 13, 2013.
  7. The Chromium Projects: Blink - Developer FAQ. http://www.chromium.org/blink/developer-faq . 2013.