v0.0.6 - Add Electron/Tauri and Super-App Usecases

- Third-party extensions and plugins developed outside the browser manufacturer's control

- Third-party extensions and plugins developed outside the browser manufacturer's control

- User-generated bookmarks, preferences, and configuration data

- User-generated bookmarks, preferences, and configuration data

- Remote attestation or DRM modules that operate under separate security models

- Remote attestation or DRM modules that operate under separate security models

- Mini-apps executed within super-app platforms (as defined in W3C Mini-App White Paper): Individual mini-apps are separate products with digital elements that inherit their browser security properties from the super-app platform. The security of the super-app platform itself is in scope (UC-B12), but the individual mini-apps hosted within such platforms are out of scope for this standard as their security is derivative of the hosting platform's capabilities.

### 4.3.2 In-Scope components embedded browser

### 4.3.2 In-Scope components embedded browser

- Risk level: Standard to High (depends on extent of modifications and deployment context)

- Risk level: Standard to High (depends on extent of modifications and deployment context)

- Rationale: The security posture depends on both the upstream browser's security and the manufacturer's implementation quality. Added features introduce additional attack surface and potential vulnerabilities. Delayed or incomplete integration of upstream patches can extend exposure to known vulnerabilities. Manufacturer-operated services create additional trust dependencies and data processing considerations. However, when properly implemented, adapted browsers can maintain equivalent security to their upstream base while providing differentiated user value. The risk level increases when modifications are extensive, when manufacturer services handle sensitive data, or when the browser is deployed in high-risk contexts (UC-B4 through UC-B8).

- Rationale: The security posture depends on both the upstream browser's security and the manufacturer's implementation quality. Added features introduce additional attack surface and potential vulnerabilities. Delayed or incomplete integration of upstream patches can extend exposure to known vulnerabilities. Manufacturer-operated services create additional trust dependencies and data processing considerations. However, when properly implemented, adapted browsers can maintain equivalent security to their upstream base while providing differentiated user value. The risk level increases when modifications are extensive, when manufacturer services handle sensitive data, or when the browser is deployed in high-risk contexts (UC-B4 through UC-B8).

UC-B11: Desktop Applications with Embedded Browser Navigation

- Description: Software applications built with frameworks like Electron, Tauri, or similar technologies that provide browser-like navigation capabilities, allowing users to navigate to user-defined URLs while maintaining an application-like experience. These applications typically combine web technologies with native capabilities and may provide custom UI chrome, integrated features, and controlled navigation within a defined scope.

- Typical workflows: User-initiated navigation to URLs (bookmarked, typed, or linked); form filling and authentication; downloading files; viewing multimedia content; interaction with web APIs (camera, location, notifications) as permitted by the application; switching between multiple views or tabs managed by the application.

- Typical environments: Desktop workstations (Windows, macOS, Linux) in home offices, corporate environments, or educational settings; installed as native applications with filesystem access; may integrate with system services and native APIs.

- Security considerations: Host-web boundary enforcement; JavaScript bridge security; custom protocol handler validation; URL allowlisting/blocklisting; content security policy enforcement; prevention of navigation to untrusted domains; isolation between web content and native functionality; secure handling of file:// URLs and local resources; protection against XSS and injection attacks targeting the native bridge; update mechanism security for both native and web components.

- Risk level: High

- Rationale: These applications combine the attack surface of both web browsers and native applications. Navigation to user-defined URLs introduces exposure to arbitrary web content while the native integration creates additional vectors for privilege escalation. The JavaScript bridge between web and native contexts is particularly sensitive as it can expose native APIs to potentially malicious web content. Vulnerabilities can lead to local file access, credential theft, or system compromise. The risk is elevated compared to standard web browsing due to the trusted native context and potential for broader system access.

UC-B12: Super-App Platforms

- Description: A super-app is a software platform that hosts and supports other applications (mini-apps), enabling their execution by using the platform's resources. Super-apps function as the hosting environment where multiple mini-apps execute, providing unified discovery (app stores, QR codes, search), shared authentication, resource management, and content curation. Examples include platforms like Alipay, Baidu, WeChat, and similar multi-service aggregation platforms.

- Typical workflows: Mini-app discovery and launch via in-app stores, QR codes, or search; shared authentication across hosted mini-apps; payment processing and financial transactions; access to platform-provided APIs (camera, location, contacts, payment systems); switching between multiple active mini-apps; integration with platform-level services (messaging, social features, notifications).

- Typical environments: Mobile devices (iOS, Android) and desktop applications; multi-user context with shared platform identity; high-frequency daily usage; integration with financial services, social networks, and e-commerce systems; operation in diverse network conditions including public WiFi and cellular networks.

- Security considerations: Mini-app isolation and sandboxing; validation and review of mini-apps before hosting; platform API access control and permissions; shared authentication security across mini-apps; payment and financial transaction security; data sharing boundaries between mini-apps and platform; prevention of malicious mini-apps compromising the platform or other mini-apps; supply chain security for third-party mini-apps; session management across multiple mini-apps; protection of platform-level credentials and tokens; monitoring and logging of mini-app behavior; enforcement of content security policies per mini-app; secure communication channels between mini-apps and platform services.

