EN-304-617.md

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

**Task**: Unrestricted storage enables disk space exhaustion attacks, storage-based denial-of-service, tracking through persistent data storage, and system instability from full disks. Malicious origins filling storage prevent legitimate applications from functioning. Per-origin storage quotas, persistent storage permissions, QuotaExceededError enforcement, and separate incognito limits prevent storage abuse while enabling adequate space for web applications and maintaining system stability.

**Verification**:

1. Test StorageManager.estimate() to query available storage quota → Storage quotas enforced per-origin (typically 50-100MB default)
2. Attempt to exceed storage quota using IndexedDB and verify QuotaExceededError → StorageManager API accurately reports usage and quota
3. Test localStorage quota limits (typically 5-10MB) → QuotaExceededError thrown when limits reached
4. Verify Cache API respects storage quota → localStorage limited to 5-10MB per origin
5. Test that storage quota is per-origin and isolated → Cache API storage counted toward quota
6. Verify persistent storage requires explicit user permission → Persistent storage requires user permission
7. Test that storage usage is accurately reported in browser settings → Browser settings show per-origin storage usage
8. Verify storage can be cleared per-origin by user → Users can clear storage per-origin
9. Test that incognito/private mode has separate, limited storage → Incognito mode has separate, limited quota
10. Verify storage quota warnings or prompts for large allocations → Large storage requests trigger user prompts

**Pass Criteria**: Quotas enforced per-origin AND QuotaExceededError thrown AND persistent storage requires permission AND user controls available

**Fail Criteria**: No quota enforcement OR errors not thrown OR persistent storage auto-granted OR no user controls

**Evidence**: StorageManager.estimate() results, QuotaExceededError screenshots, localStorage limit tests, Cache API quota tests, browser settings storage UI, incognito mode quota verification

**References**:

- Storage API: https://storage.spec.whatwg.org/
- StorageManager: https://developer.mozilla.org/en-US/docs/Web/API/StorageManager
- IndexedDB Quota: https://www.w3.org/TR/IndexedDB/#dom-idbdatabase-transaction
- Chrome Storage Quotas: https://web.dev/articles/storage-for-the-web
- Firefox Storage Limits: https://developer.mozilla.org/en-US/docs/Web/API/Storage_API/Storage_quotas_and_eviction_criteria

### Assessment: SYS-REQ-25 (Process priority management)

**Reference**: SYS-REQ-25 - Browser shall implement process priority management to ensure responsive user experience and fair resource allocation

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

**Task**: Without process priority management, background tabs can monopolize CPU resources causing foreground tab lag, audio playback in background can be interrupted unfairly, and browser responsiveness suffers from equal treatment of all processes. Priority inversion where background processes starve foreground operations degrades user experience. Dynamic process priority management ensuring foreground preference, audio continuity, and fair scheduling prevents resource contention while maintaining responsive user interaction.

**Verification**:

1. Launch browser with multiple tabs and identify process priorities using OS tools → Foreground tabs run at higher OS process priority
2. Verify foreground tab processes have higher priority than background → Background tabs run at reduced priority (low or below normal)
3. Test that audio-playing tabs maintain elevated priority → Audio-playing tabs maintain adequate priority
4. Verify visible tabs have higher priority than hidden tabs → Priority changes dynamically when switching tabs
5. Test process priority changes when switching tabs → CPU scheduler gives preference to high-priority processes
6. Monitor CPU scheduling and verify foreground processes get preference → Extension processes have appropriate priority
7. Test that extension processes have appropriate priority → Utility processes prioritized by criticality
8. Verify utility processes (network, GPU) have appropriate priority → Frozen tabs have lowest priority
9. Test that frozen background tabs have lowest priority → No process starvation occurs
10. Verify process priorities don't allow starvation → User-facing processes most responsive

**Pass Criteria**: Foreground tabs high priority AND background tabs low priority AND dynamic priority adjustment AND no starvation

**Fail Criteria**: All same priority OR no background reduction OR static priorities OR starvation occurs

