EN-304-617.md

- Android App Links Verification: https://developer.android.com/training/app-links/verify-site-associations
- iOS Universal Links Validation: https://developer.apple.com/documentation/xcode/supporting-associated-domains
- Deep Link Security: https://tools.ietf.org/html/rfc8252#section-7.11
- OWASP Mobile Deep Link Security: https://owasp.org/www-project-mobile-security-testing-guide/
- Deep Link Phishing Prevention: https://attack.mitre.org/techniques/T1660/
- URL Scheme Best Practices: https://www.rfc-editor.org/rfc/rfc8252#appendix-B

### Assessment: PRO-REQ-20 (Protocol handler CSP integration)

**Reference**: PRO-REQ-20 - Browser shall integrate protocol handlers with Content Security Policy to prevent handler-based attacks

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

**Task**: Protocol handlers can be weaponized to bypass Content Security Policy restrictions if not properly integrated with CSP directives, allowing attackers to navigate to restricted destinations, execute blocked scripts, or submit forms to prohibited targets through custom protocol invocations. Without CSP integration, handlers create a side channel that circumvents navigate-to, form-action, and script-src protections. Enforcing CSP directives on protocol handler operations ensures handlers cannot be used to violate the page's security policy.

**Verification**:

1. Create a page with a strict CSP that includes navigate-to directive
2. Register a protocol handler from this page
3. Verify that protocol handler invocation respects the navigate-to CSP directive
4. Test that CSP violations during handler registration are reported
5. Create a handler URL template that would violate CSP and verify blocking
6. Test that the script-src directive affects protocol handler registration scripts
7. Verify that form-action CSP directive applies to forms targeting custom protocols
8. Test that connect-src doesn't restrict protocol handler registration but affects handler page
9. Verify that CSP inheritance works correctly for handler pages
10. Test that CSP reports include protocol handler context when violations occur
11. navigate-to CSP directive restricts protocol handler destinations
12. CSP violations during handler operations are properly reported
13. Handler URL templates that violate CSP are rejected
14. script-src controls JavaScript that registers handlers
15. form-action applies to forms with custom protocol actions
16. connect-src applies to handler page, not registration
17. Handler pages inherit appropriate CSP from their origin
18. CSP violation reports include handler-specific context
19. Unsafe-inline and unsafe-eval restrictions apply to handlers
20. CSP nonces and hashes work with handler registration

**Pass Criteria**: navigate-to restricts handler destinations AND violations reported AND handler URLs validated against CSP AND form-action enforced

**Fail Criteria**: CSP not enforced for handlers OR violations not reported OR handler URLs bypass CSP OR form-action ignored

**Evidence**: CSP policy examples with handlers, navigate-to enforcement tests, violation reports with handler context, handler URL validation tests, form-action tests, CSP inheritance verification

**References**:

- Content Security Policy Level 3: https://www.w3.org/TR/CSP3/
- CSP navigate-to Directive: https://www.w3.org/TR/CSP3/#directive-navigate-to
- CSP form-action Directive: https://www.w3.org/TR/CSP3/#directive-form-action
- CSP Violation Reporting: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#violation_reports
- CSP Integration: https://w3c.github.io/webappsec-csp/
- Protocol Handler CSP Considerations: https://www.chromium.org/Home/chromium-security/

### Assessment: PRO-REQ-21 (Handler registration audit trail)

**Reference**: PRO-REQ-21 - Browser shall maintain a complete audit trail of protocol handler registration and modification events

**Given**: A conformant browser with PRO-2 or higher capability (enterprise mode)

**Task**: Protocol handler registration and modification events create security-critical audit trails essential for detecting handler-based attacks, insider threats, and policy violations in enterprise environments. Without comprehensive auditing, attackers can register malicious handlers, modify existing handlers, or abuse handler permissions without detection, leaving no forensic evidence for incident response. Tamper-evident audit trails with complete lifecycle tracking enable security teams to detect, investigate, and respond to handler abuse while meeting compliance requirements.

**Verification**:

1. Enable enterprise audit logging for protocol handlers
2. Register a protocol handler and verify the registration is logged
3. Check that audit log includes: timestamp, origin, scheme, handler URL, user/admin identity
4. Modify handler permissions and verify the change is audited
5. Unregister a handler and verify the removal is audited
6. Test that failed registration attempts are logged with error reasons
7. Verify that permission grants/denials for handlers are audited
8. Test that enterprise policy changes affecting handlers are logged
9. Export the audit trail and verify it's in a tamper-evident format
10. Verify that audit logs can be forwarded to enterprise SIEM systems
11. Complete audit trail for all handler lifecycle events
12. Audit entries include: timestamp, identity, action, object, before/after state, outcome
13. Failed operations logged with error details
14. Permission changes audited with user decision
15. Enterprise policy enforcement events included
16. Audit logs are tamper-evident (signed or chained hashes)
17. Logs exportable in standard formats (JSON, CEF, syslog)
18. SIEM integration supported for centralized logging
19. Audit trail completeness can be verified
20. Log retention aligns with compliance requirements

**Pass Criteria**: All handler events audited with complete metadata AND failed attempts included AND logs tamper-evident AND SIEM integration supported

**Fail Criteria**: Incomplete audit trail OR missing metadata OR logs can be tampered OR no SIEM integration

**Evidence**: Audit log exports, log completeness analysis, tamper-evidence verification, SIEM integration examples, failed operation logs, enterprise policy audit examples, retention policy documentation

**References**:

- NIST SP 800-53 Audit and Accountability: https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
- ISO 27001 Audit Trail Requirements: https://www.iso.org/standard/54534.html
- Common Event Format (CEF): https://www.microfocus.com/documentation/arcsight/arcsight-smartconnectors-8.3/cef-implementation-standard/
- Syslog Protocol RFC 5424: https://www.rfc-editor.org/rfc/rfc5424
- CIS Audit Log Management: https://www.cisecurity.org/controls/

