EN-304-617.md.backup

   - 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)

**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
2. Verify protected USB classes are filtered (HID keyboards/mice, mass storage, video, audio)
3. Test USB device access requires user activation (transient user gesture)
4. Verify vendors can opt out devices via USB device descriptor
5. Test that WebUSB requires secure context (HTTPS or localhost)
6. Attempt interface claiming on protected interface classes and verify blocking
7. Test USB device connection events fire only for authorized devices
8. Verify control transfers are validated and potentially dangerous ones blocked
9. Test that permissions-policy can restrict WebUSB in iframes
10. Verify USB device access is auditable through DevTools protocol
11. Protected USB device classes are never shown in picker
12. Only secure contexts can access WebUSB API
13. User activation required for device requests
14. Previously authorized devices require getDevices() call
15. Protected interface classes cannot be claimed
16. Device connection events only for authorized devices
17. Control transfers are validated for safety
18. Permissions Policy successfully restricts WebUSB
19. DevTools shows USB activity for debugging
20. 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
2. Verify GATT blocklist prevents access to dangerous services (HID, firmware update)
3. Test that Web Bluetooth requires secure context (HTTPS or localhost)
4. Verify user activation required for requestDevice() calls
5. Test service UUID filters work correctly in device selection
6. Attempt to access blocklisted GATT characteristics and verify blocking
7. Test that optional services still require user awareness
8. Verify device name filtering prevents fingerprinting
9. Test permissions-policy restricts Web Bluetooth in cross-origin iframes
10. Verify Bluetooth scanning requires explicit user permission
11. Secure context (HTTPS/localhost) required for all Web Bluetooth APIs
12. User activation required for device requests
13. GATT blocklist prevents access to dangerous services/characteristics
14. Service UUID filtering correctly limits accessible services
15. Blocklisted characteristics return errors when accessed
16. Optional services declared in requestDevice()
17. Device names sanitized to prevent fingerprinting
18. Permissions Policy successfully restricts Web Bluetooth
19. Bluetooth scanning requires separate permission
20. 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
2. Verify Web NFC requires secure context (HTTPS or localhost)
3. Test that NFC access requires user gesture for permission prompt
4. Grant NFC permission and verify scan operations work
5. Test NDEFReader.write() and verify it respects same permission
6. Verify cross-origin iframe NFC access is blocked without permission policy
7. Test permission revocation immediately stops NFC scanning
8. Verify NFC operations blocked when page in background
9. Test that dangerous NFC tag types are filtered or sandboxed
10. Verify NFC access is per-origin and isolated
11. Secure context (HTTPS/localhost) required for Web NFC
12. Permission prompt appears before NFC access granted
13. User gesture required to trigger permission prompt
14. Both scan and write operations respect same permission
15. Cross-origin iframe access blocked without delegation
16. Permission revocation stops active scans
17. Background pages cannot perform NFC operations
18. Dangerous tag operations are restricted
19. Permissions are per-origin and isolated
20. 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
2. Verify secure context required for sensor APIs
3. Test Gyroscope access and verify same permission model
4. Create Magnetometer sensor and verify permissions
5. Test that high-frequency sensor access may require additional permissions
6. Verify sensors stop when page moves to background
7. Test cross-origin iframe sensor access requires permission policy delegation
8. Verify sensor permissions are per-origin
9. Test that ambient light sensor respects privacy considerations
10. Verify sensor access can be blocked via Permissions Policy
11. Secure context required for all Sensor APIs
12. Permission prompts or policies apply before sensor access
13. High-frequency access may require explicit permission
14. Sensors automatically pause in background
15. Cross-origin access requires Permissions Policy delegation
16. Permissions are per-origin and isolated
17. Privacy-sensitive sensors have additional restrictions
18. Permissions Policy can block sensor access
19. Sensor frequency is limited to prevent fingerprinting
20. 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
2. Verify battery level is rounded to prevent high-precision fingerprinting
3. Test battery timing information is quantized to prevent tracking
4. Verify battery status updates are throttled
5. Test that battery information is not available in insecure contexts
6. Verify battery status in cross-origin iframes requires permission policy
7. Test that frequent battery queries are rate-limited
8. Verify battery API can be disabled via browser settings or policy
9. Test that battery charging state changes are debounced
10. Verify no access to detailed battery analytics or history
11. Battery level rounded to coarse granularity (e.g., 1% or 5%)
12. Timing information quantized to prevent precise measurements
13. Update frequency throttled to prevent tracking
14. Secure context recommended for battery API access
15. Cross-origin access requires Permissions Policy
16. Rate limiting prevents rapid polling
17. Battery API can be disabled by user/policy
18. Charging state changes debounced
19. No historical battery data exposed
20. 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
2. Test CPU-intensive operations and verify throttling or limits applied
3. Monitor browser resource usage with intensive JavaScript loops
4. Test WebWorker resource limits and verify isolation
5. Verify background tab resource throttling is active
6. Test WebAssembly memory limits and verify enforcement
7. Monitor GPU memory usage and verify limits on WebGL contexts
8. Test that runaway scripts trigger timeout warnings or termination
9. Verify resource limits apply per-origin or per-process
10. Test that browser remains responsive under resource pressure
11. Memory allocation limits prevent excessive consumption
12. CPU-intensive operations are throttled
13. Background tabs have reduced resource quotas
14. WebWorkers have separate resource limits
15. WebAssembly memory is bounded and enforced
16. GPU memory limits prevent resource exhaustion
17. Script timeouts prevent infinite loops
18. Resource limits are per-origin or per-process
19. Browser UI remains responsive under load
20. 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