**Evidence**: Process priority listings (nice values, Windows priority classes), CPU scheduling analysis, tab switching priority changes, audio playback priority verification, process responsiveness measurements

**References**:

- Chrome Process Model: https://www.chromium.org/developers/design-documents/multi-process-architecture/
- Linux Process Priority: https://man7.org/linux/man-pages/man2/nice.2.html
- Windows Process Priority: https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities
- Page Lifecycle: https://developer.chrome.com/blog/page-lifecycle-api/

### Assessment: SYS-REQ-26 (Sandbox escape prevention)

**Reference**: SYS-REQ-26 - Browser shall implement multiple layers of defense to prevent sandbox escape attacks

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

**Task**: Sandbox escapes are high-severity vulnerabilities that allow compromised renderers to break containment and gain full system access, enabling malware installation, data exfiltration, and system compromise. Single-layer sandboxes are vulnerable to bypass through exploitation of implementation bugs or kernel vulnerabilities. Defense-in-depth with multiple sandbox layers, syscall filtering, IPC validation, kernel exploit mitigations, and continuous fuzzing prevents sandbox escapes even when individual defenses are bypassed.

**Verification**:

1. Review browser's sandbox architecture documentation and layers of defense → Multiple sandbox layers (syscall filter, namespace isolation, capability dropping)
2. Test syscall filtering using strace/dtruss to verify blocked calls → Dangerous syscalls blocked (execve, ptrace, mount, etc.)
3. Attempt known sandbox escape techniques and verify they're mitigated → IPC messages validated in broker process
4. Verify IPC validation prevents malformed messages from escaping sandbox → Process debugging APIs blocked
5. Test that renderer processes cannot ptrace or debug other processes → Memory corruption contained within sandbox
6. Verify memory corruption in renderer doesn't allow privilege escalation → GPU sandbox independent from renderer
7. Test that GPU process sandbox is separate from renderer sandbox → Kernel exploit mitigations active (SMEP, SMAP, KPTI)
8. Verify kernel exploit mitigations (SMEP, SMAP, KPTI) are active → Regular fuzzing for sandbox bypasses
9. Test fuzzing results for sandbox bypass vulnerabilities → Security updates address known escapes
10. Verify security updates address discovered sandbox escapes → Defense-in-depth architecture

**Pass Criteria**: Multiple sandbox layers AND syscall filtering AND IPC validation AND kernel mitigations active

**Fail Criteria**: Single layer only OR syscalls not filtered OR IPC not validated OR kernel mitigations missing

**Evidence**: Sandbox architecture documentation, syscall trace logs, sandbox escape test results, IPC validation logs, kernel mitigation verification, fuzzing reports, security update changelogs

**References**:

- Chromium Sandbox: https://chromium.googlesource.com/chromium/src/+/master/docs/design/sandbox.md
- Linux Namespace Isolation: https://man7.org/linux/man-pages/man7/namespaces.7.html
- Seccomp BPF: https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html
- SMEP and SMAP: https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance.html
- Project Zero Sandbox Escapes: https://googleprojectzero.blogspot.com/

### Assessment: SYS-REQ-27 (Speculative execution mitigations)

**Reference**: SYS-REQ-27 - Browser shall implement mitigations for speculative execution vulnerabilities including Spectre and Meltdown

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

**Task**: Spectre and Meltdown enable attackers to exploit speculative execution in modern CPUs to read arbitrary memory across security boundaries, including passwords, encryption keys, and cross-origin data. Without mitigations, malicious JavaScript can use timing side channels to leak sensitive data from other processes or origins. Site Isolation, timer quantization, SharedArrayBuffer restrictions, CORB, and COOP/COEP headers prevent speculative execution attacks by ensuring cross-origin data never shares address space.

**Verification**:

