EN-304-617_v0.0.4.md

- registerProtocolHandler API: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
- Security by Reduction: https://csrc.nist.gov/glossary/term/least_functionality

### Assessment: PRO-REQ-26 (Non-standard URL scheme blocking)

**Reference**: PRO-0-REQ-3 - Browser shall block access to non-standard URL schemes (file://, data://, javascript://, etc.)

**Given**: A conformant browser with PRO-0 capability (HTTP/HTTPS only)

**Task**: Verify that the browser blocks access to non-standard URL schemes that could be exploited for cross-site scripting (javascript:), local file disclosure (file://), or content injection (data:), restricting URL navigation and resource loading exclusively to HTTP and HTTPS to eliminate common attack vectors that abuse non-standard schemes to bypass same-origin policy or execute malicious code.

**Verification**:

1. Test blocking of javascript: URLs:
   - In address bar navigation
   - In links (<a href="javascript:...">)
   - In iframe src attributes
   - In form action attributes
2. Verify that data: URLs are blocked:
   - In navigation
   - In iframe src
   - In image src
   - In script src
3. Test that file: URLs are blocked:
   - In navigation
   - In resource loading (images, scripts, styles)
   - In iframe src
4. Verify that blob: URLs are blocked or restricted
5. Test that about: URLs are limited to safe pages only
6. Verify that view-source: scheme is blocked
7. Test that custom app schemes (mailto:, tel:, sms:) are blocked
8. Verify that blocked schemes return consistent error messages
9. Test that scheme blocking applies to all contexts (main frame, iframes, workers)
10. Verify that CSP cannot override scheme blocking
11. Test that redirects to non-standard schemes are blocked
12. Verify that meta refresh to non-standard schemes is blocked

**Pass Criteria**: All non-standard schemes blocked consistently AND blocking applies in all contexts AND clear error messages AND CSP cannot override AND redirects blocked

**Fail Criteria**: Non-standard schemes accessible in any context OR inconsistent blocking OR CSP overrides OR redirects succeed

**Evidence**: Scheme blocking test results for various contexts, error message examples, CSP interaction tests, redirect blocking verification, meta refresh handling

**References**:

- URL Standard Schemes: https://url.spec.whatwg.org/#special-scheme
- XSS via javascript: URLs: https://owasp.org/www-community/attacks/xss/
- data: URI Security: https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/Data_URLs#security

### Assessment: PRO-REQ-27 (Protocol handler API removal)

**Reference**: PRO-0-REQ-4 - Browser shall not provide registerProtocolHandler() API or equivalent functionality

**Given**: A conformant browser with PRO-0 capability (HTTP/HTTPS only)

**Task**: Verify that the browser completely removes or disables the registerProtocolHandler() API and any equivalent protocol registration mechanisms, ensuring that web applications cannot even detect or attempt to use custom protocol handler functionality, providing defense in depth by eliminating the API surface rather than merely blocking its effects.

**Verification**:

1. Test that navigator.registerProtocolHandler is undefined or throws error
2. Verify that attempting to call the API produces clear error
3. Test that navigator.isProtocolHandlerRegistered() is also unavailable
4. Verify that navigator.unregisterProtocolHandler() is unavailable
5. Test that Feature Policy cannot re-enable protocol handler API
6. Verify that no polyfills or fallback mechanisms exist
7. Test that Content-Security-Policy cannot enable the API
8. Verify that browser feature detection shows API as unavailable
9. Test that JavaScript cannot detect if API was previously available
10. Verify that web platform tests for protocol handlers are skipped
11. Test that browser documentation indicates API is not supported
12. Verify that removal is consistent across all browsing contexts (windows, workers, iframes)

**Pass Criteria**: registerProtocolHandler API completely unavailable AND related APIs also removed AND no detection possible AND consistent across contexts AND documentation indicates unavailability

**Fail Criteria**: API is accessible OR can be enabled through policies OR detection possible OR inconsistent availability OR undocumented removal

**Evidence**: API availability tests in various contexts, feature detection results, policy configuration attempts, browser documentation excerpts, error messages when attempting API access

**References**:

- registerProtocolHandler Specification: https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
- Feature Policy: https://w3c.github.io/webappsec-feature-policy/

### Assessment: PRO-REQ-28 (Non-HTTP/HTTPS navigation rejection)

**Reference**: PRO-0-REQ-5 - Browser shall reject navigation to any non-HTTP/HTTPS protocols

**Given**: A conformant browser with PRO-0 capability (HTTP/HTTPS only)

**Task**: Verify that all navigation attempts to non-HTTP/HTTPS protocols are rejected regardless of how navigation is initiated, ensuring comprehensive protocol restriction that cannot be bypassed through various navigation mechanisms like user clicks, script navigation, form submission, or meta refresh, protecting against protocol-based attacks from any entry point.

**Verification**:

1. Test navigation rejection through various mechanisms:
   - Direct address bar input
   - Link clicks (<a> elements)
   - window.location assignments
   - window.open() calls
   - Form submissions
   - Meta refresh tags
   - HTTP redirects (3xx responses)
   - JavaScript location.href changes
2. Test rejection for various non-HTTP/HTTPS schemes:
   - Custom protocols (myapp://)
   - File system access (file://)
   - Data URIs (data://)
   - JavaScript (javascript://)
   - WebSocket (ws://, wss://)
   - FTP (ftp://)
3. Verify that all navigation attempts are blocked before any handler invocation
4. Test that blocked navigation shows user-friendly error page
5. Verify that error page does not expose protocol handler information
6. Test that navigation history does not include blocked attempts
7. Verify that referrer is not sent for blocked navigation
8. Test that beforeunload event does not fire for blocked navigation
9. Verify that page lifecycle continues normally after blocked navigation
10. Test that HTTPS upgrade (HTTP -> HTTPS) still functions
11. Verify that logging captures blocked navigation attempts for security monitoring

**Pass Criteria**: All non-HTTP/HTTPS navigation blocked AND blocking occurs before handler invocation AND user-friendly errors AND history not polluted AND works across all navigation mechanisms

**Fail Criteria**: Navigation succeeds through any mechanism OR handlers invoked before blocking OR confusing errors OR history includes blocked attempts

**Evidence**: Navigation blocking tests for all mechanisms and schemes, error page screenshots, history inspection, lifecycle event verification, logging samples

**References**:

- Navigation and Browsing Contexts: https://html.spec.whatwg.org/multipage/browsing-the-web.html
- Secure Navigation: https://w3c.github.io/webappsec-secure-contexts/

### Assessment: PRO-REQ-29 (Enterprise protocol handler policy controls)

**Reference**: PRO-2-REQ-12 - Enterprise administrators shall be able to configure protocol handler allowlists and blocklists

**Given**: A conformant browser with PRO-2 capability in enterprise environment

**Task**: Verify that enterprise administrators can configure protocol handler allowlists and blocklists through group policy or MDM to control which custom protocols are permitted in their organization, enabling organizations to approve specific business-critical protocol handlers (like internal application launchers) while blocking potentially dangerous handlers, supporting compliance and security requirements through centralized policy management.

**Verification**:

1. Access enterprise policy management interface
2. Identify protocol handler allowlist/blocklist policies
3. Configure policy to allow specific protocol schemes (e.g., web+customapp)
4. Configure policy to block specific schemes (e.g., web+dangerous)
5. Deploy policy to managed browser
6. Test that allowed protocols can be registered and used
7. Verify that blocked protocols cannot be registered
8. Test that user cannot override enterprise protocol policies
9. Verify that allowlist takes precedence when both are configured
10. Test that wildcard patterns work in policies (e.g., web+myorg*)
11. Verify that policy applies to all browser profiles on managed device
12. Test that policy changes propagate immediately or on restart
13. Verify that policy status is visible in browser management UI
14. Test that attempting blocked protocol shows enterprise policy message
15. Verify that audit logs include policy enforcement events

**Pass Criteria**: Allowlist and blocklist policies available AND policies enforced correctly AND user cannot override AND wildcard support AND policy status visible AND enforcement logged

**Fail Criteria**: No policy controls OR policies not enforced OR user override possible OR no wildcard support OR no visibility OR no logging

**Evidence**: Policy configuration screenshots, enforcement test results with allowed and blocked protocols, user override attempts, wildcard pattern tests, policy status UI, audit logs

**References**:

- Enterprise Browser Management: https://chromeenterprise.google/policies/
- Group Policy Configuration: https://docs.microsoft.com/en-us/deployedge/configure-microsoft-edge
- Mobile Device Management: https://developer.apple.com/documentation/devicemanagement

### Assessment: PRO-REQ-30 (Custom scheme registration without web+ prefix)

**Reference**: PRO-3-REQ-7 - Browser shall allow registration of custom schemes without web+ prefix

**Given**: A conformant browser with PRO-3 capability (unrestricted protocol registration)

**Task**: Verify that the browser allows registration of custom protocol schemes without requiring the web+ prefix, providing maximum flexibility for legacy applications and custom integrations that use established protocol schemes, while acknowledging increased security risk from schemes that don't follow web+ convention and may conflict with future browser features or OS-level protocol handlers.

**Verification**:

1. Attempt to register custom protocol without web+ prefix (e.g., "myapp")
2. Verify that registration succeeds without requiring web+ prefix
3. Test that registered handler functions correctly when invoked
4. Verify that schemes without web+ prefix are marked with security warning
5. Test registration of common non-web+ schemes:
   - Application launchers (myapp://)
   - Internal tools (tool://)
   - Legacy protocols (custom://)
6. Verify that registration still requires user consent
7. Test that schemes conflicting with browser internals are rejected
8. Verify that schemes matching standard protocols (http, ftp) are rejected
9. Test that OS-level protocol conflicts are detected and warned about
10. Verify that documentation explains risks of non-web+ schemes
11. Test that handler management UI shows prefix status
12. Verify that non-web+ handlers appear in security audits

**Pass Criteria**: Custom schemes without web+ can be registered AND security warnings shown AND conflicts detected AND user consent still required AND risks documented

**Fail Criteria**: Non-web+ registration fails OR no security warnings OR conflicts not detected OR no consent required OR undocumented risks

**Evidence**: Registration success examples for non-web+ schemes, security warning screenshots, conflict detection tests, user consent dialogs, documentation excerpts, audit trail entries

**References**:

- Custom Scheme and Content Handlers: https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
- Protocol Handler Security: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler#security

### Assessment: PRO-REQ-31 (Non-standard protocol handler security warnings)

**Reference**: PRO-3-REQ-8 - Browser shall display security warnings for non-standard protocol handlers

**Given**: A conformant browser with PRO-3 capability with custom protocol handlers

**Task**: Verify that the browser displays clear security warnings when non-standard protocol handlers are registered or invoked, informing users about potential risks of custom handlers including command injection, local application exploitation, or data exfiltration, enabling informed decisions about accepting handlers in unrestricted environments where security is balanced against compatibility.

**Verification**:

1. Register a non-standard protocol handler (not following web+ convention)
2. Verify that security warning is displayed during registration:
   - Clear explanation of handler risks
   - Warning about non-standard scheme
   - Potential security implications
   - Recommendation to verify handler source
3. Test that warning requires explicit user acknowledgment
4. Verify that invoking non-standard handler shows warning:
   - Banner or notification when handler activates
   - Indication of which handler is being called
   - Option to cancel handler invocation
5. Test warnings for various risk levels:
   - High risk: local application launchers
   - Medium risk: web+ schemes to unknown origins
   - Low risk: handlers from trusted origins
6. Verify that warnings distinguish between:
   - First-time handler invocation (full warning)
   - Subsequent invocations (brief reminder)
7. Test that warning cannot be permanently dismissed for high-risk handlers
8. Verify that warning includes handler details (origin, scheme, target URL)
9. Test that warning links to security documentation
10. Verify that security dashboard shows active non-standard handlers

**Pass Criteria**: Security warnings displayed at registration and invocation AND warnings explain risks clearly AND explicit acknowledgment required AND warnings vary by risk level AND handler details provided

**Fail Criteria**: No warnings shown OR unclear risk explanation OR no acknowledgment required OR static warnings regardless of risk OR missing handler details

**Evidence**: Warning screenshots at registration and invocation, risk level differentiation examples, acknowledgment requirements, security dashboard views, documentation links

**References**:

- Security Warning Design: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/felt
- Protocol Handler Risks: https://textslashplain.com/2019/08/28/browser-architecture-web-platform-security/

### Assessment: PRO-REQ-32 (Protocol handler review interface)

**Reference**: PRO-3-REQ-10 - Users shall be able to review all registered protocol handlers in browser settings

**Given**: A conformant browser with PRO-3 capability with protocol handlers registered

**Task**: Verify that users can review all registered protocol handlers through accessible browser settings interface, providing transparency about which applications or sites can intercept custom protocols, enabling users to audit handler registrations, understand what each handler does, and identify potentially malicious or unwanted handlers for removal.

**Verification**:

1. Register multiple protocol handlers for different schemes
2. Access browser settings to find protocol handler management
3. Verify that handler list is easily accessible:
   - Located in Privacy, Security, or Site Settings
   - Clear menu label ("Protocol Handlers" or "Custom Protocols")
   - Accessible within 2-3 clicks
4. Test that handler list shows complete information:
   - Protocol scheme (e.g., web+myapp)
   - Handler URL/origin
   - Registration date
   - Last invocation date
   - Handler status (active, disabled)
5. Verify that list includes all registered handlers:
   - Web+ prefixed schemes
   - Non-web+ custom schemes
   - Built-in handler overrides (mailto, etc.)
6. Test that list can be filtered or searched
7. Verify that clicking handler shows detailed information:
   - Full handler URL template
   - Registering origin
   - Number of invocations
   - Security warnings if applicable
8. Test that handlers can be removed from this interface
9. Verify that handler changes (add/remove) update list immediately
10. Test that export/backup of handler list is available
11. Verify that help documentation explains handler risks

**Pass Criteria**: Handler list easily accessible AND shows complete information AND includes all handlers AND can be filtered AND detailed view available AND removal possible AND changes immediate

**Fail Criteria**: List hard to find OR incomplete information OR missing handlers OR no filtering OR no details OR cannot remove OR delayed updates

**Evidence**: Handler list UI screenshots showing various handlers, detailed view examples, filter/search functionality, removal workflow, export capability, help documentation

**References**:

- User Control and Transparency: https://www.w3.org/TR/design-principles/#user-control
- Browser Settings Best Practices: https://www.w3.org/TR/security-privacy-questionnaire/#user-interface

### Assessment: PRO-REQ-33 (Custom handler vulnerability scanning)

**Reference**: PRO-3-REQ-11 - Browser shall scan custom handlers for known security vulnerabilities

**Given**: A conformant browser with PRO-3 capability with custom protocol handlers

**Task**: Verify that the browser scans custom protocol handlers for known security vulnerabilities and suspicious patterns before registration and periodically during use, detecting handlers that could be exploited for command injection, path traversal, or other attacks, providing automated security analysis to protect users who may not recognize malicious handler patterns in unrestricted registration environments.

**Verification**:

1. Attempt to register protocol handlers with known vulnerable patterns:
   - Command injection patterns (e.g., URL with shell metacharacters)
   - Path traversal attempts (../ sequences)
   - SQL injection patterns
   - Script injection patterns (<script>, javascript:)
2. Verify that browser detects and warns about vulnerable patterns
3. Test that scan occurs before handler registration completes
4. Verify that detected vulnerabilities are clearly explained to user
5. Test that high-severity vulnerabilities block registration
6. Verify that medium-severity issues show strong warning but allow registration
7. Test periodic rescanning of registered handlers:
   - Check if scan runs on browser updates (new vulnerability signatures)
   - Verify notification if previously-safe handler becomes vulnerable
8. Verify that vulnerability database is updated regularly
9. Test that false positives can be reported
10. Verify that scan covers various attack vectors:
   - Local command execution
   - File system access
   - Network exfiltration
   - Cross-origin data access
11. Test that scan results are logged for security auditing
12. Verify that documentation explains vulnerability scanning process

**Pass Criteria**: Vulnerability scanning active AND detects known patterns AND scan before registration AND periodic rescans AND severity-based actions AND regular signature updates AND scan results logged

**Fail Criteria**: No scanning OR fails to detect known vulnerabilities OR no periodic rescans OR no severity differentiation OR outdated signatures OR no logging

**Evidence**: Vulnerability detection test results for various attack patterns, scan timing verification, periodic rescan demonstrations, severity handling examples, signature update verification, scan logs

**References**:

- OWASP Top 10: https://owasp.org/www-project-top-ten/
- Common Weakness Enumeration: https://cwe.mitre.org/
- Protocol Handler Attack Vectors: https://portswigger.net/web-security/cross-site-scripting/contexts

### Assessment: PRO-REQ-34 (Protocol handler security audit logging)

**Reference**: PRO-3-REQ-12 - All protocol handler security exceptions shall be logged and auditable

**Given**: A conformant browser with PRO-3 capability with protocol handlers active

**Task**: Verify that all protocol handler security events are comprehensively logged to enable security monitoring, incident investigation, and compliance auditing in unrestricted environments where protocol handlers pose elevated risk, ensuring that security teams have visibility into handler registration, invocation, security warning dismissals, and vulnerability detections to identify potential compromise or policy violations.

**Verification**:

1. Perform various protocol handler security events:
   - Handler registration (standard and non-standard)
   - Handler invocation
   - Security warning acknowledgments
   - Vulnerability detections during scanning
   - Failed registration attempts (blocked schemes)
   - Handler removal/revocation
   - Policy violations (if enterprise policies active)
2. Access browser security logs or audit trail
3. Verify that all events are logged with comprehensive details:
   - Timestamp (with timezone)
   - Event type (registration, invocation, warning, etc.)
   - Protocol scheme involved
   - Handler URL/origin
   - Registering origin
   - User action taken (accepted, declined, dismissed)
   - Security warnings shown
   - Vulnerability scan results
   - IP address or network context if relevant
4. Test that logs are structured for automated analysis (JSON, CSV, syslog)
5. Verify that logs can be filtered by event type, scheme, or time range
6. Test that logs are retained for appropriate period (configurable)
7. Verify that logs can be exported or forwarded to SIEM
8. Test that log tampering is prevented or detected
9. Verify that high-severity events trigger immediate log entries
10. Test that logging does not expose sensitive user data
11. Verify that logs are accessible to security administrators
12. Test that log volume is reasonable and doesn't impact performance

**Pass Criteria**: All security events logged AND comprehensive details captured AND structured format AND filterable AND exportable to SIEM AND tamper-protected AND privacy-preserving

**Fail Criteria**: Events not logged OR insufficient details OR unstructured logs OR no filtering OR cannot export OR logs can be tampered OR exposes sensitive data

**Evidence**: Log samples showing various event types, log schema documentation, filter/search demonstrations, SIEM export examples, tamper protection verification, privacy analysis

**References**:

- CWE-778: Insufficient Logging: https://cwe.mitre.org/data/definitions/778.html
- OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- Security Audit Trail Requirements: https://csrc.nist.gov/glossary/term/audit_trail

## 6.7 System Resource Access Security Assessments

This section covers assessment procedures for requirements SYS-REQ-1 through SYS-REQ-32, addressing sandbox enforcement, Hardware Abstraction Layer (HAL) security, PWA permissions, filesystem access, device API security, and system resource isolation.

### Assessment: SYS-REQ-1 (Process sandbox enforcement)

**Reference**: SYS-REQ-1 - Browser shall enforce process-level sandboxing to isolate web content from the host operating system

**Given**: A conformant browser with SYS-1 or higher capability

**Task**: Renderer processes handle untrusted web content and are the primary attack surface for browser exploitation. Without OS-level sandboxing, successful renderer exploits grant attackers full system access to read files, execute processes, exfiltrate data, and install malware. Process-level sandboxing using platform-specific mechanisms (seccomp-bpf, sandbox-exec, Job Objects) with syscall filtering and privilege reduction contains renderer compromises, preventing sandbox escapes and limiting attack impact to the isolated process.

**Verification**:

1. Launch the browser with sandbox debugging enabled (--enable-sandbox-logging or equivalent)
2. Open the browser's internal process viewer through the browser's debugging interface or task manager
3. Navigate to a test web page and verify it runs in a sandboxed renderer process
4. Attempt to execute system calls from JavaScript that should be blocked (file system access, process creation)
5. Use platform-specific tools to inspect process sandbox status (Process Explorer on Windows, ps with security flags on Linux/macOS)
6. Verify renderer processes run with reduced privileges using tools like icacls, getfacl, or sandbox-exec -p
7. Test that sandboxed processes cannot access parent process memory
8. Attempt to escape sandbox through known attack vectors and verify containment
9. Monitor system calls using strace (Linux), dtruss (macOS), or Process Monitor (Windows) to verify syscall filtering
10. Verify that sandbox violations are logged and processes are terminated on policy violations
11. All renderer processes execute within OS-level sandbox (seccomp-bpf on Linux, sandbox-exec on macOS, Job Objects on Windows)
12. Sandboxed processes cannot access filesystem outside designated cache directories
13. System call filtering is active and blocks dangerous syscalls (execve, fork, ptrace)
14. Process privileges are reduced (no root, limited capabilities, restricted tokens)
15. Memory isolation prevents cross-process memory access
16. Network access is mediated through broker process
17. Sandbox escape attempts are blocked and logged
18. Process termination occurs on sandbox policy violations

**Pass Criteria**: All renderer processes execute in OS-level sandbox AND dangerous system calls are filtered AND privilege reduction is verified AND sandbox escapes are prevented

**Fail Criteria**: Any renderer process runs without sandbox OR system calls are not filtered OR privileges are not reduced OR sandbox escape succeeds

**Evidence**: Process sandbox status screenshots, syscall trace logs showing filtering, privilege analysis outputs (icacls, capabilities), sandbox violation logs, security tool reports (Process Explorer, sandbox-exec output)

**References**:

- Chromium Sandbox Design: https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md
- Linux seccomp-bpf: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html
- macOS Sandbox: https://developer.apple.com/documentation/security/app_sandbox
- Windows Sandbox: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-sandbox/windows-sandbox-overview

### Assessment: SYS-REQ-2 (Renderer process isolation)

**Reference**: SYS-REQ-2 - Browser shall isolate renderer processes from each other and from browser core processes

**Given**: A conformant browser with SYS-1 or higher capability

**Task**: Renderer process isolation is fundamental to browser security architecture, preventing compromised renderers from accessing data belonging to other origins. Without process-per-origin isolation, a successful exploit in one tab could steal credentials, session tokens, and sensitive data from all other open tabs, violating Same-Origin Policy at the process level. Site Isolation with distinct processes, mediated IPC, and no shared memory prevents cross-origin data theft, Spectre attacks, and cascading process crashes.

**Verification**:

1. Open multiple tabs with different origins in the browser
2. Use the browser's process viewer to verify each origin runs in a separate renderer process
3. Open developer tools and use performance profiling to identify process boundaries
4. Test Site Isolation by navigating to cross-origin iframes and verifying separate processes
5. Attempt to access memory or data from one renderer process in another using side-channel attacks
6. Verify that process IDs are distinct for different origins using OS tools (ps, Task Manager)
7. Test that renderer crashes in one tab do not affect other tabs or the browser process
8. Monitor inter-process communication to verify it goes through secure IPC channels
9. Use memory analysis tools to verify no shared memory regions between renderers
10. Test process-per-site-instance isolation for enhanced security
11. Each origin or site instance runs in a dedicated renderer process
12. Process IDs are distinct and verifiable through OS tools
13. Renderer process crashes are isolated and do not cascade
14. No shared memory regions exist between different renderer processes
15. Inter-process communication uses secure, mediated IPC channels
16. Browser core process (broker) is isolated from all renderers
17. GPU process isolation is separate from renderer isolation
18. Side-channel attacks cannot leak data between renderer processes

**Pass Criteria**: Different origins run in separate processes AND processes have distinct PIDs AND crashes are isolated AND no memory sharing exists

**Fail Criteria**: Same process handles multiple origins OR process crash cascades OR shared memory exists OR IPC is not secured

**Evidence**: Process viewer screenshots showing multiple renderer processes, PID listings from OS tools, crash isolation test results, memory map analysis, IPC traffic logs, Site Isolation verification reports

**References**:

- Chromium Site Isolation: https://www.chromium.org/Home/chromium-security/site-isolation/
- Firefox Fission: https://wiki.mozilla.org/Project_Fission

### Assessment: SYS-REQ-3 (GPU process isolation)

**Reference**: SYS-REQ-3 - Browser shall isolate GPU rendering operations in a separate sandboxed process

**Given**: A conformant browser with SYS-1 or higher capability

**Task**: GPU processes execute untrusted shader code and interact with complex graphics drivers that have historically been sources of vulnerabilities. Without GPU process isolation, exploits targeting graphics drivers or shader compilers could escape to access the filesystem, network, or other process memory, bypassing renderer sandbox protections. Isolated GPU processes with command buffer validation and sandboxing contain GPU-related exploits while enabling graceful degradation through software rendering fallbacks.

**Verification**:

1. Launch browser and navigate to the browser's GPU information interface to verify GPU process information
2. Open a WebGL-intensive page (e.g., https://webglsamples.org/) and verify GPU process activation
3. Use OS process viewer to identify the GPU process and verify it's distinct from renderers
4. Check GPU process sandbox status using platform-specific security tools
5. Verify GPU process has limited capabilities and cannot access filesystem directly
6. Test that GPU process crashes do not terminate the browser or renderer processes
7. Monitor GPU command buffer submissions to verify they're sanitized and validated
8. Attempt to exploit GPU driver vulnerabilities and verify sandbox containment
9. Use graphics debugging tools (apitrace, RenderDoc) to analyze GPU process isolation
10. Verify that software rendering fallback maintains process isolation
11. GPU process runs as separate, distinct process with unique PID
12. GPU process executes within OS-level sandbox with reduced privileges
13. GPU command buffers are validated before submission to driver
14. GPU process cannot directly access filesystem or network
15. Crashes in GPU process trigger graceful degradation (software rendering)
16. Graphics driver access is mediated and monitored
17. Shader compilation occurs in isolated context
18. GPU memory is isolated from CPU-accessible memory

**Pass Criteria**: GPU process is isolated with distinct PID AND sandbox is enforced AND command validation occurs AND crashes are contained

**Fail Criteria**: No GPU process isolation OR sandbox not enforced OR commands not validated OR crashes cascade

**Evidence**: GPU process information screenshots, PID verification, sandbox status reports, crash test results, GPU command trace logs, shader compilation logs, graphics debugging tool outputs

**References**:

- Chromium GPU Process Architecture: https://www.chromium.org/developers/design-documents/gpu-accelerated-compositing-in-chrome/
- GPU Sandbox: https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md#gpu-process
- WebGL Security: https://www.khronos.org/registry/webgl/specs/latest/1.0/#security
- Angle Project Security: https://chromium.googlesource.com/angle/angle
- GPU Denylist and Security: https://chromium.googlesource.com/chromium/src/+/master/gpu/config/software_rendering_list.json

### Assessment: SYS-REQ-4 (Network service isolation)

**Reference**: SYS-REQ-4 - Browser shall isolate network operations in a separate sandboxed process or service

**Given**: A conformant browser with SYS-1 or higher capability

**Task**: Network operations in renderer processes create attack vectors for certificate validation bypass, CORS violations, and direct socket access that could enable data exfiltration or network-based attacks. Without network service isolation, compromised renderers could directly manipulate network connections, bypass security policies, or exploit network stack vulnerabilities. Isolating network operations in a separate service with mediated access ensures certificate validation, CORS enforcement, and CSP compliance occur in a privileged, monitored context outside attacker control.

**Verification**:

1. Open browser internal pages to view process architecture through the process inspection interface
2. Verify network service runs as separate process or is isolated within browser process
3. Use network analysis tools (Wireshark, tcpdump) to monitor network requests from different processes
4. Test that renderer processes cannot directly create network sockets
5. Verify all network requests are mediated through network service/process
6. Attempt to bypass network service from renderer process and verify blocking
7. Monitor network service sandbox status using platform security tools
8. Test certificate validation occurs in network service, not renderer
9. Verify CORS and CSP enforcement happens in network service layer
10. Test that network service crashes trigger appropriate error handling
11. Network operations execute in isolated network service/process
12. Renderer processes cannot directly access network APIs
13. All network requests are mediated through network service
14. Certificate validation occurs in privileged context
15. CORS and content security policies are enforced at network layer
16. Network service runs with minimal necessary privileges
17. Socket creation is controlled and monitored
18. Network service crashes are handled gracefully

**Pass Criteria**: Network service is isolated AND renderers use IPC for network access AND certificate validation is isolated AND CORS/CSP enforced at network layer

**Fail Criteria**: Renderers have direct network access OR no network service isolation OR certificate validation in renderer OR enforcement bypassed

**Evidence**: Process architecture diagrams, network traffic captures, IPC logs showing network requests, sandbox status for network service, certificate validation traces, CORS enforcement logs

**References**:

- Chromium Network Service: https://www.chromium.org/developers/design-documents/network-stack/
- Network Sandbox: https://chromium.googlesource.com/chromium/src/+/master/services/network/README.md
- CORS and Fetch Standard: https://fetch.spec.whatwg.org/
- Certificate Transparency: https://www.certificate-transparency.org/
- Mozilla Network Security: https://wiki.mozilla.org/Security/Server_Side_TLS

### Assessment: SYS-REQ-5 (Filesystem access control)

**Reference**: SYS-REQ-5 - Browser shall enforce strict access controls on filesystem operations, limiting access to user-approved locations

**Given**: A conformant browser with SYS-1 or higher capability

**Task**: Unrestricted filesystem access from web content enables attackers to read sensitive files, access system directories, exfiltrate browser credentials from profile directories, or write malicious files to startup locations. Without strict access controls, file:// URLs could read arbitrary local files, and File APIs could access system directories without user awareness. User-mediated filesystem access with sandboxed namespaces, IPC-brokered operations, and revocable per-origin permissions prevents unauthorized file access while enabling legitimate file operations.

**Verification**:

1. Attempt to read local files using file:// URLs and verify restrictions
2. Test File API access from web content and verify it requires user gesture
3. Use File System Access API to request directory access and verify user prompt appears
4. Monitor filesystem access from renderer process using system tools (auditd, OpenBSM, Process Monitor)
5. Verify browser cache and profile directories are protected from direct renderer access
6. Test that sandboxed filesystem namespace limits visible paths
7. Attempt to access system directories (/etc, C:\\Windows) from web content and verify blocking
8. Verify file uploads use secure IPC to broker process for filesystem access
9. Test that downloaded files are stored in user-designated locations only
10. Check that filesystem access permissions are revoked when tab closes
11. file:// URL access is restricted or requires user opt-in
12. File API requires user gesture (click/tap) for access
13. File System Access API shows permission prompts
14. Renderer processes cannot directly access filesystem
15. System directories are not accessible from web content
16. Browser profile and cache protected from renderer access
17. File operations use IPC to privileged broker process
18. Filesystem permissions are per-origin and revocable
19. Sandboxed filesystem namespace limits path visibility

**Pass Criteria**: Filesystem access requires user permission AND system directories are blocked AND renderer uses IPC for file operations AND permissions are revocable

**Fail Criteria**: Direct filesystem access from renderer OR no user permission required OR system directories accessible OR permissions not revocable

**Evidence**: File access audit logs, permission prompt screenshots, filesystem monitoring traces, sandbox policy dumps, IPC logs for file operations, directory access test results

**References**:

- File System Access API: https://wicg.github.io/file-system-access/
- File API Specification: https://www.w3.org/TR/FileAPI/
- OWASP File Upload Security: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html
- Same-Origin Policy for file: URLs: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy#file_origins

### Assessment: SYS-REQ-6 (Device API permissions)

**Reference**: SYS-REQ-6 - Browser shall implement permission controls for all device hardware access APIs

**Given**: A conformant browser with SYS-1 or higher capability

**Task**: Device hardware APIs provide access to sensitive capabilities like cameras, microphones, sensors, and location data that can be abused for surveillance, data theft, or privacy violations. Without permission controls, malicious websites could silently activate cameras for spying, record audio, or track user location. Per-origin permission prompts with explicit user consent, revocability, and cross-origin isolation prevent unauthorized device access while enabling legitimate functionality for trusted origins.

**Verification**:

1. Navigate to test page that requests camera access using navigator.mediaDevices.getUserMedia()
2. Verify permission prompt appears and requires explicit user action
3. Test microphone access and verify separate permission prompt
4. Check permission settings in browser UI through the content/privacy settings interface
5. Revoke camera permission and verify future access is blocked
6. Test permission persistence across browser restarts
7. Verify permissions are per-origin and not shared across origins
8. Test permission inheritance in cross-origin iframes (should be blocked)
9. Attempt to access device without permission and verify SecurityError thrown
10. Verify permissions can be permanently denied by user
11. All device API access triggers permission prompts
12. User shall explicitly grant permission (no auto-grant)
13. Permissions are origin-scoped and isolated
14. Cross-origin iframe access is blocked by default
15. Permission state is persistent and survives restarts
16. Users can revoke permissions at any time
17. Denied permissions throw appropriate errors
18. Permission prompts include clear device/API information
19. Temporary permission grants expire appropriately

**Pass Criteria**: Device access requires explicit permission AND prompts are clear AND permissions are per-origin AND revocation works

**Fail Criteria**: Device access without permission OR auto-grant occurs OR permissions not per-origin OR revocation doesn't work

**Evidence**: Permission prompt screenshots, settings UI showing permissions, console logs of SecurityErrors, cross-origin test results, permission persistence tests, revocation verification

**References**:

- Permissions API: https://www.w3.org/TR/permissions/
- Media Capture and Streams: https://www.w3.org/TR/mediacapture-streams/
- Permission Delegation: https://www.w3.org/TR/permissions-policy-1/
- MDN Permissions: https://developer.mozilla.org/en-US/docs/Web/API/Permissions_API

### Assessment: SYS-REQ-7 (PWA permission management)

**Reference**: SYS-REQ-7 - Browser shall enforce equivalent permission controls for Progressive Web Apps as for regular web content

**Given**: A conformant browser with PWA-1 and SYS-1 or higher capability

**Task**: Progressive Web Apps installed as standalone applications may appear more trustworthy to users, creating opportunities for permission abuse if PWAs receive elevated privileges compared to web contexts. Auto-granting permissions during PWA installation would bypass informed consent, while allowing service workers to circumvent permission checks enables background surveillance. Enforcing equivalent permission controls for PWAs as web content prevents privilege escalation through installation while ensuring permission revocation upon uninstallation.

**Verification**:

1. Install a test PWA with manifest requesting various permissions
2. Verify that PWA installation does not auto-grant permissions
3. Launch PWA and trigger permission requests (camera, location, notifications)
4. Verify permission prompts appear identical to browser context
5. Check that PWA permissions are isolated per origin in browser settings
6. Test that uninstalling PWA revokes all granted permissions
7. Verify PWA cannot request more permissions than web context
8. Test permission state is synchronized between PWA and browser views of same origin
9. Attempt to bypass permission via service worker and verify blocking
10. Verify PWA display mode (standalone, fullscreen) does not affect permission requirements
11. PWA installation does not auto-grant permissions
12. Permission prompts appear for all sensitive APIs
13. Permissions are per-origin, shared with web context
14. Uninstalling PWA revokes granted permissions
15. Service workers cannot bypass permission checks
16. Display mode does not affect permission requirements
17. PWA permissions visible in browser settings
18. Permission state synchronized across contexts

**Pass Criteria**: PWA permissions equal to web permissions AND no auto-grant on install AND uninstall revokes permissions AND service workers respect permissions

**Fail Criteria**: PWA gets extra permissions OR auto-grant on install OR uninstall doesn't revoke OR service worker bypass

**Evidence**: PWA installation flow screenshots, permission prompt comparisons, settings showing PWA permissions, uninstall verification tests, service worker permission logs, display mode test results

**References**:

- Web App Manifest: https://www.w3.org/TR/appmanifest/
- PWA Permissions: https://web.dev/articles/install-criteria
- Service Worker Security: https://www.w3.org/TR/service-workers/#security-considerations
- Permissions Policy in PWAs: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Permissions-Policy

### Assessment: SYS-REQ-8 (Geolocation permission enforcement)

**Reference**: SYS-REQ-8 - Browser shall enforce user permission requirements for geolocation API access

**Given**: A conformant browser with SYS-1 or higher capability

**Task**: Geolocation APIs expose precise user location data that enables physical tracking, stalking, burglary planning, and profiling of user movements and routines. Without HTTPS requirements and permission controls, attackers on insecure connections could intercept location data, while malicious sites could track users without consent. HTTPS enforcement, per-origin permission prompts, immediate revocation, and cross-origin isolation prevent unauthorized location tracking while enabling legitimate location-based services.

**Verification**:

1. Navigate to test page that calls navigator.geolocation.getCurrentPosition()
2. Verify permission prompt appears before any location data is returned
3. Test that HTTPS context is required for geolocation (HTTP should fail)
4. Grant permission and verify location data is returned
5. Revoke permission and verify subsequent calls are denied
6. Test high-accuracy mode requires explicit permission
7. Verify watchPosition() respects same permission model
8. Test that cross-origin iframes require permission policy delegation
9. Attempt geolocation access without user gesture and verify it still requires permission
10. Verify location permission can be set to "ask every time"
11. Geolocation API requires HTTPS context (except localhost)
12. Permission prompt appears before any location data access
13. Permission is per-origin and persistent
14. High-accuracy mode requires explicit permission
15. Cross-origin access blocked without delegation
16. Revoked permissions immediately block access
17. Users can set "ask every time" preference
18. Permission state is accessible via Permissions API

**Pass Criteria**: HTTPS required AND permission prompt appears AND per-origin isolation AND revocation works AND cross-origin blocked

**Fail Criteria**: HTTP allows access OR no permission prompt OR not per-origin OR revocation doesn't work OR cross-origin allowed

**Evidence**: Permission prompt screenshots, HTTPS requirement test results, permission settings showing geolocation, cross-origin test logs, revocation verification, console errors for denied access

**References**:

- Geolocation API: https://www.w3.org/TR/geolocation-API/
- Geolocation Security: https://w3c.github.io/geolocation-api/#security
- Secure Contexts: https://www.w3.org/TR/secure-contexts/
- MDN Geolocation: https://developer.mozilla.org/en-US/docs/Web/API/Geolocation_API

### Assessment: SYS-REQ-9 (Camera/microphone access control)

**Reference**: SYS-REQ-9 - Browser shall enforce strict permission controls for camera and microphone access with user-visible indicators

**Given**: A conformant browser with SYS-1 or higher capability

**Task**: Camera and microphone access enables covert surveillance, recording private conversations, capturing sensitive visual information, and violating user privacy. Without visible indicators, malicious sites could secretly record audio/video for blackmail, espionage, or data theft. Permission prompts with device selection, persistent active-use indicators, immediate mid-stream revocation, and cross-origin blocking prevent unauthorized surveillance while providing user transparency and control over their devices.

**Verification**:

1. Navigate to test page that requests camera access via getUserMedia({video: true})
2. Verify permission prompt appears with device selection options
3. Grant permission and verify camera indicator appears in browser UI (red dot, icon)
4. Test microphone access separately and verify distinct permission prompt
5. Request both camera and microphone and verify single combined prompt
6. Verify active use indicators remain visible while devices are active
7. Test that stopping media stream removes indicators
8. Verify users can revoke permission mid-stream and devices immediately stop
9. Test that cross-origin iframes cannot inherit camera/microphone permissions
10. Verify permission prompts identify requesting origin clearly
11. Separate permission prompts for camera and microphone
12. Device selection available in permission prompt
13. Visual indicators appear when camera/microphone active
14. Indicators remain visible for entire use duration
15. Stopping stream immediately removes indicators
16. Mid-stream revocation immediately stops device access
17. Cross-origin iframe access blocked without delegation
18. Permission prompts clearly show requesting origin
19. Users can select specific device or deny access

**Pass Criteria**: Permission prompts appear AND active-use indicators visible AND mid-stream revocation works AND cross-origin blocked

**Fail Criteria**: No permission prompt OR no indicators OR revocation doesn't stop devices OR cross-origin allowed

**Evidence**: Permission prompt screenshots, active camera/microphone indicator screenshots, device selection UI, cross-origin test results, mid-stream revocation tests, origin display verification

**References**:

- Media Capture and Streams: https://www.w3.org/TR/mediacapture-streams/
- getUserMedia Security: https://w3c.github.io/mediacapture-main/#security-and-permissions
- Firefox Camera Privacy: https://support.mozilla.org/en-US/kb/how-manage-your-camera-and-microphone-permissions

### Assessment: SYS-REQ-10 (Clipboard access restrictions)

**Reference**: SYS-REQ-10 - Browser shall restrict clipboard access to require user interaction or explicit permission

**Given**: A conformant browser with SYS-1 or higher capability

**Task**: Clipboard access enables theft of sensitive data like passwords, credit card numbers, authentication tokens, and private communications that users copy. Unrestricted clipboard reading allows malicious sites to silently exfiltrate clipboard contents, while background clipboard access enables persistent monitoring. User gesture requirements for writing, permission prompts for reading, background access blocking, and cross-origin restrictions prevent clipboard-based data theft while enabling legitimate copy/paste functionality.

**Verification**:

1. Test document.execCommand('copy') and verify it requires user gesture
2. Attempt clipboard write without user gesture and verify it's blocked
3. Test Async Clipboard API (navigator.clipboard.writeText()) and verify permission model
4. Attempt clipboard read using navigator.clipboard.readText() and verify permission prompt
5. Test clipboard access in background tab and verify it's blocked
6. Verify cross-origin iframe clipboard access requires permission policy
7. Test that clipboard events (copy, cut, paste) are only triggered by user actions
8. Verify sensitive data types (images, rich text) require explicit permission
9. Test that clipboard access from service workers is restricted
10. Verify clipboard history is not accessible without permission
11. Legacy clipboard API requires user gesture
12. Async Clipboard API requires permission for reading
13. Background clipboard access is blocked
14. Cross-origin access requires permission policy delegation
15. Clipboard events only fire from user-initiated actions
16. Sensitive data types require explicit permission
17. Service worker clipboard access is restricted
18. No access to clipboard history without permission
19. Permission prompts are clear about clipboard access

**Pass Criteria**: User gesture required for write AND permission required for read AND background access blocked AND cross-origin requires delegation

**Fail Criteria**: Write without gesture OR read without permission OR background access allowed OR cross-origin not restricted

**Evidence**: Clipboard permission prompt screenshots, console logs showing blocked access, user gesture test results, cross-origin test logs, background tab test results, service worker restriction verification

**References**:

- Clipboard API: https://www.w3.org/TR/clipboard-apis/
- Async Clipboard API: https://w3c.github.io/clipboard-apis/
- Clipboard Security Model: https://w3c.github.io/clipboard-apis/#security
- MDN Clipboard API: https://developer.mozilla.org/en-US/docs/Web/API/Clipboard_API

### Assessment: SYS-REQ-11 (Notification permission management)

**Reference**: SYS-REQ-11 - Browser shall enforce permission controls for web notifications with user-visible prompts

**Given**: A conformant browser with SYS-1 or higher capability

**Task**: Web notifications enable persistent user engagement but create vectors for notification spam, phishing through fake system alerts, social engineering attacks via deceptive messages, and user annoyance leading to permission fatigue. Without permission controls, malicious sites could bombard users with unwanted notifications or craft convincing fake alerts mimicking system messages. User gesture requirements, permission prompts, per-origin isolation, and service worker permission enforcement prevent notification abuse while enabling legitimate push messaging.

**Verification**:

1. Test Notification.requestPermission() and verify user prompt appears
2. Verify notification requests require user gesture (click/tap)
3. Grant permission and test notification display using new Notification()
4. Verify notifications from different origins are isolated
5. Test notification permission revocation and verify no more notifications appear
6. Verify service worker notifications respect same permission model
7. Test that cross-origin iframes cannot inherit notification permission
8. Verify permission state is accessible via Notification.permission
9. Test notification action buttons and verify they maintain security context
10. Verify silent notifications (without sound/vibration) still require permission
11. Notification permission requires explicit user grant
12. Permission prompt appears before any notification shown
13. User gesture required to trigger permission prompt
14. Permissions are per-origin and isolated
15. Service worker notifications use same permission
16. Cross-origin iframe access blocked without delegation
17. Permission revocation immediately prevents notifications
18. Notification.permission accurately reflects state
19. Action buttons maintain security context
20. All notification types require permission

**Pass Criteria**: Permission prompt required AND user gesture needed AND per-origin isolation AND service workers respect permissions

**Fail Criteria**: No permission prompt OR no user gesture required OR not per-origin OR service worker bypass

**Evidence**: Permission prompt screenshots, user gesture requirement tests, service worker notification tests, cross-origin test results, revocation verification, notification display examples

**References**:

- Notifications API: https://notifications.spec.whatwg.org/
- Notification Security: https://notifications.spec.whatwg.org/#security-and-privacy
- Push API: https://www.w3.org/TR/push-api/
- Service Worker Notifications: https://web.dev/articles/push-notifications-overview
- Chrome Notifications: https://developer.chrome.com/docs/extensions/reference/notifications/

### Assessment: SYS-REQ-12 (USB device access security)

**Reference**: SYS-REQ-12 - Browser shall enforce strict permission and security controls for WebUSB device access

**Given**: A conformant browser with SYS-1 or higher capability and WebUSB support

**Task**: WebUSB provides direct hardware access to USB devices, creating risks of firmware attacks, data exfiltration through storage devices, keystroke logging via HID devices, and unauthorized control of sensitive peripherals. Without restrictions, malicious sites could access mass storage to read private files, reprogram device firmware, or communicate with security keys to bypass authentication. HTTPS requirements, device picker prompts, dangerous class filtering, and per-device permissions prevent USB-based attacks while enabling legitimate device interaction.

**Verification**:

1. Navigate to test page that calls navigator.usb.requestDevice()
2. Verify permission prompt appears with device picker showing available USB devices
3. Test that HTTPS context is required for WebUSB (HTTP should fail)
4. Grant access to specific USB device and verify connection succeeds
5. Verify that only explicitly granted device is accessible
6. Test device access from cross-origin iframe and verify it's blocked
7. Attempt to access USB device without user gesture and verify it's blocked
8. Revoke USB permission and verify device access is immediately blocked
9. Test that dangerous device classes (HID, mass storage) are filtered from device picker
10. Verify device disconnect/reconnect requires re-authorization if permission was revoked
11. WebUSB requires HTTPS context (except localhost)
12. Permission prompt shows device picker with clear device identification
13. Only explicitly selected devices are accessible
14. User gesture required to trigger device selection
15. Cross-origin access blocked without permission policy
16. Dangerous device classes (HID, storage) are not available
17. Permission revocation immediately blocks device access
18. Device access is per-origin and isolated
19. Device picker shows only appropriate devices
20. Reconnected devices respect permission state

**Pass Criteria**: HTTPS required AND device picker shown AND only selected devices accessible AND dangerous classes blocked

**Fail Criteria**: HTTP allows access OR no device picker OR all devices accessible OR dangerous classes available

**Evidence**: WebUSB permission prompt screenshots, device picker UI, HTTPS requirement tests, dangerous device class filtering tests, cross-origin test results, revocation verification

**References**:

- WebUSB API: https://wicg.github.io/webusb/
- WebUSB Security: https://wicg.github.io/webusb/#security-and-privacy
- USB Device Class Codes: https://www.usb.org/defined-class-codes
- Chrome WebUSB: https://developer.chrome.com/articles/build-for-webusb/

### Assessment: SYS-REQ-13 (Bluetooth permission enforcement)

**Reference**: SYS-REQ-13 - Browser shall enforce permission controls and security restrictions for Web Bluetooth API

**Given**: A conformant browser with SYS-1 or higher capability and Web Bluetooth support

**Task**: Web Bluetooth enables wireless communication with Bluetooth devices, creating risks of unauthorized pairing with sensitive peripherals, GATT service exploitation to extract data or modify device settings, and attacks on Bluetooth-enabled security devices or medical equipment. Without controls, malicious sites could pair with fitness trackers to steal health data, connect to Bluetooth keyboards to log keystrokes, or interact with dangerous device types. HTTPS requirements, device picker prompts, service UUID filtering, and blocklist enforcement prevent Bluetooth-based attacks.

**Verification**:

1. Navigate to test page that calls navigator.bluetooth.requestDevice()
2. Verify permission prompt appears with Bluetooth device picker
3. Test that HTTPS context is required for Web Bluetooth (HTTP should fail)
4. Grant access to specific Bluetooth device and verify GATT connection
5. Verify only explicitly granted device is accessible
6. Test service UUID filtering in device picker
7. Attempt Bluetooth access without user gesture and verify blocking
8. Test cross-origin iframe access and verify it's blocked
9. Revoke Bluetooth permission and verify device access is blocked
10. Verify Bluetooth blocklist prevents access to dangerous device types
11. Web Bluetooth requires HTTPS context (except localhost)
12. Permission prompt shows Bluetooth device picker
13. Only explicitly selected devices are accessible
14. Service UUID filtering works correctly
15. User gesture required to trigger device selection
16. Cross-origin access blocked without delegation
17. Dangerous device types blocked by blocklist
18. Permission revocation immediately blocks access
19. Device access is per-origin and isolated
20. GATT operations respect permission boundaries

**Pass Criteria**: HTTPS required AND device picker shown AND only selected devices accessible AND blocklist enforced

**Fail Criteria**: HTTP allows access OR no device picker OR all devices accessible OR blocklist not enforced

**Evidence**: Bluetooth permission prompt screenshots, device picker UI, service UUID filtering tests, HTTPS requirement verification, blocklist enforcement tests, cross-origin test results

**References**:

- Web Bluetooth API: https://webbluetoothcg.github.io/web-bluetooth/
- Web Bluetooth Security: https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy
- Bluetooth GATT Services: https://www.bluetooth.com/specifications/gatt/
- Chrome Web Bluetooth: https://developer.chrome.com/articles/bluetooth/
- Web Bluetooth Blocklist: https://github.com/WebBluetoothCG/registries/blob/master/gatt_blocklist.txt

### Assessment: SYS-REQ-14 (File System Access API security)

**Reference**: SYS-REQ-14 - Browser shall enforce strict security controls for File System Access API including user permission and path restrictions

**Given**: A conformant browser with SYS-1 or higher capability and File System Access API support

**Task**: File System Access API provides powerful capabilities to read and write local files and directories, creating risks of unauthorized data exfiltration, ransomware-style file encryption, malicious file modification, and access to sensitive system directories. Without strict controls, malicious sites could silently read user documents, modify critical files, or encrypt files for ransom. OS-native file pickers, separate write confirmation, system directory filtering, and per-access authorization prevent filesystem abuse while enabling legitimate file editing applications.

**Verification**:

1. Test window.showOpenFilePicker() and verify file picker dialog appears
2. Verify user should explicitly select files through OS file picker
3. Test window.showDirectoryPicker() and verify directory picker dialog
4. Grant directory access and verify files within are accessible
5. Test write access requires separate user confirmation
6. Attempt to access system directories and verify blocking/filtering
7. Test that file handles persist and verify permission prompt on reuse
8. Verify cross-origin iframes cannot access file handles
9. Test permission revocation clears all file handles
10. Verify HTTPS context required for persistent permissions
11. OS file/directory picker appears for all access requests
12. User should explicitly select files/directories
13. Write access requires separate confirmation
14. System directories are blocked or filtered from picker
15. File handles require permission on reuse after restart
16. Cross-origin access to file handles is blocked
17. HTTPS required for persistent file handle permissions
18. Permission revocation clears all granted handles
19. Each file/directory access is separately authorized
20. No programmatic file system enumeration possible

**Pass Criteria**: OS picker required AND write needs confirmation AND system directories blocked AND handles require reauthorization

**Fail Criteria**: No picker shown OR write without confirmation OR system directories accessible OR handles work without reauth

**Evidence**: File picker screenshots, directory picker UI, write confirmation prompts, system directory blocking tests, file handle persistence tests, cross-origin blocking verification

**References**:

- File System Access API: https://wicg.github.io/file-system-access/
- File System Access Security: https://wicg.github.io/file-system-access/#privacy-considerations
- Chrome File System Access: https://developer.chrome.com/articles/file-system-access/
- WHATWG File System: https://fs.spec.whatwg.org/
- OWASP File Security: https://cheatsheetseries.owasp.org/cheatsheets/File_Upload_Cheat_Sheet.html

### Assessment: SYS-REQ-15 (WebUSB security controls)