EN-304-617_v0.0.5.md

5. Deploy policy to managed browser → Test that policy changes propagate immediately or on restart
6. Test that allowed protocols can be registered and used → Verify that policy status is visible in browser management UI
7. Verify that blocked protocols cannot be registered → Test that attempting blocked protocol shows enterprise policy message

**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") → Test that schemes conflicting with browser internals are rejected
2. Verify that registration succeeds without requiring web+ prefix → Verify that schemes matching standard protocols (http, ftp) are rejected
3. Test that registered handler functions correctly when invoked → Test that OS-level protocol conflicts are detected and warned about
4. Verify that schemes without web+ prefix are marked with security warning → Verify that documentation explains risks of non-web+ schemes
5. Test registration of common non-web+ schemes: → Test that handler management UI shows prefix status
   - Application launchers (myapp://)
   - Internal tools (tool://)
   - Legacy protocols (custom://)
6. Verify that registration still requires user consent → 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 → Test that list can be filtered or searched
2. Access browser settings to find protocol handler management → Verify that clicking handler shows detailed information:
   - Full handler URL template
   - Registering origin
   - Number of invocations
   - Security warnings if applicable
3. Verify that handler list is easily accessible: → Test that handlers can be removed from this interface
   - 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: → Verify that handler changes (add/remove) update list immediately
   - 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: → Test that export/backup of handler list is available
   - Web+ prefixed schemes
   - Non-web+ custom schemes
   - Built-in handler overrides (mailto, etc.)

**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: → Test periodic rescanning of registered handlers:
   - Command injection patterns (e.g., URL with shell metacharacters)
   - Path traversal attempts (../ sequences)
   - SQL injection patterns
   - Script injection patterns (<script>, javascript:)
   - Check if scan runs on browser updates (new vulnerability signatures)
   - Verify notification if previously-safe handler becomes vulnerable
2. Verify that browser detects and warns about vulnerable patterns → Verify that vulnerability database is updated regularly
3. Test that scan occurs before handler registration completes → Test that false positives can be reported
4. Verify that detected vulnerabilities are clearly explained to user → Verify that scan covers various attack vectors:
   - Local command execution
   - File system access
   - Network exfiltration
   - Cross-origin data access
5. Test that high-severity vulnerabilities block registration → Test that scan results are logged for security auditing
6. Verify that medium-severity issues show strong warning but allow registration → 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: → Verify that logs can be exported or forwarded to SIEM
   - 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 → Test that log tampering is prevented or detected
3. Verify that all events are logged with comprehensive details: → Verify that high-severity events trigger immediate log entries
   - 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) → Test that logging does not expose sensitive user data
5. Verify that logs can be filtered by event type, scheme, or time range → Verify that logs are accessible to security administrators
6. Test that logs are retained for appropriate period (configurable) → 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) → Verify that sandbox violations are logged and processes are terminated on policy violations
2. Open the browser's internal process viewer through the browser's debugging interface or task manager → All renderer processes execute within OS-level sandbox (seccomp-bpf on Linux, sandbox-exec on macOS, Job Objects on Windows)
3. Navigate to a test web page and verify it runs in a sandboxed renderer process → Sandboxed processes cannot access filesystem outside designated cache directories
4. Attempt to execute system calls from JavaScript that should be blocked (file system access, process creation) → System call filtering is active and blocks dangerous syscalls (execve, fork, ptrace)
5. Use platform-specific tools to inspect process sandbox status (Process Explorer on Windows, ps with security flags on Linux/macOS) → Process privileges are reduced (no root, limited capabilities, restricted tokens)
6. Verify renderer processes run with reduced privileges using tools like icacls, getfacl, or sandbox-exec -p → Memory isolation prevents cross-process memory access
7. Test that sandboxed processes cannot access parent process memory → Network access is mediated through broker process
8. Attempt to escape sandbox through known attack vectors and verify containment → Sandbox escape attempts are blocked and logged
9. Monitor system calls using strace (Linux), dtruss (macOS), or Process Monitor (Windows) to verify syscall filtering → 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 → Test process-per-site-instance isolation for enhanced security
2. Use the browser's process viewer to verify each origin runs in a separate renderer process → Each origin or site instance runs in a dedicated renderer process
3. Open developer tools and use performance profiling to identify process boundaries → Process IDs are distinct and verifiable through OS tools
4. Test Site Isolation by navigating to cross-origin iframes and verifying separate processes → Renderer process crashes are isolated and do not cascade
5. Attempt to access memory or data from one renderer process in another using side-channel attacks → No shared memory regions exist between different renderer processes
6. Verify that process IDs are distinct for different origins using OS tools (ps, Task Manager) → Inter-process communication uses secure, mediated IPC channels
7. Test that renderer crashes in one tab do not affect other tabs or the browser process → Browser core process (broker) is isolated from all renderers
8. Monitor inter-process communication to verify it goes through secure IPC channels → GPU process isolation is separate from renderer isolation
9. Use memory analysis tools to verify no shared memory regions between renderers → 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 → Verify that software rendering fallback maintains process isolation
2. Open a WebGL-intensive page (e.g., https://webglsamples.org/) and verify GPU process activation → GPU process runs as separate, distinct process with unique PID
3. Use OS process viewer to identify the GPU process and verify it's distinct from renderers → GPU process executes within OS-level sandbox with reduced privileges
4. Check GPU process sandbox status using platform-specific security tools → GPU command buffers are validated before submission to driver
5. Verify GPU process has limited capabilities and cannot access filesystem directly → GPU process cannot directly access filesystem or network
6. Test that GPU process crashes do not terminate the browser or renderer processes → Crashes in GPU process trigger graceful degradation (software rendering)
7. Monitor GPU command buffer submissions to verify they're sanitized and validated → Graphics driver access is mediated and monitored
8. Attempt to exploit GPU driver vulnerabilities and verify sandbox containment → Shader compilation occurs in isolated context
9. Use graphics debugging tools (apitrace, RenderDoc) to analyze GPU process isolation → 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 → Test that network service crashes trigger appropriate error handling
2. Verify network service runs as separate process or is isolated within browser process → Network operations execute in isolated network service/process
3. Use network analysis tools (Wireshark, tcpdump) to monitor network requests from different processes → Renderer processes cannot directly access network APIs
4. Test that renderer processes cannot directly create network sockets → All network requests are mediated through network service
5. Verify all network requests are mediated through network service/process → Certificate validation occurs in privileged context
6. Attempt to bypass network service from renderer process and verify blocking → CORS and content security policies are enforced at network layer
7. Monitor network service sandbox status using platform security tools → Network service runs with minimal necessary privileges
8. Test certificate validation occurs in network service, not renderer → Socket creation is controlled and monitored
9. Verify CORS and CSP enforcement happens in network service layer → 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 → Check that filesystem access permissions are revoked when tab closes
2. Test File API access from web content and verify it requires user gesture → file:// URL access is restricted or requires user opt-in
3. Use File System Access API to request directory access and verify user prompt appears → File API requires user gesture (click/tap) for access
4. Monitor filesystem access from renderer process using system tools (auditd, OpenBSM, Process Monitor) → File System Access API shows permission prompts
5. Verify browser cache and profile directories are protected from direct renderer access → Renderer processes cannot directly access filesystem
6. Test that sandboxed filesystem namespace limits visible paths → System directories are not accessible from web content
7. Attempt to access system directories (/etc, C:\\Windows) from web content and verify blocking → Browser profile and cache protected from renderer access
8. Verify file uploads use secure IPC to broker process for filesystem access → File operations use IPC to privileged broker process
9. Test that downloaded files are stored in user-designated locations only → Filesystem permissions are per-origin and revocable

**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() → Verify permissions can be permanently denied by user
2. Verify permission prompt appears and requires explicit user action → All device API access triggers permission prompts
3. Test microphone access and verify separate permission prompt → User shall explicitly grant permission (no auto-grant)
4. Check permission settings in browser UI through the content/privacy settings interface → Permissions are origin-scoped and isolated
5. Revoke camera permission and verify future access is blocked → Cross-origin iframe access is blocked by default
6. Test permission persistence across browser restarts → Permission state is persistent and survives restarts
7. Verify permissions are per-origin and not shared across origins → Users can revoke permissions at any time
8. Test permission inheritance in cross-origin iframes (should be blocked) → Denied permissions throw appropriate errors
9. Attempt to access device without permission and verify SecurityError thrown → Permission prompts include clear device/API information

**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 → Verify PWA display mode (standalone, fullscreen) does not affect permission requirements
2. Verify that PWA installation does not auto-grant permissions → PWA installation does not auto-grant permissions
3. Launch PWA and trigger permission requests (camera, location, notifications) → Permission prompts appear for all sensitive APIs
4. Verify permission prompts appear identical to browser context → Permissions are per-origin, shared with web context
5. Check that PWA permissions are isolated per origin in browser settings → Uninstalling PWA revokes granted permissions
6. Test that uninstalling PWA revokes all granted permissions → Service workers cannot bypass permission checks
7. Verify PWA cannot request more permissions than web context → Display mode does not affect permission requirements
8. Test permission state is synchronized between PWA and browser views of same origin → PWA permissions visible in browser settings
9. Attempt to bypass permission via service worker and verify blocking → 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() → Verify location permission can be set to "ask every time"
2. Verify permission prompt appears before any location data is returned → Geolocation API requires HTTPS context (except localhost)
3. Test that HTTPS context is required for geolocation (HTTP should fail) → Permission prompt appears before any location data access
4. Grant permission and verify location data is returned → Permission is per-origin and persistent
5. Revoke permission and verify subsequent calls are denied → High-accuracy mode requires explicit permission
6. Test high-accuracy mode requires explicit permission → Cross-origin access blocked without delegation
7. Verify watchPosition() respects same permission model → Revoked permissions immediately block access
8. Test that cross-origin iframes require permission policy delegation → Users can set "ask every time" preference
9. Attempt geolocation access without user gesture and verify it still requires permission → 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}) → Verify permission prompts identify requesting origin clearly
2. Verify permission prompt appears with device selection options → Separate permission prompts for camera and microphone
3. Grant permission and verify camera indicator appears in browser UI (red dot, icon) → Device selection available in permission prompt
4. Test microphone access separately and verify distinct permission prompt → Visual indicators appear when camera/microphone active
5. Request both camera and microphone and verify single combined prompt → Indicators remain visible for entire use duration
6. Verify active use indicators remain visible while devices are active → Stopping stream immediately removes indicators
7. Test that stopping media stream removes indicators → Mid-stream revocation immediately stops device access
8. Verify users can revoke permission mid-stream and devices immediately stop → Cross-origin iframe access blocked without delegation
9. Test that cross-origin iframes cannot inherit camera/microphone permissions → Permission prompts clearly show requesting origin