1. Verify Site Isolation is enabled using chrome://process-internals or equivalent → Site Isolation active for all sites or at least sensitive origins
2. Test that high-resolution timers are reduced precision (performance.now() granularity) → Timer precision reduced to 100 microseconds or coarser
3. Verify SharedArrayBuffer requires cross-origin isolation headers → SharedArrayBuffer requires COOP+COEP headers
4. Test that cross-origin data is not accessible in same process → Cross-origin data in separate processes
5. Verify CORB (Cross-Origin Read Blocking) prevents sensitive data leaks → CORB blocks cross-origin reads of sensitive MIME types
6. Test that speculative execution cannot leak cross-origin data → Spectre PoC exploits fail to leak data
7. Verify process-per-site-instance isolation for sensitive origins → Process-per-site-instance for banks, login pages
8. Test that COOP/COEP headers enable process isolation → COOP/COEP enable strict process isolation
9. Verify kernel page-table isolation (KPTI) is active on system → KPTI active on vulnerable systems
10. Test that Spectre PoC exploits are mitigated → Regular updates address new speculative execution vulnerabilities

**Pass Criteria**: Site Isolation enabled AND timer precision reduced AND SharedArrayBuffer restricted AND CORB active

**Fail Criteria**: No Site Isolation OR high-precision timers OR SharedArrayBuffer unrestricted OR CORB disabled

**Evidence**: Site Isolation status screenshots, timer precision measurements, SharedArrayBuffer tests with/without headers, CORB blocking logs, Spectre PoC test results, KPTI verification

**References**:

- Spectre Mitigations: https://www.chromium.org/Home/chromium-security/ssca/
- Site Isolation: https://www.chromium.org/Home/chromium-security/site-isolation/
- SharedArrayBuffer: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#security_requirements
- CORB: https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md
- Spectre Attack: https://spectreattack.com/

### Assessment: SYS-REQ-28 (Side-channel attack mitigations)

**Reference**: SYS-REQ-28 - Browser shall implement mitigations for side-channel attacks including timing attacks, cache attacks, and fingerprinting

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

**Task**: Side-channel attacks exploit timing differences, cache behavior, rendering performance, and other observable effects to infer sensitive information like user history, cross-origin data, or cryptographic keys. High-precision timers enable microarchitectural attacks, CSS :visited timing leaks browsing history, and cache timing reveals cross-origin content. Timer quantization, process isolation for cache partitioning, cross-origin timing sanitization, and fingerprinting surface minimization prevent side-channel information leakage.

**Verification**:

1. Test timer precision reduction (performance.now(), Date.now()) to verify quantization → Timer precision reduced (100 microseconds or coarser)
2. Verify SharedArrayBuffer is disabled or requires isolation headers → SharedArrayBuffer requires COOP+COEP isolation
3. Test that cache timing attacks are mitigated through process isolation → Process isolation prevents cache-based side channels
4. Verify rendering timing cannot leak cross-origin information → Rendering timing doesn't leak cross-origin data
5. Test that event loop timing is not exploitable for side channels → Event loop timing not exploitable
6. Verify CSS timing attacks are mitigated (e.g., :visited link timing) → :visited link styling restricted to prevent timing attacks
7. Test that network timing doesn't leak cross-origin data → Network timing (Resource Timing API) sanitized for cross-origin
8. Verify SVG filter timing attacks are prevented → SVG filter timing attacks mitigated
9. Test that WebGL cannot be used for timing side channels → WebGL timing attacks prevented through various restrictions
10. Verify fingerprinting surfaces are minimized or permissions-gated → Fingerprinting APIs require permission or are restricted

**Pass Criteria**: Timer quantization active AND SharedArrayBuffer isolated AND process isolation prevents cache attacks AND cross-origin timing sanitized

**Fail Criteria**: High-precision timers OR SharedArrayBuffer unrestricted OR no cache isolation OR timing leaks exist

**Evidence**: Timer precision tests, SharedArrayBuffer isolation verification, cache timing attack tests, cross-origin timing measurements, fingerprinting surface analysis, side-channel PoC test results

**References**:

- Web Platform Security: https://www.w3.org/TR/fingerprinting-guidance/
- Timing Attacks: https://www.w3.org/TR/hr-time-2/#clock-resolution
- CSS :visited Privacy: https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector
- Resource Timing: https://www.w3.org/TR/resource-timing-2/
- Fingerprinting Resistance: https://brave.com/privacy-updates/3-fingerprint-randomization/

