Commit b8270c2c authored by Daniel Thompson-Yvetot's avatar Daniel Thompson-Yvetot
Browse files

meeting updates

parent a61a0a4a
Loading
Loading
Loading
Loading
+2 −2
Original line number Diff line number Diff line
@@ -496,7 +496,7 @@ This requirement for user agency fundamentally shapes the browser security model
**Risk**: HIGH - Failure of isolation mechanisms enables immediate compromise of user data across multiple web applications

**Requirements**:
* Implement strict same-origin policy enforcement by default
* DOM-REQ-0: Implement strict same-origin policy enforcement by default
* Validate all cross-origin communication channels
* Provide secure APIs for controlled cross-origin resource sharing
* Monitor and log isolation boundary violations
@@ -554,7 +554,7 @@ This requirement for user agency fundamentally shapes the browser security model
**Risk**: CRITICAL - Encryption failures expose all user data and communications

**Requirements**:
* Enforce TLS 1.3+ for all network communications
* Support TLS 1.3+ for all network communications
* Implement secure storage for passwords and sensitive data
* Validate certificate chains and implement certificate pinning where appropriate
* Provide cryptographic agility for algorithm updates
+93 −1
Original line number Diff line number Diff line
@@ -53,10 +53,102 @@ List of participants included in the meeting report annex.
- 

### 2.3 Cryptography
- Let's discuss if we need to discuss.

All browser should do their best to support post quantum cryptography, 
In our call today it was clear that all participating members are working toward having the capability of quantum secure algorithms / approaches in their products.
We would like to have some expertise here to help us understand the nuances
---

# Meeting Notes: Browser Security Standards Working Group
**Date:** September 26, 2025  
**Duration:** ~1 hour 11 minutes (main session)  

## Overview
Discussion focused on developing browser security standards for the Cyber Resilience Act (CRA), specifically reviewing Section 4.6 containing capability-based threat modeling and requirement classification.

## Key Topics Discussed

### 1. Document Structure and Approach
- **Section 4.6** identified as the normative (mandatory) part containing testable requirements
- Everything outside 4.6 is informative only
- Focus on capability-based approach where browsers may or may not have certain capabilities
- Requirements will be applied to specific use cases (e.g., embedded browsers vs personal browsers)

### 2. Domain and Origin Isolation
- Identified as one of the most complex and expensive security features to implement
- **Sylvestre's concerns:**
  - Implementation can require significant investment (Mozilla spent ~$10-20M on E10S/Fission)
  - Technical nuances difficult to capture in simple requirements
  - Safari still catching up; Chrome has best architecture currently
  - Recommendation to move this to end of document as it may deter initial engagement

### 3. Cryptography Standards
- **Challenge:** Standards must remain valid for 36 months from publication (~September 2025)
- Quantum computing threat timeline uncertain (could be imminent or 5-20 years away)
- **Consensus reached:**
  - Avoid specifying specific algorithms or versions
  - Reference state-of-the-art as described in EUCC guidelines from ENISA
  - Support post-quantum cryptography capabilities
  - Focus on concepts rather than specific implementations

### 4. Testing and Conformity Assessment
- Browsers classified as "Important Class 1" products
- **Three conformity options:**
  1. Self-assessment using harmonized standards
  2. Common specifications
  3. EUCC certification
  - If none used, third-party assessment required
- **Special note:** EIDAS 2 compliance requires mandatory inspection by conformity assessment body

### 5. Market Surveillance Considerations
- Testing must be binary (yes/no) and testable
- Market surveillance authorities need ability to verify compliance
- Challenges with software complexity vs hardware inspection
- Discussion of practical testing methods (OWASP ZAP, Wireshark, memory debuggers)

## Action Items

1. **Molly:** Retrieve and share ESO standard 180131 examples from RED standards
2. **Jarek:** Prepare 2-3 slides showing RED test case approach for next meeting
3. **Sylvestre:** 
   - Review requirements with Mozilla security experts
   - Provide feedback on domain/origin isolation requirements
   - Attempt to get Apple participation through Paris contact
4. **Daniel:** 
   - Continue drafting capabilities and requirements
   - Create issue for post-quantum cryptography requirements

## Key Decisions

- Avoid prescribing specific cryptographic algorithms in the standard
- Focus on testable outcomes rather than implementation methods
- Standards should be achievable for smaller browsers (Brave, Ladybird) not just major vendors
- Profile isolation and user data isolation identified as important capabilities to address

## AOB

- **Apple's absence:** Need to ensure WebKit/Safari representation in discussions
- **Testing complexity:** How to practically test browser security features at scale
- **PWA classification:** Confirmed PWAs depend on installing browser and are essentially special tabs
- **Electron apps:** Two tests developed:
  1. Does it consume uncontrolled third-party content?
  2. Can users navigate freely between websites?

## Next Steps

- Next meeting in two weeks
- Participants to review Section 4.6 and provide feedback
- Workshop next week on cross-vertical alignment
- Draft due to Commission beginning/middle of next week

## Notable Context

- Not enough conformity assessment bodies in Europe currently
- No CRA-certified bodies available until June 2026
- Browser manufacturers (Google, Apple, Mozilla) already investing heavily in security
- Exploit prices range from $200K to $1M indicating strong current security


## Annex A: ETSI IPR Call, Antitrust reminder and Code of conduct

### A.1 IPR Call