new cluase 4

<mark>Editor's Note: This clause is not normative.</mark>

## 4.0 Introduction

## 4.1 Intended Purpose

## 4.1 Product Functions

The intended purpose of a Web Browser is to access, retrieve, and render Web-based resources on behalf of an end user and display them via a Graphical User Interface. This includes everything from reading the news and online encyclopedias to accessing critical systems related to finance, government, healthcare, etc.

The intended purpose of standalone and embedded web browsers is to access and interact with the shared World Wide Web. This access includes everything from reading the news and online encyclopedias to accessing critical systems related to finance, government, healthcare, etc.

Browsers are general-purpose software: When presented with a Web browser, including an embedded one, user expectations are generally that they can trust it as their user agent to mediate the interaction between them and the Web.

Browsers are general purpose software: When presented with a web browser, including an embedded one, user expectations are generally that they can trust it as their "user agent" to do any internet-related task which they can access -- which, via links and other navigation mechanisms, expands to the whole web.

The breadth of reasonably forseeable uses for all Web browsers implies that there are many risks in common across use cases.

The breadth of reasonably forseeable uses for all web browsers implies that there are many risks in common across use cases.

### 4.1.1 Essential Functions

## 4.2 Product Architecture

To access websites and make them available to users, web browsers need components to handle the following:

- Networking (including HTTPS and TLS)

- HTML interpretation and rendering

- CSS layout

- JavaScript and WebAssembly code execution

The essential functions of a Web browser, as defined for the purposes of this standard, are those capabilities that shall remain operational to fulfill the browser's intended purpose. These do not vary between standalone and embedded browsers.

> NOTE: Java™ is the trade name of a programming language developed by Oracle Corporation.

The Essential Functions of a Web Browser may include:

- Image decoding

- SVG, MathML rendering

- GPU use, both to support rendering of HTML+CSS and for WebGPU

- Multimedia and video conferencing

- Camera, microphone and geolocation

- Retrieve Web Content

- Parse HTML and build DOM

- Style CSS and compute resource layout

- Execute JavaScript and WebAssembly

- Render images, media, and other embedded content

- Manage navigation and sessions

- Establish client-server connections

- Store data required for intended purpose functions

- Receive and process user input

- Deliver and apply software updates

TODO: Describe how these are put together, typical process architectures, include a diagram, etc.

## 4.3 Operational Environment

## 4.2 Product Architecture

### 4.3.1 General description

The specific architecture of Web browsers can vary based on factors such as vendor-specific implementation and use cases. This section focuses on the functionalities and trust boundaries of Web browsers that have significant security implications. A high-level Data Flow Diagram (DFD) of web browsers and their relationship with external entities is already proposed in W3C's Threat Model for the Web Editor's Draft. Without redefining already existing standardization work on the topic, this section structures a generic web browser threat model that outlines common architectural decisions, trust boundaries, and data flows often found in modern Web browsers.

A web browser may be used on any device which supports a user interface and sufficient resources to run the browser. This includes desktop and laptop computers, mobile phones, smart televisions, certain embedded devices, etc.

<figure id="threat-model">

    <img src="./media/DFD.png">

    <figcaption>Placeholder Data Flow Diagram (DFD)</figcaption>

</figure>

Different contexts where web browsers are used may have different risk profiles, for example:

- **Privileged Web browser process.** The Privileged Web browser process is the initial process launched by the OS and is typically responsible for managing subsequent processes, sessions, navigation, User Interface, and policies. This high-privilege process also generally serves as a central broker for permissions and other OS APIs, as well as access to local resources and OS filesystem. With direct OS access and elevated privileges, the Privileged Web browser process enforces the trust boundary between the OS and the Web browser itself.

- **Web-content execution.** Web resources are parsed and executed inside dedicated child processes. These processes handle untrusted web resources and should therefore be modeled under the assumption that the input they receive and interpret cannot be trusted. For this reason, each Web origin is typically assigned a dedicated sandboxed process that is isolated from all others. The resulting trust boundary separates web-executed content from the privileged Web browser process.

