Merge branch 'extensions' into 'main_publish'

<mark>Editor's Note: If there is a matrix mapping the use cases to the technical requirements of the standard, it should be inserted in this clause. Alternatively, there can be such a matrix/mapping in each subclause below.</mark>

The extension-related requirements apply to products that offer the installation of third party extensions. Products not offering third party extension support are out of scope for those requirements.

## 5.2 No known exploitable vulnerabilities

> NOTE: It is proposed that a cross-vertical task force could work on the technical requirements to be included in this clause.

## 5.3 Secure by default configuration

Proposed ESR code SBD

Applicability: Web browsers which maintain their own root store, rather than using the OS's root store.

**[REQ-EXT-SBD-1]**: The product shall execute extensions with minimal privileges by default.

Example: The extension execution process runs with the least amount of operating system privileges and least amount of capabilities necessary for its purpose.

<mark>Editor's note: Could home in MAS? or IM?</mark>

**[REQ-EXT-SBD-2]**: The product shall execute extensions in an isolated context.

<mark>Editor's note: This covers the default configuration - the exploitation mitigation is covered in section 5.12.</mark>

<mark>Editor's note: Content scripts can be run in different ways, eg Chrome's isolated worlds vs Firefox's xray-vision. Open question if text change needed due to different ways of handling this where "isolated" maybe isn't the all encompassing term.</mark>

## 5.4 Secure Updates

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (c).

**[REQ-TLS-UPD-1]**: The web browser's root store shall be kept up to date appropriately, based on the manufacturer's risk assessment and documented policy.

**[REQ-TLS-SU-1]**: The web browser's root store shall be kept up to date appropriately, based on the manufacturer's risk assessment and documented policy.

Applicability: Web browsers which maintain their own root store, rather than using the OS's root store.

**[REQ-EXT-SU-1]**: The product shall support automatic updates of extensions, and before installing an update shall cryptographically verify the update.

## 5.5 Authentication and access control

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (d).

**[REQ-EXT-AAC-1]**: The product shall enforce a granular permission model for the extension.

Example: Permissions divided such that an extension can request and access the minimum required capabilities for it purpose.

**[REQ-EXT-AAC-2]**: The product shall grant an extension only the permissions declared in its manifest and approved by the user.

**[REQ-EXT-AAC-3]**: The product shall prompt the user with the manifest-declared permissions prior to installation, listing the capabilities and implications of each permission, and allow the user to approve or decline the installation.

**[REQ-EXT-AAC-4]**: The product shall allow the user to review and revoke extension access to specific origins after installation.

**[REQ-EXT-AAC-5]**: The product shall require additional consent for permissions granting developer tools access or network interception, beyond what's required for standard permissions.

**[REQ-EXT-AAC-6]**: The product shall ensure isolation between the execution and data contexts of different extensions.

## 5.6 Confidentiality

Example: Implementation of HSTS [i.8], active mixed content blocking [i.9], and HTTPS-First loading strategies.

**[REQ-EXT-CON-1]**: The product shall prevent secrets stored by extensions from being read by other extensions or by web content.

## 5.7 Integrity

Proposed ESR code: INT

Note: TLS-related clauses contribute to integrity.

**[REQ-EXT-INT-1]**: The product shall cryptographically verify extensions before installation and update.

## 5.8 Data Minimisation

Proposed ESR code: DM

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (h).

**[REQ-EXT-AP-1]**: The product shall make the best effort to prevent the ability of an extension to make the product unavailable.

## 5.10 Impact Minimisation

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (i).

**[REQ-EXT-IM-1]**: If the product is running with elevated system privileges, extensions will be prevented from executing with those elevated privileges.

**[REQ-EXT-IM-2]**: The product shall permit extensions to communicate with native applications only when declared in the extension manifest and the native application is configured according to the product requirements for doing so.

**[REQ-EXT-IM-3]**: The product shall permit extensions to communicate with system webservers when the localhost origin is declared in the extension manifest.

## 5.11 Minimisation of Attack Surfaces

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (j).

**[REQ-EXT-MAS-1]**: The product's extension APIs shall be documented, and specify for each API the purpose, inputs and outputs, permissions required, its security-related behavior, and the platforms the API is available on.

**[REQ-EXT-MAS-2]**: The product shall support enterprise policy controls allowing administrators to disable the extension feature entirely, or specify an allow-list of extensions.

Applicability: Enterprise browsers (UC-INST)

**[REQ-EXT-MAS-3]**: The product shall enforce the scope of extension resources available to web content, as declared in the manifest.

Example: Extensions may bundle assets in their packages, and browsers may allow them provide web pages with access to static assets, such as images, scripts and styles. Extensions declare these assets in their manifest, and browsers restrict access to only the declared assets.

## 5.12 Exploitation Mitigation Mechanisms

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (k).

**[REQ-EXT-EMM-1]**: The product shall enforce a Content Security Policy for extension pages and scripts injected into web content.

**[REQ-EXT-EMM-2]**: The product shall validate an extension's manifest before installation and update, reject malformed manifests, and ignore unexpected manifest content.

## 5.13 Logging and Monitoring

Proposed ESR code: LOG

**[REQ-TLS-LOG-1]**: The web browser shall present a user interface giving visibility into the security properties of the connection, including the origin.

**[REQ-EXT-LOG-1]**: The product shall provide the user the ability to identify running extensions, and to observe their activity.

## 5.14 Data Removal and Transparency

Proposed ESR code: DRT

Applicability: Web browsers which allow changing TLS-related settings.

**[REQ-EXT-DRT-1]**: The product shall enable the removal of individual extensions, which shall delete all data associated with the extension, and revoke all permissions granted to it.

## 5.15 Vulnerability Handling

    - Untreated risks: information leaks to and across websites, actions may be taken which are not what the user wanted

    - The harmonised standard is expected to deliver technical solutions within the generally acknowledged state of the art and not in areas still rapidly evolving.

## O.3 Products with a third party extension feature

Certain products on the market at the time of this writing provide a feature to allow the installation and execution of third party code, known as extensions, to extend the functionality of the product, typically using an industry standard.

- Publishing and distribution of extensions: The requirements for extension publishing and distribution are out of scope. An extension store is not a Remote Data Processing Solution in the CRA, because web browser products can operate without access to the store, and extensions may be installed from outside any store under some browsers and conditions. In-product mechanisms, such as blocklists of malicious extensions, are in scope.

# Annex V (informative): Guide for derivative web browsers

## V.1 General