Merge branch 'main_publish' into 'new-clause-4'

<mark>Editor's Note: Proposal to put together a common term sheet for all verticals developed in CYBER-EUSR.</mark>

browser profiles: private browsing sessions, temporary guest profiles or user managed profiles that may be used for separating principals or use-cases

effective Top-Level Domain: a domain suffix, under which independent tenants may register subdomains

public suffix list: list of all eTLDs

registrable domain: subdomain exactly one level below an eTLD, such that the domain and all further sub-domains are registered to a single tenant

site: logical security boundary defined by scheme and registrable domain

third-party cookies: cookies keyed to a site other than the top-level site

Origin: An origin in browser products is the compound of the scheme, host and port of a web resource. When a web resource defined as valid in the user documentation cannot be formed into a meaningful combination of host, scheme and port, the product constructs a synthetic origin uniquely identifying the resource.

Same-origin policy: A security model in browser products used to determine whether assets and state should be shared or not between web page execution contexts.

## 3.2 Symbols

`CRA   Cyber Resilience Act`  

`CVE   Common Vulnerabilities and Exposures`  

`DB    Database`  

`eTLD  Effective Top-level Domain`

`EDR   Endpoint Detection and Response`  

`DHCP  Dynamic Host Configuration Protocol`  

`GDPR  General Data Protection Regulation`  

`SIEM  Security Information and Event Management`  

`SIF   Social Interactive Function`  

`SOAR  Security Orchestration Automation and Response`  

`SOP   Same-origin policy`

`TLS   Transport Layer Security`  

`TUF   The Update Framework`  

`UC    Use Case`  

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

**[REQ-KEV-1]**:The product shall incorporate only components, including third party and open source elements, for which no known exploitable vulnerabilities exist at the time of release. 

Note: The manufacturer may relay on documentation in the form of an Software Bill of Materials (SBOM) as well as reasoning of why known vulnerabilities are not exploitable under the applicable, expected operational environment. 

**[REQ-KEV-2]**:In accordance with the requirement to apply effective and regular tests to the security of the product, the product shall be tested to demonstrate the absence or mitigation of known exploitable vulnerabilities.

Note: To demonstrate compliance, the manufacturer may rely on manual security testing (e.g., penetration testing), automated vulnerability scanners, or a combination of both, depending on what is most comprehensive and technically feasible for the product's technology stack.

**[REQ-MEM-KEV-1]**: Web browser interfaces that are, or could potentially be, exposed to untrusted data shall undergo automated dynamic analysis to identify vulnerabilities (for example, via techniques such as fuzzing in an environment that enables the detection of memory access errors).

**[REQ-MEM-KEV-2]** The web browser source code shall undergo automated static analysis to identify vulnerabilities (for example, via LLM code analysis). 

**[REQ-MEM-KEV-3]** The web browser source code shall make use of languages, language features, libraries, and/or automation-enforced coding conventions that prevent well-known classes of vulnerability from being introduced (for example, via the use of memory safe languages, bounds checked container classes, restricting use of raw pointers).

## 5.3 Secure by default configuration

Proposed ESR code SBD

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

**[REQ-STORE-SU-1]** The product shall maintain the validity of data stored to disk across updates.

**[REQ-STORE-SU-2]** The product shall update the Public Suffix List regularly.

## 5.5 Authentication and access control

Proposed ESR code: AAC

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

**[REQ-STORE-ACC-1]** The product shall store data and enforce access according to the Same Origin Policy.

**[REQ-STORE-ACC-2]** The product shall not share or make data available across browser profiles.

**[REQ-SOP-AAC-1]**: The product shall deny access in one origin to all parts of another origin, except as defined in the user documentation.

Example: Web pages may load images from other origins, message using `window.postMessage` and may access limited properties such as `Location`. Web pages may not access the document object model or global Window scope from scripts of other origins. The user documentation references industry standards with implementation recommendations and additinal examples.

**[REQ-SOP-AAC-2]**: The product shall isolate origin-specific data such as cookies, Web Storage, IndexedDB and any other storage, ensuring it's not available to any other origin, except through protocol-determined methods.

<mark>Editor's note: is this limited to top-level pages?</mark>

<mark>Editor's note: are cookies awkward here? in what way?</mark>

<mark>Editor's note: need to add examples for cross domain storage access is allowed, etc.</mark>

## 5.6 Confidentiality

Proposed ESR code: CON

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

**[REQ-STORE-CON-1]** The product shall not send third-party cookies by default. They may be supported consistent with the `Partitioned` attribute.

NOTE: The product can provide users the ability to share third-party cookies, whether on a case-by-case basis through interaction as in Storage Access API or throughout their browser profile through configuration.

**[REQ-STORE-CON-2]** The product shall make use of OS access control, encryption methods or other mechanisms to ensure confidentiality of disk-stored data.

**[REQ-STORE-CON-3]** The product shall store browser cache data such that they are keyed to both top-level site and resource.

