Browser Performance And Security (Part 1) | Manvi Sharma

Browser Performance And Security (Part 1)

A web browser is old software, with lineages tracing back to the 1990s. It’s our portal to the cloud, interface with Salesforce, AWS, Azure, and countless other services.

It’s also one of the most insecure apps you will ever use, with malicious attacks targeting the browser.

Web browsers are not set up in the most secure means with the default configuration. They tend to be configured for maximum performance, and the performance and security don’t always go together. This is true of both preloaded browsers with the computer and the ones you may download.

But with time as they have evolved, many browsers like Microsoft, Apple, and various Linux vendors have effectively secured their respective operating systems.

This post will discuss the complex browser structure and processes about how it handles security and performance.

We will use Chromium browser for understanding these concepts, since source code for Chromium provides the basis for multiple browsers.

Chromium

Chromium is a free and open-source web browser project, mainly developed and maintained by Google. This codebase provides the vast majority of code for the Google Chrome browser, which is proprietary software and has some additional features.

The Chromium codebase is widely used. Microsoft Edge, Samsung Internet, Opera, and many other browsers are based on the Chromium code. Moreover, significant portions of the code are used by several app frameworks.

Google does not provide an official stable version of the Chromium browser but does provide official API keys for some features, such as speech-to-text and translation.

How does Chromium handle browser security?

Chromium has its own Process Model that determines how documents, workers, and other web content are divided into processes,

so that neither safety nor performance is compromised.

It also has support for Site Isolation, which is a security feature in Chrome that offers additional protection against some types of security bugs. It uses Chrome's sandbox to make it harder for untrustworthy websites to access or steal information from your accounts on other websites.

Let us discuss in detail:

Process Model and Site Isolation

With the evolution of web from simple documents to active programs, the web browser's role changed from a simple document renderer to an operating system for programs. Modern browsers use multiple operating system processes to manage this workload, improving stability, security, and performance.

At a high level, Chromium aims to use separate processes for different instances of web sites when possible.

A web site instance is a group of documents or workers that must share a process with each other to support their needs, such as cross-document scripting.

For stability, putting web site instances in separate processes limits the impact of a renderer process crash or hang, allowing other content to continue working.

For performance, this allows different web site instances to run in parallel with better responsiveness, at the cost of some memory overhead for each process.

For security, strictly using separate processes for different web sites allows significantly stronger defenses against malicious web sites.

Chromium's multi-process architecture can support Site Isolation, where each renderer process is only allowed to access data from a single site.

Site Isolation involves:-

Locked Renderer Processes: A renderer process can be limited to documents and workers from a single web site or origin, even if such documents are in iframes.

Browser-Enforced Restrictions: The privileged browser process can monitor IPC messages from locked processes to limit their actions or access to site data.

Network Response Limitations: Chromium can ensure that locked renderer processes are only allowed to receive sensitive data.

Abstractions and Implementations:-

Chromium uses several abstractions to track which documents and workers need synchronous access to each other, as a constraint for process model decisions.

Security Principal: In security terminology, a principal is an entity with certain privileges. Chromium associates a security principal with execution contexts (e.g., documents, workers) to track which data their process is allowed to access.

Principal Instance: A principal instance is the core unit of Chromium‘s process model. Any two documents with the same principal in the same browsing context group must live in the same process, because they have synchronous access to each other’s content. This access includes cross-document scripting and synchronous communication through shared memory.

If such documents were in different processes, data races or deadlocks would occur if they concurrently accessed objects in their shared DOM or JavaScript heaps.

Note that the user may visit multiple instances of a given principal in the browser, sometimes in unrelated tabs (i.e., separate browsing context groups). These separate instances do not need synchronous access to each other and can safely run in separate processes

Browsing Context Group: A browsing context group is a group of tabs and frames (i.e., containers of documents) that have references to each other. Any two documents within a browsing context group may find each other by name, so it is important that any same-principal documents in the group live in the same process.

In other words, there is only one principal instance per principal in a given browsing context group. Note that a tab may change its browsing context group on some types of navigations (e.g., due to a Cross-Origin-Opener-Policy header, browser-initiated cross-site navigations, and other reasons).

That's all for now!!

In the upcoming post we will discuss about modes and availability in different devices of these processes.