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.
@@ -567,7 +567,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
@@ -646,7 +646,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 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).
**[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
@@ -663,7 +663,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).
## 5.15 Vulnerability Handling
@@ -767,16 +767,163 @@ Proposed ESR code SBD
Proposed ESR code: SU
### Assessment of [REQ-STORE-SU-1]
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:**
- Making use of tooling, verify the data that has been added to storage.
- Perform the update of the browser.
- Verify the data the data available in storage after the update.
-**Assignment of Verdict:**
- The data is available prior to browser update.
- The data available subsequent to browser update is identical.
-**Supporting Evidence**:
- Screenshot or log output from tooling at showing the data loaded prior to update.
- Screenshot or log output from tooling at showing the data loaded subsequent to update.
### Assessment of [REQ-STORE-SU-2]
-**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:**
- Verify state of the missing PSL suffix.
- Await update according to policy.
- Verify the updated state of the missing PSL suffix.
-**Assignment of Verdict:**
- 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.
-**Supporting Evidence**:
- Screenshot or log output from test at each stage.
## 6.5 Authentication and Access Control
Proposed ESR code: AAC
### Assessment of [REQ-STORE-ACC-1]
-**Assessment Objective:** Assess whether the product presents stores and enforces access according to Same Origin Policy.
-**Assessment Preparation:**
- Identify two relevant websites for test hosted at different origins, that will generate storage data.
- Prepare tooling that will provide visibility into data available for a given context.
- Clear all browser storage.
-**Assessment Activities:**
- Navigate to the first of the websites identified.
- Making use of tooling, verify the data is added to storage, and is available in the context.
- Navigate to the second website.
- Verify that the data set when accessing the first site is unavailable in the new context.
- Verify that the data set when accessing the second site is available in the new context.
- Navigate back to the first website.
- Verify that the data set by the site is still available.
-**Assignment of Verdict:**
- 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.
-**Supporting Evidence**:
- Screenshot or log output from tooling to demonstrate
### Assessment of [REQ-STORE-ACC-2]
-**Assessment Objective:** Assess whether the product enforces Same Origin Policy access outside the rendering process.
-**Assessment Preparation:**
- Access to product source code.
- Access to technical design documentation.
-**Assessment Activities:**
- Identify APIs for retrieval of origin-bound data.
- Identify all access control policy enforcement point(s) for each API.
- Review security boundaries against technical design documentation, to identify location of policy enforcement points.
-**Assignment of Verdict:**
- For each API, at least one access control policy enforcement point should be outside the rendering process boundary.
-**Supporting Evidence**:
- Enumerated list of data retrieval APIs.
- Identified enforcement points.
## 6.6 Confidentiality
Proposed ESR code: CON
In this clause, reference can be made to the Annex K (normative), specifying State Of The Art Cryptography assessment criteria.
### Assessment of [REQ-STORE-CON-1]
-**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:**
- Visit website on site A, and verify the cookies that have been set.
- Visit website on site B, and verify whether the cookies are sent to site A when loading resources.
- Verify whether either of the cookies from site A iframes embedded on site B are stored.
- Reload website on site B, and verify the cookies sent to site A when loading resources.
- Visit website on site A, and verify whether the cookies sent.
-**Assignment of Verdict:**
- 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.
-**Supporting Evidence**:
- Screenshot or log output from tooling at each step to show request data.
- Screenshot or log output from tooling at each step to show cookie storage state.
### Assessment of [REQ-STORE-CON-2]
-**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:**
- Each instance of data written to disk is using appropriate access control.
-**Supporting Evidence**:
- List of disk-stored data from product.
- Corresponding list of OS access control mechanisms used and justification for why each is appropriate.
### Assessment of [REQ-STORE-CON-3]
-**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:**
- Visit the website hosted on site A and inspect browser cache.
- Visit the website hosted on site B, verify request data and inspect browser cache.
-**Assignment of Verdict:**
- 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.
-**Supporting Evidence**:
- Screenshot or log output from tooling showing browser cache content at each step.
- Screenshot or log output from tooling showing request and response for resource A, when visiting site B.
## 6.7 Integrity
@@ -790,6 +937,26 @@ Proposed ESR code: DM
Proposed ESR code: AP
### Assessment of [REQ-STORE-AP-1]
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:**
- Visit website and verify it has set data.
- Follow steps to induce crash
- Restart browser
- Verify data exists in browser.
- Visit website and verify that the data is available to it.
-**Assignment of Verdict:**
- Data set by the website during the first step is presented back to site during final step.
-**Supporting Evidence**:
- Screenshot or log output from tooling at each step to show data.
## 6.10 Impact Minimisation
Proposed ESR code: IM
@@ -806,10 +973,111 @@ Proposed ESR code: EMM
Proposed ESR code: LOG
### Assessment of [REQ-STORE-LOG-1]
-**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:**
- Visit website on site A, and verify it has set data.
- Visit website on site B, and verify it has set data.
- Follow user documentation for deleting data against site A.
- Verify whether data for site A has been removed.
- Verify whether data for site B has been removed.
-**Assignment of Verdict:**
- 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.
-**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
### Assessment of [REQ-STORE-DRT-1]
-**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:**
- For each storage deletion API implementaiton, each has either
- System vendor documentation for the system API, providing guarantee of deletion, or
- Test that upon calling API, underlying memory is deleted.
-**Supporting Evidence**:
- List of internal APIs implementations providing storage deletion.
- Corresponding list of underlying system APIs, and documentation their references.
- Screenshot of log output from test tooling in the case of manual test verification.
### Assessment of [REQ-STORE-DRT-2]
-**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:**
- Verify with tooling only default browser profile exists, and no data is stored.
- Create an instance of each supported browser profile.
- Verify with tooling that each profile exists, and no data is stored.
- With each profile, visit the website to set data.
- Verify with tooling that each profile still exists, and has data stored.
- Follow user documentation for performing reset.
- Verify with tooling only default browser profile exists, and no data is stored.
-**Assignment of Verdict:**
- At each verification step, the expected profiles and data are present.
-**Supporting Evidence**:
- Screenshot or log output from tooling at each step to show data.
- User documentation for performing reset.
### Assessment of [REQ-STORE-DRT-3]
-**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:**
- Visit website on site A, and verify it has set data.
- Visit website on site B, and verify it has set data.
- Follow user documentation for deleting data against site A.
- Verify whether data for site A has been removed.
- Verify whether data for site B has been removed.
-**Assignment of Verdict:**
- 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.
-**Supporting Evidence**:
- Screenshot or log output from tooling at each step to show data.
- 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