### Assessment: SYS-REQ-29 (Hardware token security)

**Reference**: SYS-REQ-29 - Browser shall implement secure access controls for hardware security tokens and authenticators (WebAuthn)

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

**Task**: Hardware security tokens provide strong authentication but require secure browser integration to prevent phishing, credential theft, and authenticator cloning attacks. Without HTTPS requirements and origin binding, attackers could steal credentials or use fake authenticators. User verification and presence requirements prevent remote attacks. HTTPS enforcement, origin-bound credentials, attestation validation, user presence requirements, and extension isolation ensure WebAuthn security while enabling passwordless authentication.

**Verification**:

1. Test WebAuthn registration with hardware security key (e.g., YubiKey) → WebAuthn requires secure context (HTTPS or localhost)
2. Verify registration requires HTTPS context (except localhost) → User verification enforced when requested by relying party
3. Test that user verification (PIN/biometric) is enforced when required → Attestation validation prevents cloned/fake authenticators
4. Verify authenticator attestation is validated correctly → Credentials strictly origin-bound (site isolation)
5. Test that credentials are origin-bound and not accessible cross-origin → User presence required (physical interaction)
6. Verify user presence is required (physical touch/button press) → CTAP2 protocol correctly implemented
7. Test that CTAP2 protocol is properly implemented for FIDO2 devices → Extensions cannot intercept or modify WebAuthn
8. Verify browser extensions cannot intercept WebAuthn operations → Users choose authenticator from picker
9. Test that authenticator selection respects user choice → Platform authenticators use OS-level secure enclaves
10. Verify platform authenticators (Touch ID, Windows Hello) are isolated → Private keys never accessible to JavaScript

**Pass Criteria**: HTTPS required AND user verification enforced AND origin-bound credentials AND user presence required

**Fail Criteria**: HTTP allowed OR no user verification OR cross-origin access OR no user presence

**Evidence**: WebAuthn registration screenshots, attestation validation logs, cross-origin test results, user presence verification, CTAP2 protocol traces, platform authenticator tests

**References**:

- WebAuthn Specification: https://www.w3.org/TR/webauthn-2/
- FIDO2 CTAP: https://fidoalliance.org/specs/fido-v2.0-ps-20190130/fido-client-to-authenticator-protocol-v2.0-ps-20190130.html
- WebAuthn Security: https://www.w3.org/TR/webauthn-2/#sctn-security-considerations
- FIDO Security Reference: https://fidoalliance.org/specifications/

### Assessment: SYS-REQ-30 (Accessibility API security)

**Reference**: SYS-REQ-30 - Browser shall implement security controls for accessibility APIs to prevent information leakage and unauthorized access

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

**Task**: Accessibility APIs expose detailed page structure, content, and user interactions to assistive technologies, creating vectors for information leakage, fingerprinting, unauthorized content scraping, and privacy violations if not properly controlled. Malicious software masquerading as assistive technology could harvest passwords, track user actions, or extract sensitive content. OS-level permission requirements, sensitive data masking, cross-origin restrictions, and remote access authentication prevent accessibility API abuse while serving users with disabilities.

**Verification**:

1. Enable OS accessibility features (screen reader, voice control) → Accessibility API access requires OS-level permission
2. Verify browser exposes accessibility tree to authorized assistive technology only → Only authorized assistive technology can access accessibility tree
3. Test that accessibility API requires user opt-in or OS-level permission → Sensitive content (passwords) properly masked in accessibility tree
4. Verify accessibility tree doesn't leak sensitive data (passwords, hidden content) → Cross-origin content has limited accessibility exposure
5. Test that cross-origin content has restricted accessibility exposure → Accessibility events sanitized to prevent leakage
6. Verify accessibility events don't leak timing or user interaction information → Remote accessibility requires authentication
7. Test that remote accessibility access (enterprise tools) requires authentication → Accessibility API cannot be used for fingerprinting
8. Verify accessibility API cannot be abused for fingerprinting → ARIA attributes don't leak sensitive information
9. Test that ARIA attributes don't leak security-sensitive information → Accessibility access auditable
10. Verify screen reader access is logged for security auditing → Browser communicates securely with assistive technology

