EN-304-617.md

### Assessment: PRO-REQ-14 (Protocol handler revocation)

**Reference**: PRO-REQ-14 - Browser shall provide mechanisms to revoke protocol handler registrations

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

**Task**: Verify that protocol handler revocation mechanisms enable users to remove unwanted or malicious handlers that may have been registered through social engineering or deceptive UIs. Without effective revocation, users would be permanently stuck with handlers they didn't intend to register, allowing attackers to maintain persistent control over protocol scheme handling even after users discover the deception.

**Verification**:

1. Register multiple protocol handlers from different origins → Test that browser reset removes all custom protocol handlers
2. Navigate to browser settings and locate protocol handler management section → Settings UI provides clear handler management interface
3. Verify that all registered handlers are listed with scheme, origin, and URL template → All registered handlers are visible with complete details
4. Revoke a specific handler using the settings UI → Individual handlers can be selectively revoked
5. Verify that the revoked handler no longer appears in the handler list → Revoked handlers stop functioning immediately
6. Test that clicking custom protocol links no longer invokes the revoked handler → unregisterProtocolHandler() API works correctly
7. Verify that unregisterProtocolHandler() API can programmatically revoke handlers → Cross-origin revocation is prevented (only origin can unregister its handlers)
8. Test that only the registering origin can programmatically unregister its handlers → Site data clearing includes handler revocation
9. Verify that clearing site data revokes all handlers from that origin → Browser reset removes all handlers

**Pass Criteria**: Settings UI allows handler revocation AND unregisterProtocolHandler() API works AND cross-origin revocation prevented AND site clearing removes handlers

**Fail Criteria**: No revocation mechanism OR handlers persist after revocation OR cross-origin revocation possible OR site clearing doesn't affect handlers

**Evidence**: Settings UI screenshots showing handler management, revocation test results, unregisterProtocolHandler() examples, cross-origin revocation prevention tests, site data clearing verification, browser reset verification

**References**:

- WHATWG unregisterProtocolHandler API: https://html.spec.whatwg.org/multipage/system-state.html#dom-navigator-unregisterprotocolhandler
- Clear Site Data Specification: https://www.w3.org/TR/clear-site-data/
- Browser Settings Best Practices: https://www.w3.org/TR/security-privacy-questionnaire/
- Chrome Protocol Handler Settings: https://support.google.com/chrome/answer/114662
- Firefox Handler Management: https://support.mozilla.org/en-US/kb/change-program-used-open-email-links
- User Control and Transparency: https://www.w3.org/TR/privacy-principles/#user-control

### Assessment: PRO-REQ-15 (Cross-origin protocol restrictions)

**Reference**: PRO-REQ-15 - Browser shall enforce cross-origin restrictions for protocol handler registration and invocation

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

**Task**: Verify that cross-origin protocol restrictions enforce same-origin policy for handler registration and management, preventing malicious iframes from registering handlers on behalf of parent frames or vice versa. This isolation ensures that each origin maintains independent control over its handlers, preventing cross-origin attacks where embedded content could hijack the parent's protocol handling or manipulate handlers from other origins.

**Verification**:

1. Create a page at https://origin-a.example.com that registers a protocol handler → Verify that subdomains are treated as separate origins for handler registration
2. Create an iframe at https://origin-b.example.com embedded in origin-a → Protocol handlers are attributed to the registering origin (not parent frame)
3. Attempt to register a protocol handler from the iframe → Cross-origin iframes register handlers under their own origin
4. Verify that the handler is attributed to origin-b (iframe origin), not origin-a (parent) → Handlers can only be modified/removed by their registering origin
5. Test that handlers registered by origin-a cannot be unregistered by origin-b → Handler URL templates are same-origin with registration origin
6. Create a cross-origin link to custom protocol and verify handler invocation → Cross-origin invocation works but respects security boundaries
7. Test that handler URL templates match the registering origin → postMessage doesn't bypass origin restrictions
8. Verify that postMessage cannot be used to bypass handler origin restrictions → CORS policies are orthogonal to handler registration
9. Test that CORS policies don't affect protocol handler registration → Subdomain isolation is enforced (sub.example.com != example.com)

**Pass Criteria**: Handlers attributed to registering origin AND cross-origin modification prevented AND URL templates same-origin AND subdomain isolation enforced

**Fail Criteria**: Handler origin attribution incorrect OR cross-origin modification allowed OR URL templates can be cross-origin OR subdomain isolation violated

**Evidence**: Cross-origin registration tests, iframe attribution tests, cross-origin modification prevention tests, URL template origin validation, subdomain isolation tests, public suffix list verification