**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 → Verify clipboard history is not accessible without permission
2. Attempt clipboard write without user gesture and verify it's blocked → Legacy clipboard API requires user gesture
3. Test Async Clipboard API (navigator.clipboard.writeText()) and verify permission model → Async Clipboard API requires permission for reading
4. Attempt clipboard read using navigator.clipboard.readText() and verify permission prompt → Background clipboard access is blocked
5. Test clipboard access in background tab and verify it's blocked → Cross-origin access requires permission policy delegation
6. Verify cross-origin iframe clipboard access requires permission policy → Clipboard events only fire from user-initiated actions
7. Test that clipboard events (copy, cut, paste) are only triggered by user actions → Sensitive data types require explicit permission
8. Verify sensitive data types (images, rich text) require explicit permission → Service worker clipboard access is restricted
9. Test that clipboard access from service workers is restricted → No access to clipboard history without permission

**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 → Notification permission requires explicit user grant
2. Verify notification requests require user gesture (click/tap) → Permission prompt appears before any notification shown
3. Grant permission and test notification display using new Notification() → User gesture required to trigger permission prompt
4. Verify notifications from different origins are isolated → Permissions are per-origin and isolated
5. Test notification permission revocation and verify no more notifications appear → Service worker notifications use same permission
6. Verify service worker notifications respect same permission model → Cross-origin iframe access blocked without delegation
7. Test that cross-origin iframes cannot inherit notification permission → Permission revocation immediately prevents notifications
8. Verify permission state is accessible via Notification.permission → Notification.permission accurately reflects state
9. Test notification action buttons and verify they maintain security context → Action buttons maintain security context
10. Verify silent notifications (without sound/vibration) still require permission → 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() → WebUSB requires HTTPS context (except localhost)
2. Verify permission prompt appears with device picker showing available USB devices → Permission prompt shows device picker with clear device identification
3. Test that HTTPS context is required for WebUSB (HTTP should fail) → Only explicitly selected devices are accessible
4. Grant access to specific USB device and verify connection succeeds → User gesture required to trigger device selection
5. Verify that only explicitly granted device is accessible → Cross-origin access blocked without permission policy
6. Test device access from cross-origin iframe and verify it's blocked → Dangerous device classes (HID, storage) are not available
7. Attempt to access USB device without user gesture and verify it's blocked → Permission revocation immediately blocks device access
8. Revoke USB permission and verify device access is immediately blocked → Device access is per-origin and isolated
9. Test that dangerous device classes (HID, mass storage) are filtered from device picker → Device picker shows only appropriate devices
10. Verify device disconnect/reconnect requires re-authorization if permission was revoked → 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() → Web Bluetooth requires HTTPS context (except localhost)
2. Verify permission prompt appears with Bluetooth device picker → Permission prompt shows Bluetooth device picker
3. Test that HTTPS context is required for Web Bluetooth (HTTP should fail) → Only explicitly selected devices are accessible
4. Grant access to specific Bluetooth device and verify GATT connection → Service UUID filtering works correctly
5. Verify only explicitly granted device is accessible → User gesture required to trigger device selection
6. Test service UUID filtering in device picker → Cross-origin access blocked without delegation
7. Attempt Bluetooth access without user gesture and verify blocking → Dangerous device types blocked by blocklist
8. Test cross-origin iframe access and verify it's blocked → Permission revocation immediately blocks access
9. Revoke Bluetooth permission and verify device access is blocked → Device access is per-origin and isolated
10. Verify Bluetooth blocklist prevents access to dangerous device types → 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 → OS file/directory picker appears for all access requests
2. Verify user should explicitly select files through OS file picker → User should explicitly select files/directories
3. Test window.showDirectoryPicker() and verify directory picker dialog → Write access requires separate confirmation
4. Grant directory access and verify files within are accessible → System directories are blocked or filtered from picker
5. Test write access requires separate user confirmation → File handles require permission on reuse after restart
6. Attempt to access system directories and verify blocking/filtering → Cross-origin access to file handles is blocked
7. Test that file handles persist and verify permission prompt on reuse → HTTPS required for persistent file handle permissions
8. Verify cross-origin iframes cannot access file handles → Permission revocation clears all granted handles
9. Test permission revocation clears all file handles → Each file/directory access is separately authorized
10. Verify HTTPS context required for persistent permissions → 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)

