resolved comments

<span id="_ref_i.9"></span><a name="#_ref_i.9">[i.9]</a>[Mixed Content (W3C Candidate Recommendation Draft)](https://www.w3.org/TR/mixed-content/), W3C, 23 February 2023

<span id="_ref_i.10"></span><a name="#_ref_i.10">[i.10]</a>[Threat Model for the Web (W3C Editor's Draft)](https://w3c.github.io/threat-model-web/), W3C, 11 May 2026

<span id="_ref_i.11"></span><a name="#_ref_i.11">[i.11]</a>[HTML (WHATWG Living Standard)](https://html.spec.whatwg.org/multipage/), WHATWG, 11 May 2026

<span id="_ref_i.12"></span><a name="#_ref_i.12">[i.12]</a>[Fetch (WHATWG Living Standard)](https://fetch.spec.whatwg.org/), WHATWG, 08 May 2026

<span id="_ref_i.13"></span><a name="#_ref_i.13">[i.13]</a>[Content Security Policy Level 2 (W3C Reccomendation)](https://www.w3.org/TR/CSP2/), W3C, 15 December 2016

<span id="_ref_i.14"></span><a name="#_ref_i.14">[i.14]</a>[Secure Contexts (W3C Candidate Reccomendation Draft)](https://www.w3.org/TR/secure-contexts/), W3C, 10 November 2023

<span id="_ref_i.15"></span><a name="#_ref_i.15">[i.15]</a>[Subresource Integrity (W3C Working Draft)](https://www.w3.org/TR/sri-2/), W3C, 20 March 2026

<span id="_ref_i.16"></span><a name="#_ref_i.16">[i.16]</a>[RFC 8996: Deprecating TLS 1.0 and TLS 1.1](https://datatracker.ietf.org/doc/html/rfc8996), IETF, March 2021

<span id="_ref_i.17"></span><a name="#_ref_i.17">[i.17]</a>[RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile](https://datatracker.ietf.org/doc/html/rfc5280), IETF, May 2008

<span id="_ref_i.18"></span><a name="#_ref_i.18">[i.18]</a>[RFC 6962: Certificate Transparency](https://datatracker.ietf.org/doc/html/rfc6962), IETF, June 2013

<span id="_ref_i.n"></span><a name="_ref_i.n">[i.n]</a> &lt;Standard Organization acronym> &lt;document number> (&lt;version number>): "&lt;Title>".

<mark>Editor's Note: The EC advises that the references between verticals should be informative.</mark>  

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

## 4.1 Intended Purpose

## 4.0 Introduction

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 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.

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 mediate the interaction between them and the 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.1 Product Functions

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.

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

The Essential Functions of a Web Browser may include:

- Retrieve Web Content

- 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

- Store data

- Receive and process user input

- Deliver and apply software updates

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

## 4.2 Product Architecture

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.

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. The following high-level Data Flow Diagram (DFD) elaborates on the DFD presented in W3C Threat Model for the Web [\[i.10\]](#_ref_i.10).

<figure id="threat-model">

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

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

    <img src="./media/DFDGeneral.drawio.svg">

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

</figure>

- **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.

- **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 (It is worth noting that, in some implementations, these functions may not be carried out by the privileged web browser process alone but might instead be assigned to multiple processes). 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 website 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 services.** 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.

- **I/O.** Modern web browsers typically also isolate helper functionalities such as, networking stack, and other utilities into separate isolated processes to improve security and reliability.

## 4.3 Operational 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.1 General description

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 assumes that the resources they handle are inherently untrusted.

### 4.3.1 Security Functions

### 4.3.2 Security Functions

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.

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:

- **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.

- **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 [\[i.11\]](#_ref_i.11), and WHATWG Fetch Living Standard [\[i.12\]](#_ref_i.12).

- **Controlled relaxation of SOP.** A security property whereby the Same Origin Policy can be relaxed based on server-defined policies, for example, in accordance with Cross Origin Resource Sharing as defined in WHATWG Fetch Living Standard [\[i.12\]](#_ref_i.12).

- **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 [\[i.13\]](#_ref_i.13) 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 Secure Contexts [\[i.14\]](#_ref_i.14), is mediated through a permission system that requires express user permission.

- **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 [\[i.15\]](#_ref_i.15).

- **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 [\[i.7\]](#_ref_i.7) and successor standards, and the rejection of connections which use protocol versions identified as deprecated in IETF standards track RFCs, including RFC 8996 [\[i.16\]](#_ref_i.16) and successor standards.

- **Certificate validation.** A security function that includes validation of certificate chains, including certificate path as defined in IETF RFC 5280 [\[i.17\]](#_ref_i.17), and enforces Certificate Transparency as defined in IETF RFC 6962 [\[i.18\]](#_ref_i.18).

### 4.3.2 Distribution of Security Functions

### 4.3.3 Distribution of Security Functions

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

For each security function, a web browser may:

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

- **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.3.3 Security functions provided outside the product's context

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

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:

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.3.4 Security functions provided to other components

#### 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.

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

- General consumers

- General public

- Children and protected users

- Vulnerable adults

- Users of the web with respect to sensitive data

- Professionals in all fields of work

- Workers in critical infrastructure

- Users with accessibility needs

## 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.

This list is non-exhaustive, but this standard provides mitigations to risks for the following use cases:

### 4.5.1 Standalone browser use cases

# Annex B (informative): Cybersecurity threat landscape, risk identification and assessment methodology

This Annex applies a "state of the art" risk assessment methodology to the Product in scope of the present document, to identify threats, evaluate the risks and define security profiles applicable to the different use cases of the product context.

This Annex applies a "state of the art" risk assessment methodology to the Product in scope of the present document, to identify threats, evaluate the risks and define security profiles applicable to the different use cases of the product context. Threat elicitation is supported by a Data Flow Diagram of each product use case identified in Clause 4, namely: Consumer web browsers, Enterprise web browsers, and Embedded web browsers.   

Consider defining a common sub-structure.

## Asset Inventory

# Annex C (informative): Relationship between the present document and any related ETSI standards (if any, e.g. EN 303 645)