-
Notifications
You must be signed in to change notification settings - Fork 13
2026 Cyber Resilience Act
- GitHub issue: https://github.com/Igalia/webengineshackfest/issues/97
- URL: https://meet.jit.si/WEH2026-cra
The latest draft: https://labs.etsi.org/rep/stan4cra/en-304-617
The document itself lives at https://labs.etsi.org/rep/stan4cra/en-304-617/-/blob/main_publish/EN-304-617.md
Q: Anna Weine: what difference between an enterprise browser and a regular browser wrt CRA?
Enterprise browser use case: https://labs.etsi.org/rep/stan4cra/en-304-617/-/blob/main_publish/EN-304-617.md?ref_type=heads#452-enterprise-browser-use-case
Littledan presents the structure of the document as available on GitLab. Scope is limited to Web browsers since they're marked as an important product (and so have to comply to rules beyond those applying to default products.) The Product context describes the intent and architecture of Web browsers, and the environments in which they operate - enterprise being one that he advocated to distinguish. Enterprise browsers usually operate with specific settings and policies under the control of an administrator, which may offer different defaults from what gets provided to regular end users. The CRA draft describes this as a specific environment which intersects with several CRA requirements (e.g. in terms of auto-updates CRA Annex I Part I (2) (c), logging of activity CRA Annex I Part I (2) (l).
3 environments are identified as relevant: general purpose web browser, enterprise, and embedded browser (focusing only on "browser-like" tabs inside an app, NOT webviews since they introduce additional risks)˛ The document only applies to products whose function is to browse the Web - social media apps using a full-fledged webview to show web content would not get a presumption of conformance through this particular document. As a general product, a social app or a TV has to control of any risk, including Web browsers-related risk, for which this vertical standard could serve as a reference point for due diligence.
Guidance that Aki referenced draft pdf, draft html hosted by aki
Q: Lola: what about mini apps?
Littledan: from what my perspective, they're not covered by this; the fact that they use Web technologies doesn't make them a Web browser. The definition of "Web browser" doesn't exclude them, but the intent is really about to access the open internet; likewise, an electron app wouldn't be a Web browser.
Q: a distinction may be about whether the user choose the destination vs fixed by the app?
Littledan: we don't get to update the definition - it is fixed by law; while we could pass feedback to get that law updated, or consider other categories of other important products - that will also depend on how successful we are with this first batch of standards. But it would take at least a year to get this changed.
Q: Michaud: if you have an app that displays store content which can display content from an online store - I would only have basic obligations if using native apps vs CRA obligations as a Web view.
Littledan: only the Web browser component would fall under the CRA obligations; whatever technologies you use, you would have obligations under the CRA, but not as a Web browser. If you ship your own Web view component within a shopping app, it still doesn't fall under the obligations of the CRA.
Q:
If you're writing the software that interprets a Web page, you're shipping a Web browser; if you are including a component to do that, you're not a Web browser.
The vertical CRA standard gives potentially a higher level of legal certainty than what applies to default products.
Q: Cynthia: what about thrid-party browsers on iOS which wraps around the webkit engine provided by iOS? Any specific areas on which you're seeking feedback
If you're wrapping another thing, you can delegate some of the risks to the component you embed. It's not get out of jail card - as a product provider, you're responsible for assessing risks for any component you integrate, even if they're part of the OS, you may still be liable for it.
In terms of areas of feedback, I plan to go over the document in the second part of this breakout.
Q: how broad does the CRA apply to?
Anything that has software and digital hardware, and is delivered to end users (with a few exceptions where strong regulations already exist, e.g. medical devices, automotive, ...). In terms of important and critical products, that list is covered by the law.
Comment: re mobile browser wrapping a web engine component, refer to diagram in section 4.2 - it may help understand which risks are your responsibility vs someone else.
We're incorporating threat modelling (as promoted by W3C) as a way to help understand the boundaries of these risks.
Q: OSS is exempt from the CRA based on what you said yesterday; most browsers are OSS, how does this intersect?
It's very important for the EU Commission that OSS developers can continue to work with legal certainty. The distinction is between an OSS project and a product (i.e. with economic impact) - a product may very well be based on an OSS project, but as soon as you ship it as a product, the company shipping it become legally responsible for the OSS components it includes, and responsible to make the security risk assessment. Economic activity may include indirect means of monetization (e.g. search deals) - although GitHub sponsors for an individual developers wouldn't count in this context - this was the result of a lot of discussions with OSS foundations and communities in 2022.
There is also a role of "Open Source Steward" (Article 24) (with specific requirements).
Q: this only applies to products/product versions that ship after the law takes effect?
Correct - only applies to products "put on the market" after the date takes effect (Dec 2027). In general, if your product is available after that date, it's likely it's not going to be exempt from that law.
Q: Stephen: Can a large company require support from an OSS project to make their risk assessment?
An OSS developer cannot be compelled to do the work of the company trying to comply with the CRA.
Q: Stephen: how would this apply to Igalia and embedded browsers we help ship?
If you're only making money to support the direct cost of what you're doing, it is handled as the OSS donation case, and the risks remain on the client. That's an important thing consultancies need to consider - providing legal certainty is a value their customers might appreciate
Q: @@@
Article 3 (which has all the formal definitions) - 22 stresses "in the course of commercial activity" Article 3 (22) - if a browser isn't made available in that context (e.g. the Tor browser), it is exempt (whether they do or don't make a statement about it)
Q: can consumers sue based on that regulation?
No, only the governments via their national authorities can act on it. Enforcement will be done by "market surveillance authorities" (explained in chapter v of the CRA)
Littledan going over the Browsers standard, focusing on the normative requirements in section 5 - some requirements only apply to specific environments (e.g. only to enterprise browsers); the requirements are organized along the ESR (cybersecurity requirements).
Section 6 describes the assessments that can be applied to the product to determine conformity. e.g. ACC-MEM-KEV-1 describes how to assess conformity to "the web browser's source code that parses untrusted, non-trivial data, shall undergo ongoing automated dynamic analysis to identify vulnerabilities" - the assessment includes documenting the code selection process, the frequency and operations of the dynamic analysis, code coverage methodology, code coverage reports. All these technical documentation pieces only need to be kept privately, available to the market surveillance authorities - distinct from end user documentation.
All these assessments need to be objective.
Annex I gets very specific and technical; e.g. for logging requirements (Annex I (2) (l)), there is a tension between logging security risks vs preserving privacy of the end user activity.
Q: Michaud: a bunch of requirements apply to extensions - can you comment on the overall extension ecosystem? is there a distinction between browser-provided extension store vs others? e.g. there is a rule preventing extensions to access site data, how would this apply to an ad-blocker? REQ-EXT-SBD-2
The extension requirements were provided by the former person running the Mozilla add-ons store, so hopefully took into account that need. The rule is about the default, but the user can choose a different configuration
Q: AFAIK, Safari doesn't respect site isolation requirements; is it also something that user could opt-out of e.g. for memory tradeoff? and given the memory impact, this may be hard or impossible to ship on older devices?
Even in browsers that implement it, they weaken it based on a bunch of heuristics; making it a legal requirement sounds challenging.
We would be happy to get feedback on the wording.
Different levels of security should be based on security needs more than hardware capabilities.
Q: this seems challenging for something as general purpose as a browser that can be used both for low risk and high risk transactions, and can be made available on both low and and high end hardware for which some of the security requirements may have a very different impact
For site isolation, this may point to lowering the level of requirement; but conversely, you wouldn't want to lower the requirements for sufficiently modern cryptographic algorithms.
Q:
Shifting risk to users is not in general a response, but if you document the context and that the user is only able to use with a weakened configuration, this may be sufficient.
Q: site isolation has been a challenge for Android WebView for a very long time
There is a tradeoff between weakening the standard vs leaving room for interpretation - a technically motivated constructive comment on this, submitted ASAP, would be great.
That said, Google has the resources to address the situation, so not clear to me how much weakening should be done.
Q: re extensions isolation?
Clarifications on the wording would be welcome
Q: this only apply to products shipped to EU residents? Won't this generate a flood of "security alerts" banner?
Documenting the security risk to the user won't be sufficient; user consent won't be an opt-out. Only tailor-made software can be out of scope of certain CRA requirements (but still need to be configurable to a secure-by-default setting).
Q: how to deal with shipping software to a too-old-Operating System?
The way we're dealing with this in the VPN standard is to consider this part of the operating environment to which the risks are delegated, not something the product shipper has control over. (Clause 4.5.3)
Comment: when doing risk assessment and threat modelling, the question is always where to stop, and where to delegate risks to another layer, documenting the underlying assumptions (e.g. the underlying Operating SYstem is safe)
That's how the CRA approaches this indeed.
Please engage with the CRA - it is likely to be proposed for the next stage of standardization pretty soon. The GitLab repo is open for the next month; not all comments may get adopted, but they will still help the process. The sooner the comments get made, the better. The next stage is "public inquiry" where the document gets sent to national bodies - these bodies will also take feedback, and they'll decide which comments to elevate back to the ETSI CRA committee (TC CYBER EUSR). Your organisation may already be a member, check at https://www.etsi.org/membership/ (all the way at the bottom of the page) - I strongly encourage you to join, which you can do through OSI if you're an Open Source developer (contact Aki or Dan for an introduction). There is also an open chatroom on Matrix. While the gitlab doesn't take pull requests, you can provide proposed alternative text in your issue.
Two strong directions from the EU commission: get something out sooner rather than later, and get a new revision out soon after.
Comment: that iterative approach would work better if there wasn't a requirement to address all known security risks.
Agreed that these are challenging trade-off - but remember this is an optional standard (third-party assessment is an option), and we've already reduced the number of requirements significantly.