**Reference**: SYS-REQ-15 - Browser shall implement comprehensive security controls for WebUSB including device filtering, permission management, and secure contexts

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

**Task**: WebUSB's comprehensive device access requires layered security controls beyond basic permission prompts to prevent exploitation of protected device classes, dangerous control transfers, and vendor-sensitive devices. Without interface class filtering, attackers could claim HID interfaces to log keystrokes or access mass storage to exfiltrate files. Control transfer validation, protected class filtering, vendor opt-out respect, and secure context requirements create defense-in-depth protection for USB device interactions.

**Verification**:

1. Test navigator.usb.getDevices() and verify only previously authorized devices returned → Protected USB device classes are never shown in picker
2. Verify protected USB classes are filtered (HID keyboards/mice, mass storage, video, audio) → Only secure contexts can access WebUSB API
3. Test USB device access requires user activation (transient user gesture) → User activation required for device requests
4. Verify vendors can opt out devices via USB device descriptor → Previously authorized devices require getDevices() call
5. Test that WebUSB requires secure context (HTTPS or localhost) → Protected interface classes cannot be claimed
6. Attempt interface claiming on protected interface classes and verify blocking → Device connection events only for authorized devices
7. Test USB device connection events fire only for authorized devices → Control transfers are validated for safety
8. Verify control transfers are validated and potentially dangerous ones blocked → Permissions Policy successfully restricts WebUSB
9. Test that permissions-policy can restrict WebUSB in iframes → DevTools shows USB activity for debugging
10. Verify USB device access is auditable through DevTools protocol → Vendor opt-out mechanism is respected