**Pass Criteria**: OS permission required AND sensitive data masked AND cross-origin limited AND remote access authenticated

**Fail Criteria**: No permission required OR passwords exposed OR cross-origin fully accessible OR remote access unauthenticated

**Evidence**: Accessibility permission flows, accessibility tree dumps showing masking, cross-origin accessibility tests, remote access authentication verification, fingerprinting tests, audit logs

**References**:

- WAI-ARIA: https://www.w3.org/TR/wai-aria-1.2/
- Accessibility Object Model: https://wicg.github.io/aom/spec/
- Chrome Accessibility: https://www.chromium.org/developers/design-documents/accessibility/
- macOS Accessibility: https://developer.apple.com/documentation/accessibility
- Windows Accessibility: https://docs.microsoft.com/en-us/windows/win32/winauto/entry-uiauto-win32

### Assessment: SYS-REQ-31 (Native messaging restrictions)

**Reference**: SYS-REQ-31 - Browser shall enforce security restrictions on native messaging between extensions and native applications

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

**Task**: Native messaging bridges the browser extension sandbox and native applications, creating risks of sandbox escape, privilege escalation, arbitrary code execution, and malware installation if not properly controlled. Malicious extensions could exploit native messaging to execute system commands, access sensitive files, or install malware. Manifest permissions, host registration, extension ID validation, message validation, and privilege limitation prevent native messaging abuse while enabling legitimate browser-native integration.

**Verification**:

1. Create test extension with nativeMessaging permission → nativeMessaging permission required in manifest
2. Verify extension requires explicit permission declaration in manifest → Native host is registered in browser's native messaging directory
3. Test that native messaging host is registered with browser → Only permitted extensions (by ID) can connect to host
4. Verify only explicitly allowed extensions can communicate with native host → User should manually install native host application
5. Test that native messaging requires user installation of native component → Messages validated by browser before passing to/from host
6. Verify message validation occurs on browser side → Native host runs with limited OS privileges
7. Test that native host process runs with limited privileges → Extension sandbox not bypassed via native messaging
8. Verify native messaging cannot bypass extension sandbox → Extension uninstall terminates native connections
9. Test that uninstalling extension terminates native messaging connections → Enterprise policies can control native messaging
10. Verify enterprise policies can restrict or acceptlist native messaging → Native host path validation prevents arbitrary execution

**Pass Criteria**: Manifest permission required AND host registration required AND extension ID validation AND user installs host

**Fail Criteria**: No permission required OR no host registration OR any extension can connect OR automatic host installation

**Evidence**: Extension manifest examples, native host registration files, permission validation tests, message validation logs, privilege analysis of native host, enterprise policy tests

**References**:

- Chrome Native Messaging: https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging
- Firefox Native Messaging: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging

### Assessment: SYS-REQ-32 (Host OS integration security)

**Reference**: SYS-REQ-32 - Browser shall securely integrate with host operating system features while maintaining sandbox boundaries and security isolation

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

**Task**: Host OS integration provides essential functionality but creates attack surfaces for credential theft, certificate validation bypass, policy evasion, and privilege escalation if not properly secured. Insecure credential access exposes passwords, certificate store bypass enables MITM attacks, and policy violations undermine enterprise security. Secure IPC for credentials, OS certificate store usage, file association validation, policy compliance, and update signature verification maintain security boundaries while enabling OS integration.

**Verification**:

1. Test OS credential integration (Windows Credential Manager, macOS Keychain) and verify secure access → OS credential storage accessed securely (encrypted IPC)
2. Verify browser uses OS certificate store with proper validation → OS certificate store used with proper validation
3. Test OS notification integration respects permission model → OS notifications require permission and are per-origin
4. Verify file type association handlers are validated and sandboxed → File associations validated before handler invocation
5. Test protocol handler registration requires user confirmation → Protocol handlers require user confirmation
6. Verify OS-level print dialog prevents renderer access to print system → Print system accessed via broker, not renderer
7. Test that OS share APIs require user gesture and confirmation → OS share APIs require user gesture
8. Verify browser respects OS security policies (AppLocker, Gatekeeper, SELinux) → Browser respects OS security policies
9. Test that browser updates use OS-level signature verification → Updates verified with OS-level signatures
10. Verify browser profile directories use OS access controls → Profile directories protected with OS ACLs

**Pass Criteria**: Secure credential access AND certificate store used AND handlers validated AND security policies respected

**Fail Criteria**: Insecure credential access OR certificate store bypassed OR handlers not validated OR policies ignored

**Evidence**: Credential access flow analysis, certificate store usage verification, file association tests, protocol handler registration flows, OS policy compliance tests, update signature verification, ACL analysis

**References**:

- Windows Credential Manager: https://docs.microsoft.com/en-us/windows/security/identity-protection/credential-guard/
- macOS Keychain: https://developer.apple.com/documentation/security/keychain_services
- Code Signing: https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution
- Windows AppLocker: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/applocker/applocker-overview
- SELinux: https://www.redhat.com/en/topics/linux/what-is-selinux

### Assessment: SYS-REQ-33 (Block all device API access at SYS-0)

**Reference**: SYS-REQ-33 - Browser shall block all device API access (no camera, microphone, location, etc.) at SYS-0 capability level

**Given**: A conformant browser with SYS-0 capability (fully sandboxed, no system access)

**Task**: At SYS-0 capability, browsers shall completely deny access to all device hardware APIs to minimize attack surface and prevent fingerprinting, location tracking, surveillance, and privacy violations. Allowing camera, microphone, geolocation, or sensor APIs at this level contradicts the security posture of zero system access, enabling malicious sites to track users, capture audio/video without consent, or perform sophisticated fingerprinting attacks. Complete device API blocking with permission UI disabled, API surface removed, and feature policy enforcement ensures zero hardware access.

**Verification**:

1. Navigate to test pages that request camera access using browser media APIs and verify requests are blocked → All camera access requests fail without user prompting
2. Test microphone access requests and confirm they fail immediately without permission prompts → All microphone requests fail immediately
3. Attempt to access geolocation API and verify it returns an error without prompting → Geolocation API returns error without permission dialogs
4. Test device motion and orientation sensor APIs and confirm they are blocked → Motion and orientation sensors blocked
5. Attempt to access ambient light sensor API and verify it is unavailable → Ambient light sensor unavailable
6. Test battery status API access and confirm it is blocked → Battery status API blocked
7. Verify proximity sensor API is not available at SYS-0 level → Proximity sensor not exposed
8. Test vibration API and confirm it is blocked or returns immediately without effect → Vibration API disabled or no-op
9. Attempt to access NFC, Bluetooth, and USB APIs and verify they are completely unavailable → NFC, Bluetooth, USB APIs completely unavailable
10. Verify that permission UI for all device APIs is disabled and not rendered → No permission UI rendered for any device API

**Pass Criteria**: All device hardware APIs blocked AND no permission prompts shown AND API surface not exposed AND feature policy enforced

**Fail Criteria**: Any device API accessible OR permission prompts shown OR APIs available in JavaScript scope

**Evidence**: API access test results showing blocked requests, JavaScript console showing undefined API objects, network logs showing no device enumeration, permission UI absence verification, feature policy analysis

**References**:

- Media Capture and Streams API: https://www.w3.org/TR/mediacapture-streams/
- Geolocation API: https://www.w3.org/TR/geolocation-API/
- Generic Sensor API: https://www.w3.org/TR/generic-sensor/
- Web Bluetooth: https://webbluetoothcg.github.io/web-bluetooth/
- WebUSB: https://wicg.github.io/webusb/

### Assessment: SYS-REQ-34 (Block native messaging interfaces at SYS-0)

**Reference**: SYS-REQ-34 - Browser shall not expose any native messaging interfaces at SYS-0 capability level