### Assessment: PRO-REQ-22 (Protocol handler update security)

**Reference**: PRO-REQ-22 - Browser shall securely handle updates to protocol handler registrations and prevent malicious modifications

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

**Task**: Protocol handler updates create opportunities for malicious modification attacks where attackers hijack existing trusted handlers by changing their URL templates to point to attacker-controlled destinations, dangerous URL schemes, or downgraded HTTP endpoints. Cross-origin handler updates could allow one domain to subvert another's handlers, while unvalidated PWA manifest updates could silently redirect protocol traffic. Secure update mechanisms with same-origin enforcement, dangerous scheme blocking, and downgrade protection prevent handler hijacking while maintaining legitimate update functionality.

**Verification**:

1. Register a protocol handler from https://trusted.example.com
2. Attempt to update the handler URL template from the same origin
3. Verify that the update requires user confirmation or follows original permissions
4. Attempt to update the handler from a different origin (https://attacker.example.com)
5. Verify that cross-origin updates are prevented
6. Test that handler updates during active use trigger security warnings
7. Verify that automatic handler updates (e.g., PWA manifest updates) are validated
8. Test that handler URL changes are logged in audit trail
9. Attempt to update handler to point to data: or javascript: URLs and verify blocking
10. Verify that downgrade protection applies to handler updates
11. Handler updates require same-origin or user permission
12. Cross-origin handler modification is prevented
13. Active handler updates trigger user notification
14. PWA manifest handler updates follow secure update process
15. Handler URL changes are audited with before/after values
16. Updates to dangerous URL schemes (data:, javascript:) are blocked
17. HTTPS-to-HTTP downgrades in handler URLs are prevented
18. Update frequency is rate-limited to prevent abuse
19. Failed update attempts are logged
20. Users can review and approve pending handler updates

**Pass Criteria**: Same-origin update restriction enforced AND cross-origin updates prevented AND dangerous schemes blocked AND updates audited

**Fail Criteria**: Cross-origin updates allowed OR dangerous schemes accepted OR no audit trail OR downgrade attacks possible

**Evidence**: Update test results showing same-origin enforcement, cross-origin prevention tests, dangerous scheme blocking verification, audit log entries for updates, downgrade prevention tests, PWA manifest update security verification

**References**:

- WHATWG HTML Handler Updates: https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
- Web App Manifest Updates: https://www.w3.org/TR/appmanifest/#updating
- Secure Software Updates: https://www.rfc-editor.org/rfc/rfc8240
- OWASP Secure Update Guidelines: https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html
- Same-Origin Policy for Updates: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy

### Assessment: PRO-REQ-23 (Handler isolation enforcement)

**Reference**: PRO-REQ-23 - Browser shall enforce process isolation for protocol handlers to limit impact of handler compromise

**Given**: A conformant browser with PRO-2 or higher capability

**Task**: Protocol handlers execute in the browser context with potential access to sensitive user data and system resources, making them high-value targets for exploitation. Without process isolation, a compromised handler could access data from other origins, bypass sandbox restrictions, read cross-process memory through Spectre-type attacks, or crash the entire browser. Handler isolation through Site Isolation architecture with sandboxing, IPC validation, and Spectre mitigations contains the impact of handler compromise and prevents privilege escalation attacks.

**Verification**:

1. Register and invoke a protocol handler
2. Use browser internals (chrome://process-internals or equivalent) to verify handler process isolation
3. Verify that handler pages run in separate renderer processes from the triggering page
4. Test that compromised handler cannot access other origin's data
5. Verify that Site Isolation applies to protocol handler pages
6. Test that handler processes have appropriate sandbox restrictions
7. Verify that IPC between handler and browser process is validated
8. Test that handler crash doesn't affect other tabs or browser stability
9. Verify that handler processes don't have elevated privileges
10. Test that memory isolation prevents handler from reading other process memory
11. Protocol handlers run in isolated renderer processes
12. Handler isolation follows Site Isolation architecture
13. Cross-origin data is not accessible from handler process
14. Handler processes are sandboxed with restricted capabilities
15. IPC messages from handlers are validated and sanitized
16. Handler crashes are isolated and don't affect browser stability
17. No elevated privileges granted to handler processes
18. Memory isolation prevents cross-process memory access
19. Spectre/Meltdown mitigations apply to handler processes
20. Process limit enforced to prevent resource exhaustion

**Pass Criteria**: Handler process isolation enforced AND Site Isolation applied AND sandboxing active AND IPC validated AND crashes isolated

**Fail Criteria**: Handlers in same process as other content OR no sandboxing OR IPC not validated OR crashes affect browser OR cross-process memory access possible

**Evidence**: Process isolation verification using browser internals, Site Isolation tests, sandbox capability analysis, IPC validation tests, crash isolation tests, memory isolation verification, Spectre mitigation confirmation

**References**:

- Chromium Site Isolation: https://www.chromium.org/Home/chromium-security/site-isolation/
- Browser Process Architecture: https://www.chromium.org/developers/design-documents/multi-process-architecture/
- Sandbox Architecture: https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md
- IPC Security: https://www.chromium.org/developers/design-documents/inter-process-communication/
- Spectre Mitigations: https://www.chromium.org/Home/chromium-security/ssca/
- Process Isolation Best Practices: https://www.w3.org/TR/security-privacy-questionnaire/#isolation

## 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 (chrome://sandbox, about:support, 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 chrome://gpu or about:support 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 (chrome://process-internals)
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 (chrome://settings/content, about:preferences#privacy)
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