**Pass Criteria**: Protected classes filtered AND secure context required AND user activation needed AND control transfers validated

**Fail Criteria**: Protected classes available OR insecure context works OR no user activation required OR dangerous transfers allowed

**Evidence**: Device picker showing filtered devices, secure context requirement tests, protected interface class blocking logs, control transfer validation tests, Permissions Policy test results

**References**:

- WebUSB Specification: https://wicg.github.io/webusb/
- WebUSB Protected Interface Classes: https://wicg.github.io/webusb/#protected-interface-classes
- USB Implementers Forum: https://www.usb.org/
- Chrome WebUSB Security: https://chromium.googlesource.com/chromium/src/+/refs/heads/main/docs/security/permissions-for-powerful-web-platform-features.md

### Assessment: SYS-REQ-16 (WebBluetooth security)

**Reference**: SYS-REQ-16 - Browser shall implement security controls for Web Bluetooth including GATT blocklist, device filtering, and permission management

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

**Task**: Web Bluetooth GATT services provide deep access to device functionality, creating risks of HID service exploitation for keystroke injection, firmware update service abuse for device bricking or malware installation, and fingerprinting through device name enumeration. Without a comprehensive GATT blocklist, malicious sites could exploit dangerous services to compromise connected devices or user privacy. GATT blocklist enforcement, service UUID filtering, device name sanitization, and secure context requirements prevent Bluetooth-based attacks.

**Verification**:

1. Test navigator.bluetooth.getDevices() returns only previously authorized devices → Secure context (HTTPS/localhost) required for all Web Bluetooth APIs
2. Verify GATT blocklist prevents access to dangerous services (HID, firmware update) → User activation required for device requests
3. Test that Web Bluetooth requires secure context (HTTPS or localhost) → GATT blocklist prevents access to dangerous services/characteristics
4. Verify user activation required for requestDevice() calls → Service UUID filtering correctly limits accessible services
5. Test service UUID filters work correctly in device selection → Blocklisted characteristics return errors when accessed
6. Attempt to access blocklisted GATT characteristics and verify blocking → Optional services declared in requestDevice()
7. Test that optional services still require user awareness → Device names sanitized to prevent fingerprinting
8. Verify device name filtering prevents fingerprinting → Permissions Policy successfully restricts Web Bluetooth
9. Test permissions-policy restricts Web Bluetooth in cross-origin iframes → Bluetooth scanning requires separate permission
10. Verify Bluetooth scanning requires explicit user permission → Only previously granted devices in getDevices()

**Pass Criteria**: Secure context required AND GATT blocklist enforced AND user activation needed AND fingerprinting prevented

**Fail Criteria**: Insecure context works OR blocklist bypassed OR no user activation required OR fingerprinting possible

**Evidence**: Secure context requirement tests, GATT blocklist enforcement logs, service UUID filtering results, fingerprinting prevention tests, Permissions Policy test results

**References**:

- Web Bluetooth Specification: https://webbluetoothcg.github.io/web-bluetooth/
- Web Bluetooth GATT Blocklist: https://github.com/WebBluetoothCG/registries/blob/master/gatt_blocklist.txt
- Bluetooth GATT Specifications: https://www.bluetooth.com/specifications/specs/
- Web Bluetooth Security Model: https://webbluetoothcg.github.io/web-bluetooth/#security-and-privacy-considerations
- Chrome Web Bluetooth Security: https://sites.google.com/a/chromium.org/dev/developers/design-documents/bluetooth-design-docs

### Assessment: SYS-REQ-17 (WebNFC permission management)

**Reference**: SYS-REQ-17 - Browser shall enforce permission controls for Web NFC API with user prompts and secure context requirements

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

**Task**: Web NFC enables reading and writing NFC tags, creating risks of malicious tag writing to deploy phishing attacks, NFC relay attacks, unauthorized data collection from contactless payment cards, and privacy violations through persistent NFC scanning. Background NFC access could enable covert tag reading while users are unaware. Secure context requirements, permission prompts with user gestures, background operation blocking, and dangerous tag filtering prevent NFC-based attacks while enabling legitimate tag interactions.

**Verification**:

1. Test NDEFReader.scan() and verify permission prompt appears → Secure context (HTTPS/localhost) required for Web NFC
2. Verify Web NFC requires secure context (HTTPS or localhost) → Permission prompt appears before NFC access granted
3. Test that NFC access requires user gesture for permission prompt → User gesture required to trigger permission prompt
4. Grant NFC permission and verify scan operations work → Both scan and write operations respect same permission
5. Test NDEFReader.write() and verify it respects same permission → Cross-origin iframe access blocked without delegation
6. Verify cross-origin iframe NFC access is blocked without permission policy → Permission revocation stops active scans
7. Test permission revocation immediately stops NFC scanning → Background pages cannot perform NFC operations
8. Verify NFC operations blocked when page in background → Dangerous tag operations are restricted
9. Test that dangerous NFC tag types are filtered or sandboxed → Permissions are per-origin and isolated
10. Verify NFC access is per-origin and isolated → NFC indicators show when NFC is active

**Pass Criteria**: Secure context required AND permission prompt shown AND user gesture needed AND background access blocked

**Fail Criteria**: Insecure context works OR no permission prompt OR no user gesture required OR background access allowed

**Evidence**: NFC permission prompt screenshots, secure context requirement tests, user gesture verification, background access blocking tests, cross-origin test results, dangerous tag filtering verification

**References**:

- Web NFC API: https://w3c.github.io/web-nfc/
- Web NFC Security: https://w3c.github.io/web-nfc/#security-and-privacy
- NFC Forum Specifications: https://nfc-forum.org/our-work/specification-releases/
- Web NFC Explainer: https://github.com/w3c/web-nfc/blob/gh-pages/EXPLAINER.md

### Assessment: SYS-REQ-18 (Sensor API permissions)

**Reference**: SYS-REQ-18 - Browser shall enforce permission controls for Generic Sensor APIs including accelerometer, gyroscope, and magnetometer

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

**Task**: Generic Sensor APIs expose motion and environmental data that enable fingerprinting, keylogging through motion analysis, PIN theft via accelerometer side channels, and location tracking through magnetometer readings. High-frequency sensor access amplifies these attacks by providing precise timing data for cryptographic attacks. Secure context requirements, permission controls, background operation suspension, frequency limits, and Permissions Policy enforcement prevent sensor-based attacks while enabling legitimate motion and orientation detection.