**Given**: A conformant browser with SYS-0 capability (fully sandboxed, no system access)

**Task**: Native messaging interfaces allow extensions and web content to communicate with native applications on the host system, creating privileged channels for file access, process execution, and system command invocation. At SYS-0, these interfaces shall be completely disabled to prevent sandbox escape, unauthorized native code execution, and host system compromise. Exposing native messaging contradicts zero system access policy, enabling malicious code to bypass browser security boundaries. Complete removal of native messaging APIs, configuration interfaces, and manifest support prevents these attack vectors.

**Verification**:

1. Search browser extension API documentation to verify native messaging APIs are not documented for SYS-0 → Native messaging APIs undefined in extension context
2. Attempt to load an extension with native messaging permissions and verify it is rejected → Extensions with native messaging permissions rejected at install
3. Test extension manifest with "nativeMessaging" permission and confirm browser refuses to load it → Manifests declaring nativeMessaging fail validation
4. Attempt to call native messaging APIs from extension context and verify they are undefined → Native messaging host directories not accessed
5. Search for native messaging host configuration directories and verify they are not created or accessed → No permission UI for native messaging shown
6. Test that extension installation UI does not show native messaging permission requests → Browser does not spawn native host processes
7. Verify browser process does not spawn or communicate with native messaging hosts → API documentation excludes native messaging at SYS-0
8. Review browser API surface and confirm native messaging functions are not exposed → Configuration UI lacks native messaging options
9. Test that browser configuration UI does not offer native messaging settings → Security logs show zero native messaging attempts
10. Verify browser security logs do not show any native messaging connection attempts → Feature completely absent from browser capabilities

**Pass Criteria**: Native messaging APIs undefined AND extensions with native messaging rejected AND no host processes spawned AND configuration disabled

**Fail Criteria**: Native messaging APIs accessible OR extensions with permission load OR native hosts spawned OR configuration options available

**Evidence**: Extension manifest rejection logs, API availability tests showing undefined objects, process monitoring showing no native messaging hosts, configuration UI screenshots, security log analysis

**References**:

- Chrome Native Messaging: https://developer.chrome.com/docs/apps/nativeMessaging/
- Mozilla Native Messaging: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Native_messaging
- Browser Extension Security: https://www.w3.org/community/webextensions/

### Assessment: SYS-REQ-35 (Block host OS integration at SYS-0)

**Reference**: SYS-REQ-35 - Browser shall block all host OS integration features at SYS-0 capability level

**Given**: A conformant browser with SYS-0 capability (fully sandboxed, no system access)

**Task**: Host OS integration features including file associations, protocol handlers, OS notifications, credential storage access, certificate store integration, and system dialog invocation create pathways between sandboxed browser content and privileged OS functionality. At SYS-0, all integration shall be blocked to maintain complete isolation, preventing protocol handler hijacking, file association exploits, notification spam, credential theft, and OS-level privilege escalation. Disabling OS integration prevents malicious content from escaping browser boundaries to manipulate host system configuration or access sensitive OS services.

**Verification**:

1. Attempt to register custom protocol handlers and verify registration is blocked → Protocol handler registration fails
2. Test file type association requests and confirm they are rejected → File association requests rejected
3. Attempt to trigger OS notification API and verify it fails without permission prompts → OS notifications blocked without prompts
4. Test access to OS credential storage (keychain, credential manager) and confirm it is blocked → Credential storage not accessible
5. Verify browser does not access or validate certificates using OS certificate store → OS certificate store not used
6. Attempt to invoke OS print dialog and confirm it is unavailable or non-functional → Print dialog unavailable
7. Test OS share/send APIs and verify they are completely disabled → Share APIs disabled
8. Attempt to register as default browser and confirm the feature is unavailable → Default browser registration blocked
9. Test system dialog invocation (file picker, color picker) and verify dialogs do not appear → System dialogs do not invoke
10. Verify browser respects OS security policies but does not integrate with OS security features → No OS security feature integration

**Pass Criteria**: All protocol handlers blocked AND file associations rejected AND OS notifications disabled AND credential storage inaccessible AND system dialogs blocked