- **Storage.** Web browser typically also isolate and separate storage by origin. This includes cache, site data, session data, cookies, user credentials, and any other type of persistent or session-specific storage. This separation enforces the trust boundary between each origin-specific storage, preventing any origin from accessing another's stored data.

- **Utilities.** Modern Web browsers typically also isolate helper functionalities such as GPU, networking stack, and other utilities into separate isolated processes. This additional trust boundary between web-executed content and system functionalities limits the attack surface of a Web browser.

- Use of a browser embedded within a social media application, for external links

- Consumer use on a personal computer or smartphone

- "Enterprise" desktop/laptop computers within the context of an undertaking (including critical infrastructure)

## 4.3 Operational Environment

### 4.3.2 Physical/Hardware environment

Web browser serve as a medium for interaction between a system and the Web, retrieving Web resources and executing them client-side. Because of this, the operational environment in which they operate and the resources they handle should be considered to be inherently untrustworthy.

### 4.3.3 Logical/Software environment

### 4.3.1 Security Functions

### 4.3.4 Connectivity aspects

Regardless of use cases, vendor-specific implementations, and browser architecture specifics, all products with digital elements classified as Web browsers that fall within the scope of the present document should provide the security functions laid out in this section.

The security functions of a web browser include:

## 4.4 Distribution of Security Functions

- **Same Origin Policy.** A security function whereby scripts from one origin cannot access, read or manipulate data from another origin, as described in WHATWG HTML Living Standard, and WHATWG Fetch Living Standard.

- **Controlled relaxation of SOP.** A security property whereby the Same Origin Policy can be relaxed based on server-defined policies, in accordance with Cross Origin Resource Sharing as defined in WHATWG Fetch Living Standard.

- **Web Content Execution Isolation.** A security property whereby Web content from different origins is isolated into separate execution contexts.

- **Web resource content restriction.** A security control used to declare a set of content restrictions for a web resource as defined in W3C Content Security Policy Level 2 and successor standards.

- **Isolation and Sandboxing.** A security function whereby browser components are sandboxed and operate with minimal OS privileges in accordance with the principle of least-privilege, and logical isolation is enforced between different components (such as sites and execution contexts).

- **Permission management of Powerful Features.** A security function whereby access to powerful features, as defined in W3C Powerful Features and W3C Secure Contexts, is mediated through a permission system that requires express user consent.

- **Web resource integrity verification.** A security function whereby the integrity of retrieved Web resources is verified at web browser level, in accordance with the Subresource Integrity feature defined in W3C Subresource Integrity.

- **Automated Updates.** An security feature whereby the rollout of security updates is automated, ensuring that vulnerabilities are remediated in a timely manner.

- **TLS enforcement.** A security function that enforces support for current TLS versions as defined by IETF RFC 8446 and successor standards, and the rejection of connections which use protocol versions identified as deprecated in IETF standards track RFCs, including RFC 8996 and successor standards.

- **Certificate validation.** A security function that includes validation of certificate chains, including certificate path as defined in IETF RFC 5280, and enforces Certificate Transparency as defined in IETF RFC 6962.

<mark>This clause should address supply chain and integration issues - when a product contains another or is combined with another. The clause should explain in an informative manner how the security functions are distributed across the components included in the product. However, how to address this issue is still not consistent across draft verticals.</mark>

### 4.3.2 Distribution of Security Functions

<mark>- Formulation of requirements (see C IoT verticals)??</mark>

The aforementioned security functions inform the product-specific security requirements laid out in Clause 5.

<mark>- Assumptions about the integration environment??</mark>

For each security function, a web browser may:

<mark>- What recommendation we make for due diligence on integrated components?</mark>

- **Provide it itself.** In this case, the security function is provided as a native component within the Web browser’s codebase.

- **Require that it be provided by other parts of its context.** In this case, the browser delegates the provision of security functions to other components within its execution environment.

### 4.4.1 Security functions provided outside the product

### 4.3.3 Security functions provided outside the product's context