**Verification**:

1. Test Accelerometer creation and verify permission prompt or policy enforcement → Secure context required for all Sensor APIs
2. Verify secure context required for sensor APIs → Permission prompts or policies apply before sensor access
3. Test Gyroscope access and verify same permission model → High-frequency access may require explicit permission
4. Create Magnetometer sensor and verify permissions → Sensors automatically pause in background
5. Test that high-frequency sensor access may require additional permissions → Cross-origin access requires Permissions Policy delegation
6. Verify sensors stop when page moves to background → Permissions are per-origin and isolated
7. Test cross-origin iframe sensor access requires permission policy delegation → Privacy-sensitive sensors have additional restrictions
8. Verify sensor permissions are per-origin → Permissions Policy can block sensor access
9. Test that ambient light sensor respects privacy considerations → Sensor frequency is limited to prevent fingerprinting
10. Verify sensor access can be blocked via Permissions Policy → Clear user controls for sensor permissions

**Pass Criteria**: Secure context required AND permissions enforced AND background pausing works AND Permissions Policy respected

**Fail Criteria**: Insecure context works OR no permissions enforced OR background access allowed OR policy ignored

**Evidence**: Sensor permission prompt screenshots, secure context requirement tests, background pausing verification, Permissions Policy test results, frequency limiting tests, cross-origin blocking verification

**References**:

- Generic Sensor API: https://www.w3.org/TR/generic-sensor/
- Sensor Security Model: https://www.w3.org/TR/generic-sensor/#security-and-privacy
- Accelerometer API: https://www.w3.org/TR/accelerometer/
- Gyroscope API: https://www.w3.org/TR/gyroscope/
- Permissions Policy: https://www.w3.org/TR/permissions-policy-1/

### Assessment: SYS-REQ-19 (Battery Status API restrictions)

**Reference**: SYS-REQ-19 - Browser shall implement privacy restrictions for Battery Status API to prevent fingerprinting

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

**Task**: Battery Status API historically enabled precise device fingerprinting through battery level, charging time, and discharge rate patterns that uniquely identify devices across browsing sessions and origins. High-precision battery data combined with timing information creates a persistent tracking identifier resistant to cookie deletion. Rounding battery levels, quantizing timing data, throttling updates, and rate limiting prevent battery-based fingerprinting while providing sufficient information for legitimate power management features.

**Verification**:

1. Test navigator.getBattery() and observe battery information returned → Battery level rounded to coarse granularity (e.g., 1% or 5%)
2. Verify battery level is rounded to prevent high-precision fingerprinting → Timing information quantized to prevent precise measurements
3. Test battery timing information is quantized to prevent tracking → Update frequency throttled to prevent tracking
4. Verify battery status updates are throttled → Secure context recommended for battery API access
5. Test that battery information is not available in insecure contexts → Cross-origin access requires Permissions Policy
6. Verify battery status in cross-origin iframes requires permission policy → Rate limiting prevents rapid polling
7. Test that frequent battery queries are rate-limited → Battery API can be disabled by user/policy
8. Verify battery API can be disabled via browser settings or policy → Charging state changes debounced
9. Test that battery charging state changes are debounced → No historical battery data exposed
10. Verify no access to detailed battery analytics or history → API surface minimized for privacy

**Pass Criteria**: Battery data quantized AND updates throttled AND rate limiting enforced AND no detailed analytics exposed

**Fail Criteria**: Precise battery data OR no throttling OR no rate limiting OR historical data exposed

**Evidence**: Battery level precision tests, timing quantization measurements, update frequency analysis, rate limiting verification, cross-origin test results, privacy analysis reports

**References**:

- Battery Status API: https://www.w3.org/TR/battery-status/
- Battery API Privacy Concerns: https://www.w3.org/TR/battery-status/#privacy-considerations
- Web API Privacy: https://www.w3.org/TR/fingerprinting-guidance/
- Chrome Battery Status: https://chromestatus.com/feature/4537134732017664

### Assessment: SYS-REQ-20 (Hardware resource limits)

**Reference**: SYS-REQ-20 - Browser shall enforce resource limits to prevent excessive consumption of CPU, memory, and system resources

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

**Task**: Unrestricted hardware resource consumption enables denial-of-service attacks that freeze browsers, crash systems, drain battery, or make devices unusable through memory exhaustion, CPU monopolization, or GPU resource depletion. Malicious scripts with infinite loops or excessive allocations can render browsers unresponsive. Per-origin resource limits, background throttling, script timeouts, and memory quotas prevent resource-based DoS attacks while maintaining browser and system responsiveness.

