- API keys for some Google services, including browser sync
- The Widevine DRM module
- Licensed codecs for the popular H.264 video and AAC audio formats
- Tracking mechanisms for usage and crash reports
[difference between chrome and chromium](https://chromium.googlesource.com/chromium/src/+/main/docs/chromium_browser_vs_google_chrome.md)
- Gecko and Firefox
### 2.1 Tests
Test Structure Components:
* Reference - Copy of the requirement being tested
* Given - Expected state/setup requirements
* Task - What needs to be performed
* Verification - How to verify the test
* Pass/Fail - Criteria for passing/failing
* Evidence - What constitutes proof (e.g., log files)
## 3. Notes
## Main Discussion Topics
### 1. AI Browsers and Chromium Derivatives Use Case
**Context:** OpenAI recently released a new AI browser based on Chromium, prompting discussion about browser derivatives as a use case.
**Key Points:**
- Proposal to create a use case for repackaged/derivative browsers
- Under the Cyber Resilience Act (CRA), taking an existing open source project, modifying it, and placing it on the market makes the entity a manufacturer
- Chromium itself is a stewarded open source project without CE marking
- Companies like Brave, OpenAI browser are derivatives that would need to comply
- Main concern: defining requirements for manufacturers who modify existing browser projects rather than building from scratch
**Discussion Highlights:**
- Evangelos clarified that placing a modified browser on the market as a browser means the standard applies regardless of AI capabilities
- Key questions: Are modifications substantial? Do they constitute "placing on market" or "making available"?
- Daniel emphasized the use case would help manufacturers who aren't deeply concerned with underlying protocols (like TLS 1.3) but trust the base project handled those aspects
- Need to address when modifications "break the seal" and create new manufacturer obligations
**Considerations:**
- Determining substantial vs. minor modifications
- Whether derivative browsers should be treated as entirely new products or partial modifications
- Practical application for companies repackaging Chromium-based browsers
---
### 2. Browser Testing and Assessment Framework
**Context:** Discussion of how to assess whether browser requirements have been met.
**Assessment Framework Components:**
1.**Capability definition** with conditions
2.**Threat identification** related to capability
3.**Requirements** to mitigate threats
4.**Test/Assessment structure:**
- Reference to requirement being tested
- Objective (why testing this)
- Preparation needed
- Assessment methodology
- Pass/fail verdict criteria
- Evidence collection requirements
**Four Target Audiences:**
1.**Manufacturers** - For Module A self-certification, verify compliance with threat model and risk level
2.**Market Surveillance Authorities** - Cherry-pick tests to verify product compliance (though expected to be infrequent)
3.**Conformity Assessment Bodies (CABs)** - Hired by manufacturers to run comprehensive test suites
4.**Other Product Manufacturers** - Non-browser products can reference specific requirements (e.g., TLS 1.3 implementation) for their own cybersecurity risk assessments (won't achieve presumption of conformity but useful for market surveillance review)
**Resources Mentioned:**
- Standard browser tests already documented
- Web platform tests
- CA/Browser Forum previous work on defining browser criteria (Ben to provide link)
- Test.fyi system for browser acceptance verification
- Ladybird browser achieving 90% test passage threshold for iOS qualification
- Apple's European documentation on browser requirements
**Here are some "standards" and "tests": (Submitted by Ben)**
- employ a sufficient number of developers and security personnel
- comply with applicable industry standards
- pass certain industry-recognized tests
- participate in standards bodies
- release updates and patches on a regular basis
- publish its commitment to user security and privacy
**Some actual tests**
- Acid Tests: A suite of tests developed by the Web Standards Project (WaSP)
- Test262: A test suite developed by the ECMAScript standards committee
I guess one question then w.r.t. e.g. Chromium, is: "is it supplied for distribution or use... in the course of a commercial activity?"
**Level of Testing:**
- Protocol-level assessments
- Security-focused rather than purely functional
- SOC-2 level processes (vulnerability reporting, secure development practices)
- Higher level than typical web platform tests
---
## Next Steps
- Document to be prepared for review before Monday CyberUSR meeting
- Continue development of normative assessment standards
- Add informative chapter (3 or 4) covering browser industry testing practices and architecture
- Consider how to structure derivative browser use case in standard
## Annex A: ETSI IPR Call, Antitrust reminder and Code of conduct
### A.1 IPR Call
The attention of the members and participants of this TB is drawn to the fact that ETSI members and participants shall use reasonable endeavours under Clause 4.1 of the ETSI IPR Policy, Annex 6 of the Rules of Procedure, to inform ETSI of Essential IPRs in a timely fashion. This section covers the obligation to notify its own IPRs but also other companies’ IPRs. The members and participants take note that they are hereby invited:
- to investigate in their company whether their company does own IPRs which are, or are likely to become Essential in respect of the work of the TB,
- to notify to the ETSI Director-General all potential IPRs that their company may own, by means of the IPR Information Statement and the Licensing Declaration forms through the ETSI IPR online database application at https://ipr.etsi.org/.
Only under exceptional circumstances and if instructed by the ETSI Secretariat, paper declarations may be allowed using the forms provided by the ETSI Secretariat similar to the on-line forms.
Members and participants are encouraged to make general IPR undertakings/declarations that they will make licenses available for all their IPRs under FRAND terms and conditions related to a specific standardization area and then, as soon as feasible, provide (or refine) detailed disclosures.
For further details, please refer to: http://www.etsi.org/about/how-we-work/intellectual-property-rights-iprs.
---
### A.2 Antitrust and Competition Reminder
The attention of the members of this Working Group is drawn to the fact that ETSI activities are subject to all applicable antitrust and competition laws and that compliance with said laws is therefore required of any participant of this meeting including the Chair and Vice Chair.
The leadership shall conduct the present meeting with impartiality.
In case of question, it is recommended that you contact your legal counsel.
---
### A.3 Code of Conduct for ETSI Members
This Code of Conduct is intended as a broad guide to appropriate behaviour while carrying out activities in or for ETSI, particularly in cases where specific rules are not available.
The Code of Conduct is intended to augment the ETSI Directives but does not override them. Generally, the Code of Conduct encourages certain collaborative styles of interaction and discourages behaviour that would harm trust and cooperation between members.
ETSI delegates shall acknowledge that the ETSI organization was set up by the CEPT, composed of European administrations, industry partners and stakeholder groups and that the organization is recognized by EU law as a European Standardisation Organisation, as per Regulation (EU) No 1025/2012.
Delegates should support ETSI operations, including the relationship with European administrations as far as reasonably possible, noting in particular the needs of the EU and EFTA, and the advice provided through their Counsellors.
This Code of Conduct complements other more specific codes, such as the Code of Conduct for Board members.
In general, delegates to ETSI:
- Shall acknowledge that ETSI operates according to the principles of international standardization: consensus, transparency, openness, impartiality, effectiveness, relevance, and coherence.
- Shall acknowledge that, at ETSI, the respect of other delegates, the Secretariat and the professional culture of standardization is foremost.
- Shall acknowledge that consensus-building in the development of ETSI standards should be upheld and respected.
When involved in ETSI activities, delegates to ETSI
- Shall act in meetings and discussions in accordance with ETSI Values (see above).
- Should make sure that discussions and debates take place in a moderate, professional, respectful and friendly manner, without prejudice.
- Unless acting in official roles, are assumed to be presenting ideas according to their best professional judgement.
- Are expected to act in good faith and with due care and diligence, avoid collusive, anticompetitive, or dominant behaviour and to promote a culture of fair and ethical behaviour.
- Are expected to take care to act on a fully informed basis and take decisions with due diligence, in order to engage constructively in ETSI activities.
- Are invited to actively participate in the work of ETSI, providing timely contributions uploaded to the ETSI portal.
- Shall value diversity and act against any discrimination as outlined in the ETSI Values, e.g. regarding gender, race, color, ethnic or social origin, genetic features, language, religion or belief, political or any other opinion, membership of a national minority, property, birth, disability, age or sexual orientation.
- Shall acknowledge that speakers should not be interrupted; delegates may speak once recognized by the convenor/Chair of the call or meeting. Speakers should keep their interventions short and to the point.
- Should take the views of all meeting attendees (including those whose first language is not English) into consideration.
- Shall inform the Chair or the Secretariat of any issue requiring escalation so a solution may be reached in a timely manner. The member(s) concerned will use all means to endeavour to solve the issue through the appropriate mechanisms with the help of other members and will respect and uphold the outcomes of such resolution mechanisms.
- Are expected to endeavour to avoid conflict of interest. If any actual or potential conflicts of interest are identified, they shall immediately be disclosed through the appropriate mechanisms.
- Shall take into account the interests and the objectives of the European Union, e.g. as laid down in EU legislation, EU policy documents or outlined by ETSI’s Counsellors, when developing deliverables in support of EU policies and legislation.
Additionally, ETSI Chairs and Vice-Chairs
- Are expected to act in their official roles according to their best professional and neutral judgement, independent of the interests of their supporting organization.
- Are expected to facilitate discussions across different cultures, inclusively, so that decisions align with ETSI Values, protection of minority rights, gender neutrality etc.
- Shall maintain strict impartiality and act in their roles in the interest of ETSI and its members.
- Shall ensure that the ETSI Guidelines for Antitrust Compliance are followed.
- Shall remind delegates of the highlights of these full CoC guidelines at the start of each meeting (at the same time as Antitrust and IPR reminders).
---
## List of Participants
to be downloaded from etsi portal and added after the meeting
| Title | Lastname | Firstname | ORGA SHORT NAME | ORGA COUNTRY CODE |