**Fail Criteria**: Protocol handlers register OR file associations created OR notifications work OR credential storage accessible OR system dialogs appear

**Evidence**: Protocol registration test results, file association rejection logs, notification API failure messages, credential storage access attempts showing errors, certificate validation method analysis, dialog invocation tests

**References**:

- Custom Protocol Handlers: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
- Web App Manifest: https://www.w3.org/TR/appmanifest/
- Notifications API: https://notifications.spec.whatwg.org/
- Credential Management API: https://www.w3.org/TR/credential-management-1/

### Assessment: SYS-REQ-36 (PWA permission scope restrictions)

**Reference**: SYS-REQ-36 - PWA permissions shall not exceed web context permissions at SYS-2 capability level

**Given**: A conformant browser with SYS-2 capability supporting Progressive Web Applications

**Task**: Progressive Web Applications installed from browsers should not gain additional permissions beyond what the same web content has in browser context, preventing PWA installation from becoming a privilege escalation vector. If PWAs automatically gain filesystem access, native API access, or reduced permission prompting not available to web contexts, malicious actors can exploit PWA installation as a persistence mechanism with elevated privileges. Enforcing permission parity ensures PWAs remain scoped to the same security model as their web origins, with identical permission requirements, prompting, and revocation.

**Verification**:

1. Open a web application in browser tab and document available API permissions → PWA and web contexts have identical API availability
2. Install the same application as PWA and enumerate available APIs in installed context → Camera permissions identical across contexts
3. Compare permission scopes between browser tab context and PWA context for camera API → Microphone prompts same for PWA and web
4. Test microphone access in both contexts and verify identical permission prompting behavior → Geolocation requires same consent
5. Verify geolocation API requires same user consent in PWA as in browser tab → Filesystem access equally restricted
6. Test filesystem access in browser tab and PWA, confirming equal restrictions → USB permissions identical
7. Attempt to access USB devices in both contexts and verify same permission model applies → Bluetooth requires same user consent
8. Test Bluetooth API access and confirm PWAs don't bypass permission requirements → Notification permissions consistent
9. Verify notification permissions require same user consent regardless of install state → PWA installation grants no automatic permissions
10. Test that PWA installation does not auto-grant any permissions that web context requires explicit consent for → Permission UI and flows identical

**Pass Criteria**: PWA permissions identical to web context AND no automatic permission grants on installation AND same permission prompting behavior

**Fail Criteria**: PWA has more permissions than web context OR installation auto-grants permissions OR PWA bypasses permission prompts

**Evidence**: Permission enumeration comparison between contexts, API availability tests, permission prompt screenshots, installation permission logs, permission revocation testing

**References**:

- Progressive Web Apps: https://web.dev/progressive-web-apps/
- Permissions API: https://www.w3.org/TR/permissions/
- PWA Security: https://www.w3.org/TR/appmanifest/#security-and-privacy

### Assessment: SYS-REQ-37 (PWA installation permission restrictions)

**Reference**: SYS-REQ-37 - PWA installation shall not auto-grant extended permissions at SYS-2 capability level

**Given**: A conformant browser with SYS-2 capability supporting Progressive Web Applications

**Task**: PWA installation should not silently grant permissions that would normally require explicit user consent during runtime, as automatic permission grants bypass user agency and create security risks. If installing a PWA automatically grants camera, microphone, geolocation, filesystem, or device API access without user awareness, malicious applications can gain surveillance and data access capabilities through social engineering of the installation flow alone. All permissions shall require explicit runtime consent after installation, ensuring users understand and authorize each capability access.

**Verification**:

1. Review PWA manifest for requested permissions and capabilities → Installation completes without granting permissions
2. Install a PWA that declares camera, microphone, and location permissions in manifest → Camera requires runtime permission prompt
3. After installation completes, verify no permissions are automatically granted without user consent → Microphone requires explicit user consent after install
4. Launch the installed PWA and attempt to access camera, verifying permission prompt appears → Geolocation prompts user at first access