**References**:

- Same-Origin Policy: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
- HTML Origin Specification: https://html.spec.whatwg.org/multipage/origin.html
- CORS Specification: https://fetch.spec.whatwg.org/#http-cors-protocol
- Public Suffix List: https://publicsuffix.org/
- Iframe Security: https://html.spec.whatwg.org/multipage/iframe-embed-object.html
- Subdomain Security: https://tools.ietf.org/html/rfc6265#section-5.1.3

### Assessment: PRO-REQ-16 (Protocol handler manifest validation)

**Reference**: PRO-REQ-16 - Browser shall validate protocol handler manifests in Progressive Web Apps and installed web applications

**Given**: A conformant browser with PRO-1 or higher capability and support for Web App Manifests

**Task**: Progressive Web Apps can declare protocol handlers in their manifest files, creating a persistent attack surface that bypasses runtime API restrictions. Malicious PWAs could register handlers for privileged schemes, escape manifest scope restrictions, or persist handlers after uninstallation to maintain access to user data. Rigorous manifest validation ensures PWA protocol handlers meet the same security standards as API-registered handlers while preventing manifest-based handler abuse.

**Verification**:

1. Create a PWA with a manifest file declaring protocol handlers in protocol_handlers field → protocol_handlers field in manifest is parsed and validated
2. Install the PWA and verify that declared protocol handlers are registered → Declared handlers are registered upon app installation with user permission
3. Test manifest protocol handlers with invalid URL templates and verify rejection → Invalid handlers in manifest are rejected with clear error messages
4. Verify that manifest handlers require user permission before activation → Same security validations apply as registerProtocolHandler API
5. Test that manifest protocol handlers follow same security rules as registerProtocolHandler → Privileged schemes cannot be registered via manifest
6. Attempt to declare privileged schemes (http, https) in manifest and verify rejection → Handlers are removed when app is uninstalled
7. Test that manifest handlers are unregistered when app is uninstalled → Handlers point to URLs within app scope
8. Verify that manifest scope restrictions apply to protocol handlers → Manifest updates trigger handler re-validation
9. Test manifest handler updates when app manifest is updated → Developer console shows validation errors
10. Verify that manifest validation errors are reported to developer console → OS-level protocol handler registration occurs for installed apps

**Pass Criteria**: Manifest protocol_handlers validated AND user permission required AND same security rules as API AND uninstalled app removes handlers

**Fail Criteria**: Invalid manifests accepted OR no user permission OR weaker security than API OR handlers persist after uninstall

**Evidence**: Manifest examples with protocol handlers, installation flow screenshots, validation error messages, uninstallation verification, scope restriction tests, OS protocol handler registration proof, update handling tests

**References**:

- Web App Manifest Specification: https://www.w3.org/TR/appmanifest/
- PWA Protocol Handlers: https://web.dev/url-protocol-handler/
- URL Handlers in PWA: https://github.com/WICG/pwa-url-handler/blob/main/explainer.md
- Chrome PWA Installation: https://web.dev/install-criteria/
- MDN Web App Manifest: https://developer.mozilla.org/en-US/docs/Web/Manifest
- App Scope Specification: https://www.w3.org/TR/appmanifest/#scope-member

### Assessment: PRO-REQ-17 (Intent URL security - mobile)

**Reference**: PRO-REQ-17 - Browser shall implement security controls for Android Intent URLs and prevent intent scheme attacks

**Given**: A conformant mobile browser with PRO-1 or higher capability running on Android

**Task**: Android Intent URLs allow web pages to launch native applications with arbitrary parameters, creating a powerful attack vector for launching privileged system components, bypassing app permissions, or exfiltrating sensitive data through maliciously crafted intent extras. Intent scheme attacks can trigger dangerous actions like sending SMS, making calls, or accessing sensitive device features without proper authorization. Comprehensive intent URL validation prevents these attacks while maintaining legitimate app integration functionality.

**Verification**:

1. Create a test page with an intent URL: <a href="intent://example.com#Intent;scheme=http;package=com.example;end">Click</a> → Intent URLs are parsed and validated before invocation
2. Verify that clicking the intent link triggers appropriate security checks → Privileged system components cannot be launched via intent URLs
3. Test that malicious intent URLs cannot launch privileged system components → Dangerous actions trigger user permission prompts or are blocked
4. Attempt intent URL with dangerous actions (SEND_SMS, CALL, etc.) and verify blocking or permission prompts → Intent extras are sanitized to prevent injection attacks
5. Test intent URLs with arbitrary extras and verify sanitization → Intent URLs cannot bypass app permission model
6. Verify that intent URLs cannot bypass app permissions → Package name validation prevents targeting of unintended apps
7. Test that browser validates package names in intent URLs → Data exfiltration via intent URLs is prevented
8. Attempt to use intent URLs to exfiltrate data and verify prevention → Iframe intent URLs have restricted capabilities
9. Test that intent URLs from iframes have additional restrictions → Intent invocations are logged with target package and action
10. Verify that intent URL invocation is logged for security auditing → User confirmation required for sensitive intent actions