**Verification**:

1. Create test page that attempts to allocate excessive memory and verify limits → Memory allocation limits prevent excessive consumption
2. Test CPU-intensive operations and verify throttling or limits applied → CPU-intensive operations are throttled
3. Monitor browser resource usage with intensive JavaScript loops → Background tabs have reduced resource quotas
4. Test WebWorker resource limits and verify isolation → WebWorkers have separate resource limits
5. Verify background tab resource throttling is active → WebAssembly memory is bounded and enforced
6. Test WebAssembly memory limits and verify enforcement → GPU memory limits prevent resource exhaustion
7. Monitor GPU memory usage and verify limits on WebGL contexts → Script timeouts prevent infinite loops
8. Test that runaway scripts trigger timeout warnings or termination → Resource limits are per-origin or per-process
9. Verify resource limits apply per-origin or per-process → Browser UI remains responsive under load
10. Test that browser remains responsive under resource pressure → User can terminate runaway processes/tabs

**Pass Criteria**: Memory limits enforced AND CPU throttling active AND background throttling works AND script timeouts prevent hangs

**Fail Criteria**: No memory limits OR no CPU throttling OR background tabs not throttled OR scripts can hang indefinitely

**Evidence**: Memory allocation test results, CPU usage graphs showing throttling, background tab resource measurements, WebWorker limit tests, script timeout logs, browser responsiveness tests

**References**:

- WebAssembly Memory: https://webassembly.github.io/spec/core/syntax/modules.html#memories
- Script Execution Limits: https://html.spec.whatwg.org/multipage/webappapis.html#long-tasks
- Firefox Process Limits: https://wiki.mozilla.org/Project_Fission

### Assessment: SYS-REQ-21 (Memory isolation enforcement)

**Reference**: SYS-REQ-21 - Browser shall enforce memory isolation between processes to prevent cross-process memory access

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

**Task**: Memory isolation failures enable cross-process data theft, Spectre-class attacks to read arbitrary memory, privilege escalation through memory corruption, and exploitation of use-after-free vulnerabilities. Without ASLR, SharedArrayBuffer restrictions, and Spectre mitigations, attackers can reliably exploit memory vulnerabilities to breach process boundaries. Memory isolation with ASLR, cross-origin isolation requirements, memory zeroing, and hardware protections prevents cross-process memory attacks.

**Verification**:

1. Launch browser with multiple processes and identify their memory spaces → Each process has isolated virtual memory space
2. Use memory analysis tools to verify process memory isolation (valgrind, windbg, lldb) → Renderer processes cannot read browser process memory
3. Test that renderer processes cannot access browser process memory → SharedArrayBuffer requires explicit CORS headers
4. Verify SharedArrayBuffer requires cross-origin isolation → ASLR randomizes memory addresses per process
5. Test that different origins cannot share memory without explicit mechanisms → Spectre/Meltdown mitigations prevent side-channel leaks
6. Verify ASLR (Address Space Layout Randomization) is enabled → Memory is zeroed on deallocation
7. Test that Spectre mitigations prevent speculative execution memory leaks → No cross-process memory leaks detectable
8. Verify memory is zeroed when deallocated and reused → Hardware NX/DEP prevents code execution in data pages
9. Test that memory dumps do not leak data between processes → Process crashes don't leak memory to other processes
10. Verify hardware memory protection (NX, DEP) is enabled → Memory forensics shows proper isolation

**Pass Criteria**: Process memory isolated AND SharedArrayBuffer restricted AND ASLR enabled AND Spectre mitigations active

**Fail Criteria**: Cross-process memory access possible OR SharedArrayBuffer unrestricted OR no ASLR OR Spectre vulnerable

**Evidence**: Memory map analysis, process memory dumps, SharedArrayBuffer test results, ASLR verification, Spectre/Meltdown mitigation tests, memory leak detection reports

**References**:

- SharedArrayBuffer Security: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#security_requirements
- Spectre Mitigations: https://www.chromium.org/Home/chromium-security/ssca/
- ASLR: https://en.wikipedia.org/wiki/Address_space_layout_randomization
- Site Isolation: https://www.chromium.org/Home/chromium-security/site-isolation/

### Assessment: SYS-REQ-22 (CPU resource quotas)

**Reference**: SYS-REQ-22 - Browser shall enforce CPU resource quotas to prevent any single origin from monopolizing processor resources

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

