@@ -47,16 +47,69 @@ List of participants included in the meeting report annex.
## 2. Meeting Session
### 2.1 Contributions
- None
### 2.2 Use Cases
-
### 2.3 Risk Mapping
-
### 2.4 Security Profiles
-
#### Merge request by Jaroslaw Bienkowski of the Ministry of Economic Affairs (Netherlands)
Definitions
- New definition of what standalone browsers are - “monolithic” should be changed
- Changing "internet" (not defined) to IP based network
PWA discussion
- Context from previous discussion (email): We are using some frameworks like “electron” which are used to create apps by embedding together a web browser (chromium ) and nodeJS framework. I was interested to see how we will be impacted by this vertical standard for tools based on chromium/electron. For small app based on electron, the content used by the browser is limited to static content created for the application. But in big application, some content may be imported from internet, and may generate risks.
- Response: Indeed, we had a lengthy discussion about Electron and such apps that embed a browser. The feeling that I have (indeed, I am "merely" special rapporteur) is that we will make it possible for such a manufacturer of an Electron app (CEF, Tauri, etc.) to use the standard to assume the presumption of conformity for low-risk products. And it would probably only be an issue if either of the following two conditions are met: (1) the application is not entirely self-contained (i.e. it pulls remote assets from eg a CDN) and (2) it enables the user via express empowerment or reasonably foreseeable misuse to browse the internet
- Activity of browsing is not the same as consuming
- If application is self contained then its not a browser
- PWA function of browsing therefore requirement of browser vendor to provide secure ecosystem for PWAs
- https://developer.mozilla.org/en-US/docs/Web/Progressive_web_apps/Guides/What_is_a_progressive_web_app#pwas_and_the_browser - difference between traditional website and electron is based on chromium
- Distinction between electron and PWA - cannot run without the browser
- Electron is embedded in the application itself, no connection to a browser
- PWA not in themselves a browser because they have to run within a browser - PWA will always have to run within required context of browsers
- PWA entirely the responsibility of browser manufacturer so they are in scope as they are involved in the supply chain of the distribution
- Split into separate layers might be a solution - interface, engine
- Threat surface area
- Change behaviour of browsers - visual studio code (electron app) isn't necessarily same as social media app therefore electron app isn't necessarily a browser it is using framework but not enough coverage of supply chain secure frameworks that that can fall under instead?
- User of electron is a developer you don't just have electron and they're not being used in this context for browsing
- PWA is a piece of the browser and developer can make use of distributing PWA, user can choose that but without the browser its not going to work so PWA has to be managed from a risk perspective by the browser manufacturer
Use Cases
- Financial and e-government services should be separate
- Product in test not the same as product on the field so strike from use case development and testing environments?
- What matters if it has been placed on the market - if it has reached end user
- If not accessible by the real end user then not included, however if it is a beta version you could think that it has been placed on the market security needs to be in place as soon as it has a certain potential to reach a certain number of users
- Art. 4.3. and art. 37- exclusion of certain beta (limited period, affix a sign, only available for purpose of testing)
- Nightly version might not be a substantial modification - may or may not be part of the same product and at the same time the same set of security measures may or may not have been applied to it
- Nightly version might not be part of original product and the same mitigations may not be applied
- Would have to be made compliant after some time, fits within the regular release stream with subsequent major minor version and stable product
- Supposedly limited period of time would correspond to the period needed to test the product - this will be clarified
- Don't want to lose historic releases so the act of retracting a beta model should be looked into
### 2.2 Threats
- Phishing campaign, they want your credit card - Can we protect against social engineering risks? Or is that out of scope? Maybe better to look at classical XSS, sandboxing SVGs
- Two general categories - users being attacked (personal information) or browser is being leveraged in a way that permits the attacker to traverse multiple vulnerabilities in order to get somewhere deeper
- Ultimately its all running in the context of the operating system
- Support secure passwords but ensuring secure passwords is not in scope
- Focus on essential requirements of annex 1, there are some references to data protection but it is simply protecting integrity of data including personal data - there is a connection but there is no need to have a deeper conversation about possible meanings of cybersecurity
- System designed for user initiated requests - challenges of the standard as browsers has one of the widest scope in how they function
### 2.3 Course Treatment
- Isolations
- Between domain URLs
- Origins
- Extensibility
- Extensions - certified browser installed a malicious extension how would the user interpret that? Extension changes the browsers behaviour in a way the browser cant necessarily fully control
- Extension system vs extension just like electron app vs electron itself
- Encryption
- Configuration
- Logging and monitoring (crash, dumps, trails, logs)
- Integration with enterprise systems (remote monitoring, configuration)
- Update mechanisms (this must have a turn-off option) - cannot be only automatic
- Ensure vulnerabilities can be addressed through security updates, including, where applicable, through automatic security updates that are installed within an appropriate timeframe enabled as a default setting, with a clear and easy-to-use opt-out mechanism, through the notification of available updates to users and the option to temporarily postpone them
- Supported protocols
- Transport
- Data storage
- Accessibility
- Operating system access boundaries (HAL)
- PWA
---
@@ -132,7 +185,15 @@ Additionally, ETSI Chairs and Vice-Chairs
## List of Participants
[To be downloaded from the ETSI portal after the meeting]
| Title | Lastname | Firstname | ORGA SHORT NAME | ORGA COUNTRY CODE |