**Pass Criteria**: Intent URLs validated before launch AND privileged actions blocked AND extras sanitized AND user confirmation for sensitive actions AND invocations logged

**Fail Criteria**: Intent URLs launch without validation OR privileged actions allowed OR no sanitization OR no confirmation for sensitive actions OR not logged

**Evidence**: Intent URL test results, privileged action blocking verification, extras sanitization tests, permission prompt screenshots, iframe restriction tests, security log entries, data exfiltration prevention tests

**References**:

- Android Intent Specification: https://developer.android.com/reference/android/content/Intent
- Intent URL Scheme Security: https://tools.ietf.org/html/rfc8252#appendix-B.2
- Chrome Intent URLs: https://developer.chrome.com/docs/multidevice/android/intents/
- Android App Links: https://developer.android.com/training/app-links
- OWASP Mobile Security: https://owasp.org/www-project-mobile-security-testing-guide/
- Intent Security Best Practices: https://developer.android.com/guide/components/intents-filters#SafeIntent

### Assessment: PRO-REQ-18 (Universal Links security - iOS)

**Reference**: PRO-REQ-18 - Browser shall implement security controls for iOS Universal Links and prevent link hijacking

**Given**: A conformant mobile browser with PRO-1 or higher capability running on iOS

**Task**: iOS Universal Links enable seamless web-to-app transitions but create risks of link hijacking, phishing through malicious association files, and privacy violations through link interception tracking. Attackers can serve fraudulent apple-app-site-association files over compromised connections or use HTTP downgrade attacks to bypass domain validation. Strict validation of association files over HTTPS with certificate verification prevents unauthorized app launches and protects user privacy while maintaining legitimate app integration.

**Verification**:

1. Set up a test website with an apple-app-site-association file for Universal Links → apple-app-site-association file is validated before Universal Link activation
2. Create a link to a URL that matches a Universal Link pattern → HTTPS required for both the association file and triggering URLs
3. Verify that the browser validates the apple-app-site-association file before allowing app opening → Certificate validation enforced when fetching association file
4. Test that HTTPS is required for Universal Links (HTTP domains should be rejected) → Domain validation prevents unauthorized app openings
5. Verify that the association file is fetched over HTTPS with certificate validation → Malformed or malicious association files are rejected
6. Test that only domains listed in the association file can trigger the app → User choice between app and browser is preserved
7. Attempt to use a malicious association file and verify rejection → User preferences for Universal Links persist
8. Test that users can choose to open in app or browser → No user tracking via Universal Link interception
9. Verify that Universal Link preferences persist across sessions → Association file caching follows secure practices
10. Test that Universal Links respect user privacy (no tracking via link interception) → Link preview shows correct destination before opening

**Pass Criteria**: Association file validated over HTTPS AND certificate validation enforced AND user choice respected AND preferences persist

**Fail Criteria**: No association file validation OR HTTP accepted OR certificate errors ignored OR no user choice OR preferences don't persist

**Evidence**: Association file validation tests, HTTPS enforcement verification, certificate validation tests, malformed file rejection tests, user choice UI screenshots, preference persistence tests, privacy analysis

**References**:

- Apple Universal Links Documentation: https://developer.apple.com/ios/universal-links/
- Supporting Associated Domains: https://developer.apple.com/documentation/xcode/supporting-associated-domains
- apple-app-site-association Format: https://developer.apple.com/documentation/bundleresources/applinks
- Universal Links Security: https://developer.apple.com/videos/play/wwdc2019/717/
- Deep Linking Security: https://tools.ietf.org/html/rfc8252
- iOS Security Guide: https://support.apple.com/guide/security/welcome/web

### Assessment: PRO-REQ-19 (Deep linking validation)

**Reference**: PRO-REQ-19 - Browser shall validate deep links before navigation to prevent deep link hijacking and phishing

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

**Task**: Deep links enable direct navigation to specific app content but create attack vectors for parameter injection, XSS payload delivery, privilege escalation, and phishing through misleading app names or domains. Unvalidated deep links can bypass app sandboxes, exfiltrate data through malicious parameters, or launch unverified apps without user awareness. Comprehensive deep link validation with parameter sanitization, domain verification, and user confirmation for unverified apps prevents these attacks while maintaining legitimate app deep linking functionality.