**Task**: CPU resource monopolization by malicious scripts enables cryptojacking attacks that steal processing power for cryptocurrency mining, denial-of-service through CPU exhaustion, battery drain on mobile devices, and system slowdowns affecting user productivity. Background tabs consuming CPU enable covert mining operations. CPU quotas with background throttling, timer throttling, requestAnimationFrame suspension, and per-origin limits prevent CPU monopolization while maintaining responsiveness for foreground content.

**Verification**:

1. Create test page with intensive CPU computation (tight loop or crypto operations) → Background tabs throttled to <1% CPU typically
2. Monitor CPU usage per process using OS tools (top, Task Manager, Activity Monitor) → Foreground tabs have priority CPU access
3. Test that background tabs have reduced CPU quotas → WebWorker CPU usage tracked per origin
4. Verify WebWorker CPU usage is counted toward origin quota → Invisible elements have reduced CPU quotas
5. Test CPU throttling for invisible pages (display:none, zero opacity) → Timers throttled in background (1Hz or lower)
6. Verify timer throttling for background processes (setTimeout, setInterval) → requestAnimationFrame paused when not visible
7. Test that requestAnimationFrame is paused for background tabs → Browser task manager shows per-tab CPU usage
8. Monitor overall system CPU and verify browser doesn't exceed limits → Users can terminate high-CPU tabs easily
9. Test that users can identify and terminate high-CPU tabs → System CPU usage remains reasonable under load
10. Verify CPU priority scheduling favors foreground/visible content → CPU scheduling prioritizes user-visible content

**Pass Criteria**: Background throttling active AND timers throttled AND rAF paused AND user can terminate high-CPU tabs

**Fail Criteria**: No background throttling OR timers not throttled OR rAF active in background OR no termination controls

**Evidence**: CPU usage graphs per tab, background throttling measurements, timer frequency tests, rAF execution logs, task manager screenshots, system CPU monitoring

**References**:

- Page Lifecycle API: https://developer.chrome.com/blog/page-lifecycle-api/
- Timer Throttling: https://developer.mozilla.org/en-US/docs/Web/API/setTimeout#throttling
- requestAnimationFrame: https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame
- Firefox Process Priority: https://wiki.mozilla.org/Project_Fission#Process_prioritization

### Assessment: SYS-REQ-23 (Network bandwidth limits)

**Reference**: SYS-REQ-23 - Browser shall enforce network bandwidth limits to prevent excessive network resource consumption

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

**Task**: Uncontrolled network resource consumption enables bandwidth exhaustion attacks, connection pool depletion preventing legitimate requests, network-based denial-of-service, and excessive data usage on metered connections. Malicious origins opening unlimited connections can monopolize network resources. Per-origin connection limits, HTTP/2 stream limits, WebSocket quotas, and background deprioritization prevent network resource abuse while enabling efficient multiplexing and user control.

**Verification**:

1. Create test page that attempts high-volume network requests → Connection limits enforced per origin (6-10 connections)
2. Monitor network usage per origin using browser DevTools Network panel → HTTP/2 stream limits enforced (max concurrent streams)
3. Test connection limits per origin (typically 6-10 connections) → Background tabs have reduced network priority
4. Verify HTTP/2 and HTTP/3 multiplexing limits → WebSocket connections limited per origin
5. Test bandwidth throttling for background tabs → Large transfers pausable and cancellable
6. Verify WebSocket connection limits per origin → Connection pooling prevents excessive sockets
7. Test that large downloads can be paused or cancelled → Browser task manager shows network usage per tab
8. Monitor overall browser network usage and verify limits → Network throttling options available in DevTools
9. Test that fetch() requests respect connection pooling limits → Overall browser network reasonable under load
10. Verify users can identify and control network-heavy tabs → Users can control network-heavy operations

**Pass Criteria**: Connection limits enforced AND background deprioritization AND WebSocket limits AND user controls available

**Fail Criteria**: Unlimited connections OR no background priority OR unlimited WebSockets OR no user controls

**Evidence**: Network connection graphs, DevTools Network panel screenshots, connection limit test results, WebSocket limit verification, background priority measurements, task manager network stats

**References**:

- HTTP Connection Management: https://developer.mozilla.org/en-US/docs/Web/HTTP/Connection_management_in_HTTP_1.x
- HTTP/2 Specification: https://httpwg.org/specs/rfc7540.html
- Chrome Network Throttling: https://developer.chrome.com/docs/devtools/network/reference/#throttling
- WebSocket Limits: https://datatracker.ietf.org/doc/html/rfc6455
- Firefox Network Priority: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Priority

### Assessment: SYS-REQ-24 (Storage quota enforcement)

**Reference**: SYS-REQ-24 - Browser shall enforce storage quotas for origin-scoped storage mechanisms including IndexedDB, Cache API, and local storage