Across browsers and operating systems, different choices are made in different contexts about what is provided by the browser and what is implemented in the surrounding operating system and system libraries, with security functions performed at those other levels. For example:

Across web browsers and operating systems, different choices are made in different contexts about what is provided by the web browser and what is implemented in the surrounding operating system and system libraries, with security functions performed at those other levels. These may include for example:

- Some standalone browsers (e.g., on mobile platforms) are implemented with the use of a platform-provided embedded browser, subsuming most security functions

- Some standalone browsers (e.g., on mobile platforms) are implemented with the use of a platform-provided embedded browser, subsuming most security functions.

- Networking, including certificate validation and management, selection of algorithms, TLS broadly, etc.

- Image decoding, text rendering and Unicode handling (no inherent security function, but a historical source of exploitable vulnerabilities)

- Integrated password manager (may also be provided via an extension)

- Handling links which may be interpreted as references to native applications, whether via OS-registered origins or custom schemes

- Scoping permission to access camera, microphone, geolocation or other sensitive information

- etc. (This is list is not exhaustive.)

- Image decoding, text rendering and Unicode handling (no inherent security function, but a historical source of exploitable vulnerabilities).

- Integrated password manager (may also be provided via an extension).

- Handling links which may be interpreted as references to native applications, whether via OS-registered origins or custom schemes.

- Scoping permission to access camera, microphone, geolocation or other sensitive information.

- Web processes isolation may be enforced at OS kernel level.

In such cases, when functionality is implemented outside of the browser in such system libraries or operating systems, the responsibility for handling the risk is transferred to this library, following a risk assessment by the browser which integrates the OS/library that this is reasonable.

### 4.4.2 Security functions provided to other components

### 4.3.4 Security functions provided to other components

Web browsers provide a secure, trustworthy environment to render websites, which may be used as part of other products.

This property makes the web an ideal low-risk way to deliver application user interfaces.

## 4.5 Users

## 4.4 Users

Almost all computer users interact with web browsers at some point. This includes:

Almost all computer users interact with web browsers at some point. Users may include for example:

- General public

- Children, students

- Vulnerable adults

- Users of the web with respect to sensitive data

- General consumers

- Children and protected users

- Professionals in all fields of work

- Workers in critical infrastructure

- Users with accessibility needs

## 4.6 Use Cases

- Enterprise administrators

- Developers and technical users

## 4.5 Use Cases

The following use cases have been selected as the most common use cases for standalone and embedded web browser implementations. A detailed list of all potential Web browser use cases remains out of scope for the purposes of this standard.

### 4.6.1 Standalone browser use cases

### 4.5.1 Standalone browser use cases

**UC-CONS**: Standalone web browser for individual consumers

- Used for accessing the whole web, including sensitive/critical applications.

- Users are, in general, not educated or aware of cybersecurity issues.

- Installed on mobile phones, desktop and laptop computers, televisions, larger embedded devices, etc.

- Includes flexible settings, including high-risk features like developer mode, etc.

**UC-INST**: Standalone web browser for institutional or enterprise use, including critical infrastructure

- Central IT administration may set "enterprise policy" to configure security-related policies.

- Used in environments which are often taking other sorts of precautions, e.g., at the network/VPN level, physical access, etc.

- May be used to access "internal" websites which may have been developed with more or less attention to security, or which have special authentication needs.

### 4.6.2 Embedded browser use cases

### 4.5.2 Embedded browser use cases

**UC-ETAB**: Browser-like tab component for embedding in a larger application

- Used by embedding applications to enable linking to outside content while encouraging the user to return to the parent application

- Intended to facilitate access to just one website, omitting any UI to enter URLs or searches

- Grants access via links to the rest of the World Wide Web; users may "forget" that they are inside another application

- Typically no settings UI, and no integration into enterprise policy.

- Could share the state with the user's default browser.

- Could share the state with the user's default browser

# 5. Technical requirements for the Products

<mark>Editor's Note:This is the normative clause of the standard, defining the technical requirements to implement the Essential Security Requirements of the CRA regulation. The text of the regulation shall never be copied or interpreted in the standard.</mark>