WARNING! Gitlab maintenance operation scheduled for Thursday, 18 June between 19:00 and 20:00 (CET). During this time window, short service interruptions (less than 5 minutes) may occur. Thank you in advance for your understanding.
@@ -637,7 +637,7 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
<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.
**[REQ-STORE-AP-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
@@ -725,7 +725,7 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
**[REQ-EXT-LOG-1]**: The product shall provide the user the ability to identify which user-installed extensions are currently running, and the permissions in effect for each.
**[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).
**[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).
**[REQ-PWR-LOG-1]** The web browser shall provide a user interface listing the Powerful Web Platform Features granted or denied to the web page being displayed.
@@ -744,7 +744,7 @@ Applicability: Web browsers which allow changing TLS-related settings.
**[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).
**[REQ-STORE-DRT-3]** The product shall have a user interface for deleting storage at a granularity of site or narrower (e.g. origin).
**[REQ-PWR-DRT-1]** The web browser shall provide a user interface allowing revocation of previously granted permissions for Powerful Web Platform Features.
@@ -779,6 +779,8 @@ This clause provides objective and reproducible assessment criteria to determine
For each cybersecurity requirements defined in Clause 5, the following clauses specify assessment criteria to determine if the technical requirement is met.
Where Assessment Activities are presented as a numbered list, they are to be carried out sequentially. Where the Assessment Activities are presented as bullet points, the order of execution is not critical to the assessment, and can be undertaken in any order.
Please ensure that there is an easy, clear and unambiguous mapping of the requirements in clause 5 to the relevant assessment criteria in clause 6.
The assessment criteria for each security requirements are described in a structured manner, as follows:
@@ -1148,6 +1150,64 @@ The following steps are to be carried out in order:
**Supporting Evidence:**
- Product user interface per the documentation, showing the update status for an extension.
### [ACC-STORE-SU-1]
Assessment of [REQ-STORE-SU-1]
-**Assessment Reference:** The product shall maintain the validity of data stored to disk across updates.
-**Assessment Objective:** Assess whether the product maintains the validity of data stored to disk across updates.
-**Assessment Preparation:**
- Reset browser to factory default settings.
- Prepare tooling to initiate an update.
- Prepare tooling that will provide visibility into data stored in the browser.
- Load data into browser to cover available storage mechanisms, including LocalStorage, Cookie storage and IndexedDB.
-**Assessment Activities:**
1. Making use of tooling, verify the data that has been added to storage.
2. Perform the update of the browser.
3. Verify whether the data is available in storage after the update.
-**Assignment of Verdict:**
-**Pass**:
- The data is available prior to browser update.
- The data available subsequent to browser update is identical.
-**Fail**: Any of the above are not fulfilled.
-**Supporting Evidence**:
- Screenshot(s) or log output from tooling to demonstrate each verdict
### [ACC-STORE-SU-2]
Assessment of [REQ-STORE-SU-2]
-**Assessment Reference:** The product shall update the Public Suffix List regularly.
-**Assessment Objective:** Assess whether the product updates the public suffix list regularly.
-**Assessment Preparation:**
- Technical documentation containing public suffix list update policy.
- Browser with out-of-date public suffix list, with known missing suffix.
- Identify methodology or tooling to test Public Suffix List entries, e.g.
- Set a cookie at the PSL level, or
- Tooling to inspect and output PSL.
-**Assessment Activities:**
1. Verify state of the missing PSL suffix.
2. Await update according to policy.
3. Verify the updated state of the missing PSL suffix.
-**Assignment of Verdict:**
-**Pass**:
- Testing initially shows known-missing entry as not present in internal list of eTLDs.
- After update period, testing shows known-missing entry is present in internal list of eTLDs.
-**Fail**: Any of the above are not fulfilled.
-**Supporting Evidence**:
- Screenshot(s) or log output from tooling to demonstrate each verdict
## 6.5 Authentication and Access Control
Proposed ESR code: AAC
@@ -1318,12 +1378,45 @@ The following steps are to be carried out in order:
**Supporting Evidence:**
- Extension console log.
### [ACC-STORE-AAC-1]
Assessment of [REQ-STORE-AAC-1]
-**Assessment Reference:** The product shall store data and enforce access according to the Same Origin Policy.
-**Assessment Objective:** Assess whether the product presents stores and enforces access according to Same Origin Policy.
-**Assessment Preparation:**
- Prepare tooling that will provide visibility into data available for a given context.
- Website hosted on origin A, that will provide storage data.
- Website hosted on origin B, that will provide storage data.
- Reset browser to factory default settings.
-**Assessment Activities:**
1. Navigate to the website on origin A.
2. Making use of tooling, verify the data is added to storage, and is available in the context.
3. Navigate to the website on origin B.
4. Verify that the data set when accessing the first site is unavailable in the new context.
5. Verify that the data set when accessing the second site is available in the new context.
6. Navigate back to the website on origin A.
7. Verify that the data set by the site is still available.
-**Assignment of Verdict:**
-**Pass**:
- When site adds data to storage it is available.
- When the site looks for data, it does not see data from the other origin
- When the second site sets data it is also available.
- When navigating back to the first site, the data set when visiting initially will still be available.
-**Fail**: Any of the above are not fulfilled.
### [ACC-STORE-ACC-3]
-**Supporting Evidence**:
- Screenshot(s) or log output from tooling to demonstrate each verdict
### [ACC-STORE-AAC-2]
Assessment of [REQ-STORE-ACC-3]
Assessment of [REQ-STORE-ACC-2]
-**Assessment Reference:** The product shall enforce Same Origin Policy access control for storage data outside rendering processes.
-**Assessment Reference:** The product shall not share or make data available across browser profiles.
-**Assessment Objective:** Assess whether the product enforces separation of data across browser profiles.
@@ -1348,8 +1441,7 @@ Assessment of [REQ-STORE-ACC-3]
-**Fail**: Any of the above are not fulfilled.
-**Supporting Evidence**:
- Screenshot or log output from tooling at each step to demonstrate.
- Screenshot(s) or log output from tooling to demonstrate each verdict
## 6.6 Confidentiality
@@ -1498,6 +1590,100 @@ The following steps are to be carried out in order:
**Supporting Evidence:**
- Console log from extension and from the web page.
### [ACC-STORE-CON-1]
Assessment of [REQ-STORE-CON-1]
-**Assessment Reference:** The product shall not send third-party cookies by default. They may be supported consistent with the `Partitioned` attribute.
-**Assessment Objective:** Assess that third-party cookies are not sent by default.
-**Assessment Preparation:**
- Reset browser to factory default settings.
- Prepare tooling to view browser http requests.
- Prepare tooling to view stored cookies.
- Website hosted on site A, that provides cookies.
- Website hosted on site B, with :
- embedded resources from site A,
- iframe from site A that sets a `Partitioned` cookie, and
- iframe from site A that sets a cookie without the `Partitioned` keyword.
-**Assessment Activities:**
1. Visit website on site A, and verify the cookies that have been set.
2. Visit website on site B, and verify whether the cookies are sent to site A when loading resources.
3. Verify whether either of the cookies from site A iframes embedded on site B are stored.
4. Reload website on site B, and verify the cookies sent to site A when loading resources.
5. Visit website on site A, and verify whether the cookies sent.
-**Assignment of Verdict:**
-**Pass**:
- The cookies are set successfully for site A.
- The cookies are not sent to site A, when loading site B.
- The cookie set within an iframe without a `Partitioned` keyword is not stored.
- The cookie set within an iframe with a `Partitioned` keyword can be stored.
- On reloading the site, cookies from site A are not sent to site B.
- If the `Partitioned` keyword cookie was stored, it can be sent to the site A iframes and resources within site B.
- When re-visiting the website on site A, the cookies only cookies sent are those set directly visiting that site.
-**Fail**: Any of the above are not fulfilled.
-**Supporting Evidence**:
- Screenshot(s) or log output from tooling showing request data to demonstrate each verdict.
- Screenshot(s) or log output from tooling showing cookie storage state to demonstrate each verdict.
### [ACC-STORE-CON-2]
Assessment of [REQ-STORE-CON-2]
-**Assessment Reference:** The product shall make use of OS access control, encryption methods or other mechanisms to ensure confidentiality of disk-stored data.
-**Assessment Objective:** Assess that OS access control, encryption methods and other mechanisims are used to ensure confidentiality of disk-stored data.
-**Assessment Preparation:**
- Access to product source code.
- Access to OS documentation.
-**Assessment Activities:**
- Identify available access control methods for OS.
- Identify data written to disk by product.
- Verify that the data stored uses appropriate access control mechanisms.
-**Assignment of Verdict:**
-**Pass**: Each instance of data written to disk is using appropriate access control.
-**Fail**: The above is not fulfilled.
-**Supporting Evidence**:
- List of disk-stored data from product.
- Corresponding list of OS access control mechanisms used and justification for why each is appropriate.
### [ACC-STORE-CON-3]
Assessment of [REQ-STORE-CON-3]
-**Assessment Reference:** The product shall store browser cache data such that they are keyed to both top-level site and resource.
-**Assessment Objective:** Assess that browser storage cache data is keyed to both top-level site and resource.
-**Assessment Preparation:**
- Website hosted on site A, including resource A from site C.
- Website hosted on site B, including resource A from site C.
- Tooling to inspect browser cache.
- Tooling to inspect request data.
- Reset browser to factory default settings.
-**Assessment Activities:**
1. Visit the website hosted on site A and inspect browser cache.
2. Visit the website hosted on site B, verify request data and inspect browser cache.
-**Assignment of Verdict:**
-**Pass**:
- If resource A from site C is stored in browser cache, it should keyed to site A.
- Request data from site B should include resource A from site C. It should not have been retrieved from cache.
- If resource A from site C is stored in browser cache, it may be stored twice, and can be keyed against both site A and site B.
-**Fail**: Any of the above are not fulfilled.
-**Supporting Evidence**:
- Screenshot(s) or log output from tooling showing browser cache content to demonstrate each verdict.
- Screenshot(s) or log output from tooling showing request and response for resource A, when visiting site B, to demonstrate the corresponding verdict.
## 6.7 Integrity
@@ -1574,6 +1760,33 @@ The following steps are to be carried out in order:
- Process logs.
- Product documentation
### [ACC-STORE-AP-1]
Assessment of [REQ-STORE-AP-1]
-**Assessment Reference:** The product shall retain data stored to disk in case of a crash and make it available upon browser restart.
-**Assessment Objective:** Assess that in the case of a crash the data stored to disk is made available upon browser restart.
-**Assessment Preparation:**
- Prepare a method to induce crash
- Prepare tooling to inspect the data stored within the browser.
- Website that will store data
-**Assessment Activities:**
1. Visit website and verify it has set data.
2. Follow steps to induce crash
3. Restart browser
4. Verify data exists in browser.
5. Visit website and verify that the data is available to it.
-**Assignment of Verdict:**
-**Pass**: Data set by the website during the first step is presented back to site during final step.
-**Fail**: The above is not fulfilled.
-**Supporting Evidence**:
- Screenshot(s) or log output from tooling to demonstrate verdict.
## 6.10 Impact Minimisation
Proposed ESR code: IM
@@ -2038,6 +2251,46 @@ The following steps are to be carried out in order:
**Supporting Evidence:**
- User interface captures.
### [ACC-STORE-LOG-1]
Assessment of [REQ-STORE-LOG-1]
-**Assessment Reference:** The product shall provide an interface for viewing information about stored data at a granularity of site or narrower (e.g. origin).
-**Assessment Objective:** Assess that the product provides an interface for viewing information about stored data at a granularity of site or narrower.
-**Assessment Preparation:**
- Prepare tooling to inspect the data stored within the browser.
- User documentation describing process for deleting data.
- Website on site A that will store data, including:
- cookie data
- LocalStorage
- IndexedDB storage
- Website on site B that will store data, including:
- cookie data
- LocalStorage
- IndexedDB storage
-**Assessment Activities:**
1. Visit website on site A, and verify it has set data.
2. Visit website on site B, and verify it has set data.
3. Follow user documentation for deleting data against site A.
4. Verify whether data for site A has been removed.
5. Verify whether data for site B has been removed.
-**Assignment of Verdict:**
-**Pass**:
- Data is set successfully during website vists.
- User documentation provides clear steps for removing data at a site level.
- Data is successfully removed from site A.
- Data is not removed from site B.
-**Fail**: Any of the above are not fulfilled.
-**Supporting Evidence**:
- Screenshot or log output from tooling at each step to show data.
- User documentation providing instructions for data removal.
## 6.14 Data Removal and Transparency
Proposed ESR code: DRT
@@ -2106,6 +2359,106 @@ The following steps are to be carried out in order:
**Supporting Evidence:**
- Storage and permission inspection before and after extension removal.
### [ACC-STORE-DRT-1]
Assessment of [REQ-STORE-DRT-1]
-**Assessment Reference:** The product shall ensure when storage data is deleted, it uses appropriate APIs that ensure the data is deleted from the underlying storage device.
-**Assessment Objective:** Assess that in cases of storage data deletion, the data is effectively deleted.
-**Assessment Preparation:**
- Access to product source code.
- Access to integration API documentation.
- Any required test tooling for verification of memory.
-**Assessment Activities:**
- Identify internal APIs that provide for the deletion of storage data.
- Identify all implementations of the APIs.
- Identify underlying system APIs used for data management, and their accompanying documentation.
-**Assignment of Verdict:**
-**Pass**:
- For each storage deletion API implementation, each has either
- System vendor documentation for the system API, providing guarantee of deletion, or
- Test that upon calling API, underlying data is deleted from memory.
-**Fail**: Any of APIs where one of the criteria are not fulfilled.
-**Supporting Evidence**:
- List of internal APIs implementations providing storage deletion.
- Corresponding list of underlying system APIs, and documentation their references.
- Screenshot(s) or log output from test tooling for each API in the case of manual test verification.
### [ACC-STORE-DRT-2]
Assessment of [REQ-STORE-DRT-2]
-**Assessment Reference:** The product shall provide reset functionality that removes all stored data across all sites and browser profiles.
-**Assessment Objective:** Assess that the reset functionality removes all stored data across all sites and browser profiles.
-**Assessment Preparation:**
- Prepare tooling to inspect browser profiles and data stored within browser.
- Website that will store instances of all data supported by the browser.
- Browser in factory default state.
- User documentation for performing browser reset.
- List of browser profile capabilities.
-**Assessment Activities:**
1. Verify with tooling only default browser profile exists, and no data is stored.
2. Create an instance of each supported browser profile.
3. Verify with tooling that each profile exists, and no data is stored.
4. With each profile, visit the website to set data.
5. Verify with tooling that each profile still exists, and has data stored.
6. Follow user documentation for performing reset.
7. Verify with tooling only default browser profile exists, and no data is stored.
-**Assignment of Verdict:**
-**Pass**: At each verification step, the expected profiles and data are present.
-**Fail**: The above is not fulfilled.
-**Supporting Evidence**:
- Screenshot(s) or log output from tooling at each step to show data.
- User documentation for performing reset.
### [ACC-STORE-DRT-3]
Assessment of [REQ-STORE-DRT-3]
-**Assessment Reference:** The product shall have a user interface for deleting storage at a granularity of site or narrower (e.g. origin).
-**Assessment Objective:** Assess that the product provides an interface for users to delete storage at a granularity of site or narrower.
-**Assessment Preparation:**
- Prepare tooling to inspect the data stored within the browser.
- User documentation describing process for deleting data.
- Website on site A that will store data, including
- cookie data,
- LocalStorage, and
- IndexedDB storage.
- Website on site B that will store data, including
- cookie data,
- LocalStorage, and
- IndexedDB storage.
-**Assessment Activities:**
1. Visit website on site A, and verify it has set data.
2. Visit website on site B, and verify it has set data.
3. Follow user documentation for deleting data against site A.
4. Verify whether data for site A has been removed.
5. Verify whether data for site B has been removed.
-**Assignment of Verdict:**
-**Pass**:
- Data is set successfully during website vists.
- User documentation provides clear steps for removing data at a site level.
- Data is successfully removed from site A.
- Data is not removed from site B.
-**Fail**: Any of the above are not fulfilled.
-**Supporting Evidence**:
- Screenshot(s) or log output from tooling at to demonstrate each verdict.
- User documentation providing instructions for data removal.
## 6.15 Vulnerability Handling
The assessment criteria specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[2\]](#_ref_2) shall be met for the product