**Verification**:

1. Create a deep link that targets a mobile app: myapp://user/profile?id=123 → Deep link format and structure validated before processing
2. Verify that the browser validates the deep link format before allowing navigation → Parameters in deep links are URL-encoded and sanitized
3. Test that parameters in deep links are sanitized to prevent injection → XSS payloads in deep links are neutralized
4. Attempt to use a deep link with XSS payload and verify sanitization → User confirmation required for unverified deep links
5. Test that deep links to unverified apps trigger user confirmation → Domain validation confirms app ownership of deep link domains
6. Verify that deep link domains are validated against app claims (App Links/Universal Links) → Deep links cannot escalate privileges or bypass sandbox
7. Test that deep links cannot bypass app sandbox or permissions → Phishing detection identifies misleading app names or domains
8. Attempt to use deep links for phishing (misleading app names) and verify warnings → HTTPS fallback works when target app not installed
9. Verify that HTTPS fallback URLs are used when app is not installed → Deep link invocations logged with destination and parameters
10. Test that deep link invocation is logged for security monitoring → Rate limiting prevents deep link abuse

**Pass Criteria**: Deep link format validated AND parameters sanitized AND user confirmation for unverified links AND domain validation enforced AND invocations logged

**Fail Criteria**: Invalid deep links accepted OR no parameter sanitization OR no confirmation for unverified links OR no domain validation OR not logged

**Evidence**: Deep link validation tests, parameter sanitization examples, XSS prevention tests, user confirmation screenshots, domain validation verification, phishing detection tests, fallback URL tests, security logs

**References**:

- 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 → navigate-to CSP directive restricts protocol handler destinations
2. Register a protocol handler from this page → CSP violations during handler operations are properly reported
3. Verify that protocol handler invocation respects the navigate-to CSP directive → Handler URL templates that violate CSP are rejected
4. Test that CSP violations during handler registration are reported → script-src controls JavaScript that registers handlers
5. Create a handler URL template that would violate CSP and verify blocking → form-action applies to forms with custom protocol actions
6. Test that the script-src directive affects protocol handler registration scripts → connect-src applies to handler page, not registration
7. Verify that form-action CSP directive applies to forms targeting custom protocols → Handler pages inherit appropriate CSP from their origin
8. Test that connect-src doesn't restrict protocol handler registration but affects handler page → CSP violation reports include handler-specific context
9. Verify that CSP inheritance works correctly for handler pages → Unsafe-inline and unsafe-eval restrictions apply to handlers
10. Test that CSP reports include protocol handler context when violations occur → 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 → Complete audit trail for all handler lifecycle events
2. Register a protocol handler and verify the registration is logged → Audit entries include: timestamp, identity, action, object, before/after state, outcome
3. Check that audit log includes: timestamp, origin, scheme, handler URL, user/admin identity → Failed operations logged with error details
4. Modify handler permissions and verify the change is audited → Permission changes audited with user decision
5. Unregister a handler and verify the removal is audited → Enterprise policy enforcement events included
6. Test that failed registration attempts are logged with error reasons → Audit logs are tamper-evident (signed or chained hashes)
7. Verify that permission grants/denials for handlers are audited → Logs exportable in standard formats (JSON, CEF, syslog)
8. Test that enterprise policy changes affecting handlers are logged → SIEM integration supported for centralized logging
9. Export the audit trail and verify it's in a tamper-evident format → Audit trail completeness can be verified
10. Verify that audit logs can be forwarded to enterprise SIEM systems → 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/27001
- 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 → Handler updates require same-origin or user permission
2. Attempt to update the handler URL template from the same origin → Cross-origin handler modification is prevented
3. Verify that the update requires user confirmation or follows original permissions → Active handler updates trigger user notification
4. Attempt to update the handler from a different origin (https://attacker.example.com) → PWA manifest handler updates follow secure update process
5. Verify that cross-origin updates are prevented → Handler URL changes are audited with before/after values
6. Test that handler updates during active use trigger security warnings → Updates to dangerous URL schemes (data:, javascript:) are blocked
7. Verify that automatic handler updates (e.g., PWA manifest updates) are validated → HTTPS-to-HTTP downgrades in handler URLs are prevented
8. Test that handler URL changes are logged in audit trail → Update frequency is rate-limited to prevent abuse
9. Attempt to update handler to point to data: or javascript: URLs and verify blocking → Failed update attempts are logged
10. Verify that downgrade protection applies to handler updates → 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 → Protocol handlers run in isolated renderer processes
2. Use browser internals (process inspection interface) to verify handler process isolation → Handler isolation follows Site Isolation architecture
3. Verify that handler pages run in separate renderer processes from the triggering page → Cross-origin data is not accessible from handler process
4. Test that compromised handler cannot access other origin's data → Handler processes are sandboxed with restricted capabilities
5. Verify that Site Isolation applies to protocol handler pages → IPC messages from handlers are validated and sanitized
6. Test that handler processes have appropriate sandbox restrictions → Handler crashes are isolated and don't affect browser stability
7. Verify that IPC between handler and browser process is validated → No elevated privileges granted to handler processes
8. Test that handler crash doesn't affect other tabs or browser stability → Memory isolation prevents cross-process memory access
9. Verify that handler processes don't have elevated privileges → Spectre/Meltdown mitigations apply to handler processes
10. Test that memory isolation prevents handler from reading other process memory → 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

### Assessment: PRO-REQ-24 (HTTP/HTTPS-only protocol restriction)

**Reference**: PRO-0-REQ-1 - Browser shall only support HTTP and HTTPS protocols

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

**Task**: Verify that the browser restricts all network communication to HTTP and HTTPS protocols exclusively, eliminating the attack surface introduced by custom protocol handlers, WebSocket, WebRTC, and other non-standard schemes, ensuring maximum security in environments where custom protocols are not needed and could be exploited to bypass security controls, exfiltrate data, or trigger local application vulnerabilities.

**Verification**:

1. Attempt to navigate to URLs with non-HTTP/HTTPS schemes: → Test that WebSocket connections are blocked (ws:// and wss://)
   - file:// URLs
   - data:// URLs
   - javascript:// URLs
   - ftp:// URLs
   - ws:// and wss:// URLs
   - Custom schemes (mailto:, tel:, etc.)
2. Verify that all non-HTTP/HTTPS navigation attempts are blocked → Verify that WebRTC connections cannot be established
3. Test that blocked navigation displays clear error message → Test that FTP protocol is not supported
4. Verify that error message does not suggest workarounds → Verify that data: URIs are blocked or heavily restricted
5. Test that links with custom protocols do not activate handlers → Test that no custom protocol registration UI exists
6. Verify that registerProtocolHandler() API is not available → Verify that browser help documentation indicates protocol restrictions

**Pass Criteria**: Only HTTP and HTTPS protocols functional AND all other protocols blocked AND clear error messages AND no workarounds available AND no protocol registration API

**Fail Criteria**: Non-HTTP/HTTPS protocols accessible OR unclear error messages OR workarounds exist OR protocol registration possible

**Evidence**: Navigation test results for various protocol schemes, error message screenshots, API availability verification, WebSocket/WebRTC connection attempts, protocol registration UI absence

**References**:

- URL Standard: https://url.spec.whatwg.org/
- Attack Surface Reduction: https://www.microsoft.com/en-us/security/blog/topic/attack-surface-reduction/

### Assessment: PRO-REQ-25 (Custom protocol handler registration rejection)

**Reference**: PRO-0-REQ-2 - Browser shall reject all custom protocol handler registration attempts

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

**Task**: Verify that the browser rejects all attempts to register custom protocol handlers through any mechanism, preventing web applications from registering handlers that could be exploited for phishing, command injection, or local application attacks, ensuring that protocol handling remains limited to built-in HTTP/HTTPS with no extensibility for custom schemes.

**Verification**:

1. Attempt to register custom protocol handler via registerProtocolHandler() API → Test that browser extensions cannot register protocol handlers
2. Verify that API call is rejected or API is undefined → Verify that enterprise policies cannot enable protocol registration
3. Test registration attempts for various schemes: → Test that command-line flags cannot bypass restriction
   - web+custom schemes
   - mailto: handler override
   - Custom application protocols
4. Verify that all registration attempts fail → Verify that error messages clearly indicate feature is disabled
5. Test that no protocol handler registration UI is available in settings → Test that web applications cannot detect registered handlers
6. Verify that manifest-based handler registration is not supported → Verify that no protocol handler storage or persistence exists

**Pass Criteria**: All protocol handler registration attempts rejected AND no registration API available AND no UI for registration AND extensions cannot register handlers AND no bypass mechanisms

**Fail Criteria**: Registration succeeds through any mechanism OR registration API accessible OR UI available OR extensions can register OR bypass possible

**Evidence**: API call rejection logs, registration attempt test results, settings UI verification, extension capability testing, policy override attempts, error messages

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

## 6.7 System Resource Access Security Assessments

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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