**[REQ-SOP-CON-1]**: The product shall only allow scripts to access the body of a cross-origin HTTP response where the source origin has opted to allow access by the requesting origin.

Example: Implementation of Cross-Origin Resource Sharing (CORS)

**[REQ-SOP-CON-2]**: Where the product allows cross-origin embedding of a resource in documents, the product shall limit information about that resource as specified in the technical documentation.

Example: Cross-origin embedding of the height and width of an image are exposed to scripts, while the contents of the image are not exposed unless CORS is enabled by the source origin of the image.

<mark>Editor's note: In principle, CON-1 might imply CON-2, and maybe we could put this all in assessment steps. Or maybe better to be explicit?</mark>

## 5.7 Integrity

Proposed ESR code: INT

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

**[REQ-ISO-AP-1]**: The product shall take steps to reduce the risk that errors or crashes in one website running in one tab cause other, unrelated tabs to crash.

**[REQ-ISO-AP-2]**: The product shall take steps, on a best-effort basis, to save the state of running websites such that they can be restored later following an incident.

<mark>Editor's note: Need conclusion wrt this being about page state such as scroll position, form data or storage or unspecific or more specific.</mark>

**[REQ-STORE-AVA-1]** The product shall retain data stored to disk in case of a crash and make it available upon browser restart.

## 5.10 Impact Minimisation

Proposed ESR code: IM

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

**[REQ-ISO-IM-1]**: The product's technical documentation shall describe all public network protocols implemented by the product, or include references to such protocols. These protocols shall be described in publicly available specifications, or be described with sufficient technical detail to permit an independent implementation.

<mark>Editor's note: Discussion around this was not concluded. HAS did not like asking for technical docs. Sam raised asking for user docs instead. Andrew suggested that in some circumstances it's not needed at all, eg explicit cooperation between client and server. Daniel E had concerns about lowering the bar even in cooperation contexts.</mark>

## 5.11 Minimisation of Attack Surfaces

Proposed ESR code: MAS

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.

**[REQ-ISO-MAS-1]**: The product's technical documentation shall describe all web-exposed interfaces, or include references to such descriptions. These interfaces shall be described in publicly available specifications, or be described with sufficient technical detail to permit an independent implementation.

**[REQ-SOP-MAS-1]**: The product shall enforce restrictions from a source origin on how its resources may be used across origins, as defined in the user documentation.

Example: Usage of cross-origin options such as `X-Frame-Options` or `Cross-Origin-Resource-Policy` allow source origins to specify usage constraints for products to receive and enforce.

**[REQ-MEM-MAS-1]** The web browser shall not include unneeded functionality that is, or could potentially be, exposed to untrusted data (for example, shall not expose code implementing an unused file format).

**[REQ-MEM-MAS-2]** The web browser shall validate or otherwise render harmless untrusted data before exposing it to complex parsing functionality implemented in a non-memory safe language, or in a privileged process.

## 5.12 Exploitation Mitigation Mechanisms

Proposed ESR code: EMM

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

**[REQ-ISO-EMM-1]**: The product shall separate certain product components from each other to reduce the scope of exploits, using process isolation or similar industry standard mitigations.

**[REQ-ISO-EMM-2]**: The product shall isolate different sites from each other, including from side-channel attacks.

**[REQ-ISO-EMM-3]**: The product shall reduce the privileges of its various components with respect to the operating system to the level required to perform their tasks.

**[REQ-MEM-EMM-1]** The web browser shall include assertions to the correctness of program state, which fail safely (for example, an unexploitable crash) when violated (for example, via the use of ASSERT() or CHECK() statements).

**[REQ-MEM-EMM-1]** Portions of the web browser that are not implemented in a memory safe language shall employ mitigations to reduce exploitability of memory safety vulnerabilities (for example, via compiler flags, hardened allocators).

**[REQ-MEM-EMM-1]** The web browser should make use of mitigation technologies provided by the operating system and/or hardware when appropriate  (for example, hardware-assisted memory tagging, ASLR).

**[REQ-MEM-EMM-1]** Web browser processes should only have access to a restricted set of operating system capabilities and privileges as required by their function (e.g. via sandboxing, system call filtering)

<mark>Editor's note: Should sandboxing generally be considered by memory safety, or isolation?</mark>

## 5.13 Logging and Monitoring

Proposed ESR code: LOG

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

**[REQ-STORE-LOG-1]** The product shall provide an interface for viewing information about stored data at a granularity of site or narrower (e.g., origin).

## 5.14 Data Removal and Transparency

Proposed ESR code: DRT

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

**[REQ-STORE-DRT-1]** The product shall ensure when storage data is deleted, it uses appropriate APIs that ensure the data is deleted from the underlying storage device.

**[REQ-STORE-DRT-2]** The product shall provide reset functionality that removes all stored data across all sites and browser profiles.

**[REQ-STORE-DRT-3]** The product shall have an interface for deleting storage at a granularity of site or narrower (e.g., origin).

## 5.15 Vulnerability Handling

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