- Risk level: High

- Rationale: Super-apps aggregate significant user trust and typically handle sensitive operations including financial transactions, personal data access, and authentication credentials used across multiple services. The multi-tenant nature creates complex isolation requirements where compromise of one mini-app should not affect others or the platform itself. The platform's API surface exposed to mini-apps creates potential for privilege escalation or unauthorized data access. Financial integration, combined with the broad scope of functionality and third-party mini-app ecosystem, creates elevated risk for fraud, data breach, and platform-wide compromise. The aggregation of multiple services increases the potential impact of security failures.

## 4.5 Product overview and architecture

## 4.5 Product overview and architecture

---

---

### UC-B11: Desktop Applications with Embedded Browser Navigation (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-1 or DOM-2

- **EXT**: EXT-0 (typically no extension system in embedded context)

- **ENC**: ENC-1

- **LOG**: LOG-2 or LOG-3

- **UPD**: UPD-0 or UPD-1

- **PRO**: PRO-2 (custom protocol handlers)

- **SYS**: SYS-2

- **EMB**: EMB-2 or EMB-3 (mandatory - this is an embedded browser use case)

**Critical Requirements**: EMB-2-REQ-1 through EMB-2-REQ-10 OR EMB-3-REQ-1 through EMB-3-REQ-12, EMB-REQ-1 through EMB-REQ-9, DOM-1-REQ-1 through DOM-1-REQ-9, ENC-1-REQ-1 through ENC-1-REQ-19, LOG-2-REQ-1 through LOG-2-REQ-20, UPD-0-REQ-1 through UPD-0-REQ-24, PRO-2-REQ-1 through PRO-2-REQ-12, SYS-2-REQ-1 through SYS-2-REQ-15

**Special Focus**: EMB-REQ-1 (JavaScript bridge security), EMB-REQ-2 (URL scheme handler validation), EMB-REQ-3 (content source policy), EMB-REQ-8 (host-web boundary), EMB-REQ-9 (custom protocol security), PRO-REQ-3 (protocol handler registration), PRO-REQ-11 (scheme validation)

**Assessment References**: All EMB assessments are critical; PRO-REQ-3, PRO-REQ-11, DOM-REQ-5-9, SYS-REQ-7-15, LOG-REQ-13-16

---

### UC-B12: Super-App Platforms (Risk Level: High)

**Primary Capabilities and Recommended Conditions**:

- **DOM**: DOM-2 or DOM-3 (strict isolation between mini-apps required)

- **EXT**: EXT-0 or EXT-1 (mini-app system replaces traditional extensions)

- **ENC**: ENC-0 or ENC-1 (financial transactions require strictest)

- **LOG**: LOG-3 (comprehensive logging for security and fraud detection)

- **UPD**: UPD-0 or UPD-1 (platform-controlled updates)

- **PRO**: PRO-2 (custom URL schemes for mini-app invocation)

- **SYS**: SYS-2

- **EMB**: EMB-3 (mini-apps are embedded web content with elevated privileges)

- **RDPS**: RDPS-2 (platform services processing sensitive data)

**Critical Requirements**: DOM-2-REQ-1 through DOM-2-REQ-12 OR DOM-3-REQ-1 through DOM-3-REQ-9, EMB-3-REQ-1 through EMB-3-REQ-12, EMB-REQ-1 through EMB-REQ-10, EMB-REQ-19, EMB-REQ-20, LOG-3-REQ-1 through LOG-3-REQ-20, ENC-0-REQ-1 through ENC-0-REQ-23, UPD-0-REQ-1 through UPD-0-REQ-24, PRO-2-REQ-1 through PRO-2-REQ-12, SYS-2-REQ-1 through SYS-2-REQ-15, RDPS-2-REQ-1 through RDPS-2-REQ-18

**Special Focus**: DOM-REQ-9 (cross-origin isolation), DOM-REQ-10 (origin-based access control), DOM-REQ-11 (site isolation), EMB-REQ-1 (JavaScript bridge between platform and mini-apps), EMB-REQ-4 (permission model for mini-apps), EMB-REQ-8 (boundary enforcement), EMB-REQ-19 (mini-app sandboxing), LOG-REQ-13 (security event logging), LOG-REQ-14 (anomaly detection), ENC-REQ-17 (payment data protection)

**Platform-Specific Requirements**: Mini-app validation and review process; platform API permission model; payment system security; shared authentication security; mini-app isolation enforcement; supply chain security for third-party mini-apps; monitoring and behavioral analysis; emergency mini-app revocation capability

**Assessment References**: DOM-REQ-9-12, EMB-REQ-1-20, LOG-REQ-13-16, ENC-REQ-17, PRO-REQ-11, SYS-REQ-7, RDPS-REQ-16-18

---

## B.3 Capability Condition Level Selection Guide

## B.3 Capability Condition Level Selection Guide

| Use Case Risk | DOM | EXT | ENC | LOG | UPD | PRO | SYS | EMB | RDPS |

| Use Case Risk | DOM | EXT | ENC | LOG | UPD | PRO | SYS | EMB | RDPS |