EN-304-617.md

8. Verify that integrity verification results are logged with specific failure details
9. Test that browser refuses to launch if critical component integrity verification fails
10. Confirm that integrity verification uses same cryptographic strength as update verification (SHA-256+)
11. Post-installation integrity verification checks all installed components
12. Cryptographic hashes (SHA-256+) are used for integrity verification
13. Modified files are detected immediately after installation
14. Startup integrity checks detect tampering between sessions
15. Critical components are verified (binaries, libraries, key resources)
16. Integrity failures trigger automatic repair or update mechanisms
17. Browser refuses to launch if critical components fail verification
18. Integrity verification results are logged with specific error details
19. Verification coverage includes all security-critical components

**Pass Criteria**: Post-installation integrity verification is performed AND uses strong cryptographic hashes (SHA-256+) AND modified files are detected AND integrity failures trigger repair OR prevent launch

**Fail Criteria**: No post-installation verification OR weak hash algorithms OR modified files not detected OR integrity failures do not trigger corrective actions

**Evidence**: Post-installation verification logs, hash algorithm analysis, test results from file modification attacks, startup integrity check logs, repair mechanism demonstrations, critical component verification coverage analysis

**References**:

- Chrome Component Integrity Verification: https://www.chromium.org/Home/chromium-security/education/tls#TOC-Certificate-Verification
- Windows Code Integrity: https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control
- macOS Gatekeeper and Code Signing: https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution
- Linux Integrity Measurement Architecture: https://sourceforge.net/p/linux-ima/wiki/Home/
- NIST File Integrity Monitoring: https://csrc.nist.gov/glossary/term/file_integrity_monitoring
- OWASP Software Component Verification: https://owasp.org/www-project-software-component-verification-standard/

### Assessment: UPD-REQ-21 (Staged rollout support)

**Reference**: UPD-REQ-21 - Browser shall support staged rollout mechanisms to gradually deploy updates to user populations with rollback capability

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

**Task**: Verify that staged rollout mechanisms limit the blast radius of defective updates while maintaining rapid response capability for critical security fixes. Gradual deployment with rollback capability prevents scenarios where buggy updates simultaneously impact millions of users, while emergency bypass ensures that actively exploited vulnerabilities can still be patched immediately across the entire user base.

**Verification**:

1. Review browser update architecture for staged rollout or canary deployment support
2. Verify that update manifests include rollout percentage or cohort targeting information
3. Test that updates are delivered to progressively larger user populations over time
4. Check that rollout stages are controlled by server-side configuration, not client manipulation
5. Verify that users cannot force-join or opt-out of rollout cohorts
6. Test that rollout can be paused or rolled back if issues are detected
7. Monitor multiple browser instances to observe different rollout timing
8. Verify that critical security updates can bypass staged rollout for immediate deployment
9. Test that rollout cohorts are assigned using stable user identifiers (not random per check)
10. Confirm that staged rollout status is logged for monitoring and analysis
11. Update system supports staged rollout with progressive deployment
12. Rollout percentages are specified in update manifests and enforced server-side
13. Users cannot manipulate rollout cohort assignment
14. Rollout can be paused or reversed if issues are detected
15. Critical security updates can bypass staged rollout
16. Cohort assignment is stable (same user gets consistent rollout timing)
17. Multiple instances show varied rollout timing based on cohort
18. Rollout status and cohort information are logged
19. Rollout progression follows defined stages (e.g., 1%, 10%, 50%, 100%)

**Pass Criteria**: Staged rollout mechanism is implemented AND rollout percentages are server-controlled AND users cannot manipulate cohorts AND critical updates can bypass rollout AND rollback capability exists

**Fail Criteria**: No staged rollout support OR users can manipulate rollout OR all users receive updates simultaneously OR no rollback capability OR critical updates follow slow rollout

**Evidence**: Update manifest files showing rollout percentages, server-side rollout configuration documentation, test results from multiple instances showing varied timing, rollout logs with cohort information, critical update bypass demonstrations, rollback process documentation

**References**:

- Chrome Staged Rollout: https://chromium.googlesource.com/chromium/src/+/main/docs/updater/functional_spec.md#staged-rollout
- Google Omaha Rollout Mechanisms: https://github.com/google/omaha/blob/main/doc/ServerProtocolV3.md#rollout
- Canary Deployments: https://martinfowler.com/bliki/CanaryRelease.html
- Progressive Delivery Patterns: https://www.split.io/glossary/progressive-delivery/
- NIST Phased Deployment: https://csrc.nist.gov/publications/detail/sp/800-40/rev-4/final

### Assessment: UPD-REQ-22 (Update domain validation)

**Reference**: UPD-REQ-22 - Browser shall validate that update requests and responses originate from authorized domains with strict certificate requirements

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

**Task**: Verify that update domain validation prevents server-side request forgery and domain confusion attacks where attackers redirect update requests to malicious servers through HTTP redirects, DNS manipulation, or compromised network infrastructure. Strict domain allowlisting ensures that browsers only download updates from explicitly authorized vendor domains, rejecting any deviation regardless of certificate validity.

**Verification**:

1. Capture update network traffic to identify all domains involved in update process
2. Verify that all update domains are whitelisted or hardcoded in browser configuration
3. Examine TLS certificates for update domains to verify they meet strict requirements (EV or equivalent)
4. Attempt to redirect update requests to unauthorized domains using DNS attacks
5. Test that update domain acceptlist cannot be modified by users or malware
6. Verify that update responses from unauthorized domains are rejected
7. Check that update domain validation includes subdomain restrictions (no wildcards)
8. Test that HTTP redirects to unauthorized domains during update process are rejected
9. Verify that update domain validation occurs for all update-related requests (manifests, downloads, telemetry)
10. Confirm that domain validation failures are logged with domain details
11. All update domains are explicitly whitelisted or hardcoded
12. TLS certificates for update domains meet strict requirements
13. Unauthorized domains are rejected even with valid TLS certificates
14. Domain acceptlist cannot be modified through configuration or registry
15. Subdomain validation is strict (no wildcard matching)
16. HTTP redirects to unauthorized domains are blocked
17. Domain validation applies to all update-related traffic
18. Validation failures are logged with attempted domain information
19. Update domain list is protected and verified at startup

**Pass Criteria**: Update domains are whitelisted/hardcoded AND unauthorized domains are rejected AND domain list cannot be modified AND validation applies to all update traffic AND redirects to unauthorized domains are blocked

**Fail Criteria**: No domain acceptlist OR unauthorized domains accepted OR domain list can be modified OR validation can be bypassed with redirects OR logging insufficient

**Evidence**: Network traffic captures showing update domains, domain acceptlist extraction from browser binary, test results from unauthorized domain redirects, TLS certificate analysis, domain validation logs, configuration modification attempt results

**References**:

- Chrome Update Domain Security: https://chromium.googlesource.com/chromium/src/+/main/docs/updater/protocol_3_1.md#security
- Mozilla Update Domain Policies: https://wiki.mozilla.org/Software_Update#Security
- DNS Security Extensions (DNSSEC): https://www.icann.org/resources/pages/dnssec-what-is-it-why-important-2019-03-05-en
- Extended Validation Certificates: https://en.wikipedia.org/wiki/Extended_Validation_Certificate
- OWASP Server-Side Request Forgery Prevention: https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html
- NIST Domain Validation Guidelines: https://csrc.nist.gov/publications/detail/sp/800-63/3/final

### Assessment: UPD-REQ-23 (Update binary reproducibility)

**Reference**: UPD-REQ-23 - Browser shall support mechanisms to enable verification of binary reproducibility for update transparency and supply chain security

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

**Task**: Verify that binary reproducibility enables independent verification of update authenticity, protecting against sophisticated supply chain attacks where build infrastructure is compromised to inject backdoors. Reproducible builds allow security researchers and organizations to verify that distributed binaries match published source code, detecting unauthorized modifications introduced during compilation or packaging.

**Verification**:

1. Review browser build and release documentation for reproducible build support
2. Verify that update packages include build metadata (compiler version, build timestamp, source commit)
3. Attempt to reproduce an official update binary from published source code using documented build process
4. Compare reproduced binary hash with official release hash to verify reproducibility
5. Check that build process documentation includes all dependencies and toolchain versions
6. Verify that update transparency logs include binary hashes for independent verification
7. Test that multiple independent parties can reproduce identical binaries from same source
8. Check for availability of build attestations or signed build manifests
9. Verify that non-reproducible elements (timestamps, randomness) are minimized or eliminated
10. Confirm that reproducibility documentation and verification tools are publicly available
11. Browser supports reproducible builds with documented build process
12. Update packages include complete build metadata
13. Independent verification of binary reproducibility is possible
14. Build process documentation includes all dependencies and toolchain versions
15. Multiple builds from same source produce bit-identical binaries
16. Update transparency logs enable third-party verification
17. Non-deterministic build elements are minimized or documented
18. Build attestations or signed manifests are available
19. Public documentation and tools support reproducibility verification

**Pass Criteria**: Reproducible build process is documented AND build metadata is included in updates AND independent parties can verify binary reproducibility AND update transparency supports third-party verification

**Fail Criteria**: No reproducible build support OR build process not documented OR independent verification not possible OR build metadata missing OR excessive non-deterministic elements

**Evidence**: Build process documentation, reproduced binary hash comparisons, build metadata extraction from update packages, transparency log entries, independent build verification results, build attestation signatures, reproducibility verification tool outputs

**References**:

- Reproducible Builds Project: https://reproducible-builds.org/
- Chromium Build Documentation: https://chromium.googlesource.com/chromium/src/+/main/docs/linux/build_instructions.md
- Debian Reproducible Builds: https://wiki.debian.org/ReproducibleBuilds
- NIST Secure Software Development Framework: https://csrc.nist.gov/Projects/ssdf
- SLSA Supply Chain Security Framework: https://slsa.dev/

## 6.6 Protocol Handler Security Assessments

This section covers assessment procedures for requirements PRO-REQ-1 through PRO-REQ-23, addressing custom protocol handler registration, scheme hijacking prevention, protocol allowlisting, URL scheme security, mobile deep linking, and handler isolation.

### Assessment: PRO-REQ-1 (Protocol handler registration validation)

**Reference**: PRO-REQ-1 - Browser shall validate all custom protocol handler registrations to ensure they meet security requirements before registration

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

**Task**: Verify that protocol handler registration validation prevents malicious websites from hijacking critical URL schemes or injecting XSS vectors through handler templates. Without strict validation, attackers could register handlers for privileged schemes like javascript: or craft handler URLs containing script injection, enabling cross-site scripting attacks when victims click protocol links.

**Verification**:

1. Navigate to a test page that attempts to register a custom protocol handler using registerProtocolHandler()
2. Test registration with a valid web+custom scheme (e.g., web+music, web+calendar)
3. Attempt to register a handler for a dangerous built-in scheme (http, https, file, javascript)
4. Verify that the browser rejects registration attempts for privileged schemes
5. Test registration with malformed URL templates (missing %s placeholder, invalid URL format)
6. Verify that only HTTPS origins can register protocol handlers (HTTP origins should be rejected)
7. Test that the handler URL template is properly validated for XSS vectors
8. Attempt to register handlers with data: or blob: URLs and verify rejection
9. Test registration from an iframe and verify same-origin policy enforcement
10. Verify that successful registrations require user permission or confirmation
11. Valid web+custom scheme registrations are accepted after validation
12. Built-in privileged schemes (http, https, file, javascript, data, blob) cannot be registered
13. Only HTTPS origins can register protocol handlers
14. URL templates shall include %s placeholder and be valid URLs
15. Malformed registrations are rejected with appropriate error messages
16. XSS vectors in handler URLs are sanitized or rejected
17. Registration from iframes follows same-origin policy
18. User permission is required before handler activation

**Pass Criteria**: Browser validates protocol registrations AND rejects privileged schemes AND requires HTTPS origins AND validates URL templates AND requires user permission

**Fail Criteria**: Privileged schemes can be registered OR HTTP origins accepted OR invalid URL templates accepted OR no user permission required OR XSS vectors not sanitized

**Evidence**: Screenshots of registration attempts for various schemes, console error messages for rejected registrations, permission prompt screenshots, network traces showing HTTPS enforcement, XSS test results, developer console outputs

**References**:

- WHATWG HTML Standard - registerProtocolHandler: https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
- MDN registerProtocolHandler API: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler
- Custom URL Scheme Security: https://tools.ietf.org/html/rfc8252#section-7.1
- Protocol Handler Security Best Practices: https://www.chromium.org/developers/design-documents/create-amazing-password-forms/
- OWASP URL Validation: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
- Web Application Security Working Group: https://www.w3.org/2011/webappsec/

### Assessment: PRO-REQ-2 (User consent for custom protocols)

**Reference**: PRO-REQ-2 - Browser shall obtain explicit user consent before activating custom protocol handlers

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

**Task**: Verify that protocol handler consent requirements prevent malicious websites from silently registering handlers that could launch local applications or exfiltrate data through custom protocols without user knowledge. Explicit consent ensures users understand which websites can intercept specific protocol schemes, protecting against protocol handler hijacking where attackers register handlers to intercept sensitive protocol activations.

**Verification**:

1. Register a custom protocol handler (web+test) on a test page
2. Verify that registration triggers a permission prompt to the user
3. Test that the permission prompt clearly identifies the scheme and handling origin
4. Click a link with the custom protocol (web+test:example) and verify activation prompt
5. Test that users can allow, deny, or remember the choice for the handler
6. Verify that denying handler activation falls back to default behavior or shows error
7. Test that remembered choices persist across browser sessions
8. Navigate to browser settings and verify users can revoke protocol handler permissions
9. Test that each origin requires separate consent (cross-origin isolation)
10. Verify that permission prompts cannot be spoofed or triggered without user action
11. Protocol handler registration shows clear permission prompt
12. Permission prompt identifies the custom scheme and requesting origin
13. Activation of custom protocol shows confirmation before launching handler
14. Users can allow, deny, or set persistent preferences
15. Permission choices persist across sessions
16. Settings provide UI to view and revoke handler permissions
17. Each origin requires independent user consent
18. Permission prompts are genuine browser UI (not web content)
19. Consent is required for each distinct protocol scheme

**Pass Criteria**: Explicit user consent required for registration AND activation prompts shown before launching AND permissions are manageable in settings AND cross-origin isolation enforced

**Fail Criteria**: No consent prompts displayed OR handlers activate without user permission OR permissions cannot be revoked OR cross-origin handlers share permissions

**Evidence**: Screenshots of permission prompts (registration and activation), settings UI showing handler permissions, video recording of consent flow, persistent permission test results, cross-origin permission isolation tests, prompt timing analysis

**References**:

- WHATWG HTML Standard - User Activation: https://html.spec.whatwg.org/multipage/interaction.html#tracking-user-activation
- Permissions API Specification: https://www.w3.org/TR/permissions/
- User Consent Best Practices: https://www.w3.org/TR/security-privacy-questionnaire/
- GDPR Consent Requirements: https://gdpr.eu/gdpr-consent-requirements/
- Chrome Permission UX Guidelines: https://developer.chrome.com/docs/extensions/mv3/permission_warnings/
- Mozilla Permission Prompts: https://support.mozilla.org/en-US/kb/permissions-manager-give-ability-store-passwords-set-cookies-more

### Assessment: PRO-REQ-3 (Protocol allowlist enforcement)

**Reference**: PRO-REQ-3 - Browser shall enforce protocol allowlists that restrict which custom schemes can be registered

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

**Task**: Verify that protocol allowlist enforcement prevents registration of dangerous schemes that could enable code execution, data exfiltration, or privilege escalation through protocol handlers. Strict allowlisting blocks attackers from registering handlers for privileged schemes like vbscript: or shell: that could execute arbitrary code when activated.

**Verification**:

1. Review browser documentation for allowed custom protocol scheme patterns
2. Attempt to register a handler for web+validname and verify acceptance
3. Test registration with schemes that don't follow web+ prefix convention
4. Verify that safelisted schemes (mailto, tel, sms) can be registered with special handling
5. Attempt to register handlers for blocklisted dangerous schemes (vbscript, shell, etc.)
6. Test enterprise policy controls for custom protocol allowlists
7. Verify that scheme names follow DNS label conventions (alphanumeric, hyphens)
8. Test that scheme names are case-insensitive during registration and matching
9. Attempt registration with excessively long scheme names and verify length limits
10. Verify that only approved safelist schemes bypass the web+ prefix requirement
11. Custom schemes use web+ prefix unless on explicit safelist
12. Safelisted schemes (mailto, tel, sms) can be registered without web+ prefix
13. Dangerous schemes (javascript, data, vbscript, shell) are blocklisted
14. Scheme names follow DNS label conventions (alphanumeric, hyphens, no spaces)
15. Scheme matching is case-insensitive
16. Length limits prevent excessively long scheme names (e.g., 64 character limit)
17. Enterprise policies can extend or restrict allowlists
18. Invalid scheme patterns are rejected with clear error messages

**Pass Criteria**: web+ prefix required for custom schemes AND safelist exceptions work correctly AND blocklist prevents dangerous schemes AND scheme validation follows standards

**Fail Criteria**: web+ prefix not enforced OR dangerous schemes accepted OR invalid scheme patterns allowed OR no length limits

**Evidence**: Registration test results for various scheme patterns, error messages for rejected schemes, enterprise policy configuration examples, scheme validation test matrix, documentation of allowlist and blocklist

**References**:

- WHATWG URL Standard - Schemes: https://url.spec.whatwg.org/#schemes
- RFC 3986 URI Generic Syntax: https://www.rfc-editor.org/rfc/rfc3986#section-3.1
- Custom URL Scheme Guidelines: https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml
- Chromium URL Scheme List: https://source.chromium.org/chromium/chromium/src/+/main:url/url_constants.cc
- Safari Custom Protocol Handlers: https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app
- Mozilla Protocol Handler Allowlist: https://searchfox.org/mozilla-central/source/dom/base/nsContentUtils.cpp

### Assessment: PRO-REQ-4 (Scheme hijacking prevention)

**Reference**: PRO-REQ-4 - Browser shall prevent scheme hijacking attacks where malicious handlers override legitimate protocol handlers

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

**Task**: Verify that scheme hijacking prevention protects users from malicious websites that attempt to override legitimate protocol handlers to intercept sensitive protocol activations. Without protection, attackers could register handlers for schemes like mailto: or custom banking protocols to capture credentials, redirect users, or exfiltrate data when victims click protocol links.

**Verification**:

1. Register a legitimate protocol handler for web+test from https://trusted.example.com
2. Attempt to register a competing handler for web+test from https://malicious.example.com
3. Verify that the browser either prevents the override or prompts user for choice
4. Test that the most recently used or user-preferred handler takes precedence
5. Verify that built-in handlers (mailto, tel) cannot be completely overridden without permission
6. Test that unregistering a handler doesn't automatically activate an attacker's handler
7. Attempt to register a handler that impersonates a well-known service
8. Verify that handler selection UI clearly shows the origin of each handler
9. Test that handlers registered in private/incognito mode don't persist
10. Verify that resetting browser settings revokes all custom protocol handlers
11. Multiple handlers for same scheme trigger user choice rather than silent override
12. User can see and select from all registered handlers for a scheme
13. Built-in handlers maintain priority or require explicit user override
14. Handler selection UI clearly displays origin and scheme information
15. Private/incognito mode handlers are session-only
16. Browser reset revokes all custom handlers
17. No automatic activation of handlers after unregistration
18. Handler precedence is deterministic and user-controllable

**Pass Criteria**: Multiple handlers for same scheme require user selection AND origins clearly displayed AND built-in handlers protected AND private mode isolation enforced

**Fail Criteria**: Silent override of existing handlers OR origins not displayed OR built-in handlers easily hijacked OR private mode handlers persist

**Evidence**: Screenshots of handler selection UI, multi-handler registration test results, private mode isolation verification, browser reset test results, handler precedence documentation, user choice recording

**References**:

- Same-Origin Policy for Handlers: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
- URL Scheme Hijacking Prevention: https://portswigger.net/web-security/dom-based/open-redirection
- OWASP URL Redirection Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html
- Browser Handler Precedence: https://html.spec.whatwg.org/multipage/system-state.html#concept-handler-precedence

### Assessment: PRO-REQ-5 (Protocol parameter sanitization)

**Reference**: PRO-REQ-5 - Browser shall sanitize protocol URL parameters before passing them to protocol handlers

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

**Task**: Verify that protocol parameter sanitization prevents injection attacks where malicious protocol URLs containing special characters could exploit vulnerabilities in handler implementations. Without proper encoding, protocol parameters containing script tags, SQL commands, or command injection payloads could execute in the context of the handling website or application, enabling XSS, SQLi, or remote code execution.

**Verification**:

1. Register a test protocol handler with URL template: https://handler.example.com/handle?url=%s
2. Create a test link with XSS payload: <a href="web+test:<script>alert(1)</script>">Click</a>
3. Click the link and verify that the script payload is URL-encoded when passed to handler
4. Test with SQL injection characters in protocol URL and verify proper encoding
5. Attempt protocol URL with newline/CRLF characters and verify sanitization
6. Test with null bytes and other control characters in protocol URL
7. Verify that the %s placeholder is properly substituted with encoded parameter
8. Test with extremely long protocol parameters and verify truncation or rejection
9. Attempt to include additional parameters beyond the defined template
10. Verify that Unicode characters are properly normalized and encoded
11. All special characters in protocol URLs are properly URL-encoded
12. Script tags and JavaScript code are encoded, not executed
13. SQL injection characters are escaped/encoded
14. CRLF and newline characters are stripped or encoded
15. Null bytes and control characters are removed or encoded
16. Parameter substitution uses safe encoding (encodeURIComponent or equivalent)
17. Extremely long parameters are truncated or rejected
18. Template structure is enforced (no parameter injection)
19. Unicode is normalized (NFC) and safely encoded

**Pass Criteria**: All special characters properly URL-encoded AND XSS payloads neutralized AND injection attacks prevented AND template structure enforced

**Fail Criteria**: Special characters not encoded OR XSS possible through protocol parameters OR injection successful OR template can be modified

**Evidence**: XSS test results showing encoding, SQL injection test results, CRLF injection tests, parameter encoding examples, extremely long parameter handling, Unicode normalization tests, network traces showing encoded parameters

**References**:

- OWASP XSS Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html
- URL Encoding RFC 3986: https://www.rfc-editor.org/rfc/rfc3986#section-2.1
- JavaScript URL Encoding: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent
- Parameter Injection Attacks: https://owasp.org/www-community/attacks/Command_Injection
- Content Security Policy: https://www.w3.org/TR/CSP3/

### Assessment: PRO-REQ-6 (External protocol handler security)

**Reference**: PRO-REQ-6 - Browser shall implement security controls when launching external (OS-level) protocol handlers

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

**Task**: Verify that external protocol handler security prevents malicious websites from silently launching local applications with crafted parameters that could enable command injection or arbitrary code execution. Confirmation prompts and parameter sanitization ensure users understand what application is being launched and prevent attackers from exploiting vulnerable OS-level handlers through injection attacks.

**Verification**:

1. Configure an OS-level protocol handler for a custom scheme (e.g., myapp://)
2. Create a web page with a link to the custom protocol: <a href="myapp://test">Launch</a>
3. Click the link and verify that a confirmation prompt appears before launching
4. Test that the confirmation clearly identifies the external application to be launched
5. Verify that parameters passed to external handlers are sanitized
6. Test launching external handlers with malicious parameters (command injection attempts)
7. Attempt to launch external handlers from iframes and verify restrictions
8. Test that user should click or interact to trigger external handler (no automatic launch)
9. Verify that external handler launches respect user preferences (allow/deny lists)
10. Test that repeated external handler launches don't bypass confirmation prompts
11. Confirmation prompt appears before launching any external protocol handler
12. Prompt identifies the target application and protocol scheme
13. User shall explicitly approve each launch (or set persistent preference)
14. Parameters are sanitized to prevent command injection
15. Automatic launch is prevented (requires user gesture)
16. Iframe restrictions prevent silent external handler launches
17. User preferences for external handlers are persistent and accessible
18. Allow/deny lists work correctly for external protocols
19. Repeated launches maintain security checks

**Pass Criteria**: Confirmation required for external handler launches AND application identified in prompt AND parameters sanitized AND user gesture required

**Fail Criteria**: External handlers launch without confirmation OR application not identified OR command injection possible OR automatic launch allowed

**Evidence**: Screenshots of external handler confirmation prompts, command injection test results, parameter sanitization verification, user gesture requirement tests, iframe restriction tests, preference persistence verification

**References**:

- External Protocol Handler Security: https://textslashplain.com/2019/08/28/browser-architecture-web-to-app-communication-overview/
- macOS URL Scheme Handling: https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app
- Linux Desktop Entry Specification: https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html

### Assessment: PRO-REQ-7 (Protocol handler UI transparency)

**Reference**: PRO-REQ-7 - Browser shall provide transparent UI that clearly indicates when protocol handlers are registered or invoked

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

**Task**: Verify that protocol handler UI transparency prevents deceptive handler registrations where users unknowingly grant protocol handling permissions without understanding the security implications. Transparent UI ensures users can identify, review, and revoke protocol handlers, protecting against social engineering attacks where malicious sites silently register handlers to intercept sensitive protocol activations.

**Verification**:

1. Navigate to a page and register a custom protocol handler
2. Verify that a clear notification or permission prompt appears during registration
3. Check that the browser UI shows an indicator when handlers are registered (e.g., icon in address bar)
4. Click a custom protocol link and verify that the handler invocation is visible to user
5. Test that handler management UI is accessible from browser settings
6. Verify that the settings UI lists all registered handlers with origins and schemes
7. Test that users can easily identify which handler will be invoked for a scheme
8. Verify that handler removal is straightforward from the settings UI
9. Test that the browser provides clear feedback when handler invocation fails
10. Verify that developer tools show protocol handler events for debugging
11. Registration triggers visible notification or permission request
12. Browser UI indicates when handlers are registered for current origin
13. Handler invocation shows clear user feedback (dialog, notification, or status)
14. Settings provide comprehensive handler management interface
15. All registered handlers listed with scheme, origin, and URL template
16. Handler selection and removal are user-friendly
17. Failed handler invocations show error messages
18. Developer console logs handler events
19. No silent or hidden handler operations

**Pass Criteria**: Registration and invocation visible to user AND settings provide handler management AND all handlers listed with details AND clear feedback for all operations

**Fail Criteria**: Silent handler operations OR no settings UI for management OR handlers hidden from user OR no feedback on invocation

**Evidence**: Screenshots of registration notifications, address bar indicators, settings UI showing handler list, handler invocation UI, error messages, developer console logs, video walkthrough of handler lifecycle

**References**:

- User Interface Security Principles: https://www.w3.org/TR/security-privacy-questionnaire/#questions
- Chrome Protocol Handler Settings: https://support.google.com/chrome/answer/114662
- Firefox Protocol Handler Management: https://support.mozilla.org/en-US/kb/change-program-used-open-email-links
- WCAG Accessibility Guidelines: https://www.w3.org/WAI/WCAG21/quickref/
- User-Centered Security Design: https://www.usenix.org/conference/soups2019

### Assessment: PRO-REQ-8 (Protocol downgrade protection)

**Reference**: PRO-REQ-8 - Browser shall prevent protocol downgrade attacks where HTTPS handlers are replaced with HTTP handlers

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

**Task**: Verify that protocol downgrade protection prevents attackers from replacing secure HTTPS handlers with insecure HTTP handlers to enable man-in-the-middle attacks on protocol activations. Without downgrade protection, attackers could register HTTP handlers to intercept sensitive data passed through protocol URLs that were previously handled securely over HTTPS.

**Verification**:

1. Register a protocol handler from an HTTPS origin: https://secure.example.com/handler?url=%s
2. Attempt to register a handler for the same scheme from an HTTP origin: http://insecure.example.com/handler?url=%s
3. Verify that the HTTP handler registration is rejected or requires explicit user confirmation
4. Test that handler URL templates are HTTPS if registered from HTTPS origins
5. Attempt to update an existing HTTPS handler to use an HTTP URL template
6. Verify that downgrades are prevented or trigger security warnings
7. Test that HSTS policies affect protocol handler registration
8. Verify that mixed content policies apply to handler URL templates
9. Test that handler invocation follows upgrade-insecure-requests policy
10. Verify that downgrade attempts are logged for security monitoring
11. HTTP origins cannot register handlers if HTTPS origin has already registered
12. Handler URL templates are HTTPS for security-sensitive schemes
13. Existing HTTPS handlers cannot be downgraded to HTTP
14. HSTS policies prevent HTTP handler registration for HSTS hosts
15. Mixed content blocking applies to handler URLs
16. Upgrade-insecure-requests policy upgrades handler URLs when applicable
17. Downgrade attempts generate security warnings or errors
18. Security events are logged for downgrade attempts

**Pass Criteria**: HTTP handler registration blocked when HTTPS exists AND URL templates are HTTPS AND HSTS enforced for handlers AND downgrade attempts logged

**Fail Criteria**: HTTP handlers can override HTTPS handlers OR HTTP URL templates accepted OR HSTS not enforced OR no logging of downgrades

**Evidence**: Downgrade test results, HSTS enforcement verification, mixed content policy tests, security warning screenshots, event logs showing downgrade attempts, upgrade-insecure-requests verification

**References**:

- HTTP Strict Transport Security (HSTS) RFC 6797: https://www.rfc-editor.org/rfc/rfc6797
- Upgrade Insecure Requests: https://www.w3.org/TR/upgrade-insecure-requests/
- Mixed Content Specification: https://www.w3.org/TR/mixed-content/
- Chrome HTTPS Best Practices: https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https
- Mozilla Web Security Guidelines: https://infosec.mozilla.org/guidelines/web_security

### Assessment: PRO-REQ-9 (Protocol handler logging)

**Reference**: PRO-REQ-9 - Browser shall log protocol handler registration, modification, and invocation events for security auditing

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

**Task**: Verify that protocol handler logging creates comprehensive audit trails of handler lifecycle events, enabling detection of malicious handler registrations, unauthorized invocations, or suspicious patterns that could indicate compromise. Complete logging supports security investigations by providing forensic evidence of when handlers were registered, by whom, and how they were used.

**Verification**:

1. Enable security event logging in browser configuration
2. Register a custom protocol handler and verify the event is logged
3. Check that the log entry includes: timestamp, origin, scheme, handler URL template, user decision
4. Invoke a registered protocol handler and verify the invocation is logged
5. Modify an existing handler (if supported) and verify the change is logged
6. Unregister a protocol handler and verify the removal is logged
7. Test that failed registration attempts are logged with error reasons
8. Verify that external protocol handler launches are logged
9. Test that logs include sufficient context for security analysis
10. Export protocol handler logs and verify they are in structured format
11. All handler lifecycle events are logged (registration, invocation, modification, removal)
12. Log entries include complete metadata: timestamp, origin, scheme, URL template, user action
13. Failed registration attempts are logged with error details
14. External handler invocations are logged separately from web handlers
15. Logs distinguish between user-initiated and script-initiated events
16. Log format is structured (JSON or similar) for analysis
17. Logs can be exported for security monitoring
18. Log retention follows security event retention policies
19. Sensitive parameters are redacted from logs

**Pass Criteria**: All handler lifecycle events logged with complete metadata AND failed attempts logged AND logs exportable in structured format

**Fail Criteria**: Handler events not logged OR logs lack critical metadata OR failed attempts not logged OR logs not exportable

**Evidence**: Log exports showing handler events, log entry examples with metadata, failed registration logs, external handler invocation logs, log format documentation, retention policy verification

**References**:

- NIST SP 800-92 Log Management: https://csrc.nist.gov/publications/detail/sp/800-92/final
- W3C Reporting API: https://www.w3.org/TR/reporting-1/
- OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- Audit Trail Requirements: https://www.iso.org/standard/54534.html

### Assessment: PRO-REQ-10 (Web+custom scheme support)

**Reference**: PRO-REQ-10 - Browser shall support web+custom scheme format for custom protocol handlers as specified by WHATWG

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

**Task**: Verify that web+custom scheme support enforces the WHATWG-specified naming convention that prevents namespace collisions with system-level or IANA-registered schemes. The web+ prefix requirement ensures custom web handlers are clearly distinguished from OS-level protocol handlers, preventing malicious sites from hijacking system protocols while enabling safe custom protocol functionality.

**Verification**:

1. Register a protocol handler using web+ prefix: registerProtocolHandler('web+music', 'https://handler.example.com/play?url=%s')
2. Verify that the registration succeeds for properly formatted web+ schemes
3. Test that web+ schemes are case-insensitive (web+music equals WEB+MUSIC)
4. Create a link with web+music:track123 and verify it invokes the handler
5. Test that schemes without web+ prefix (except safelisted) are rejected
6. Verify that web+ is followed by at least one alphanumeric character
7. Test that web+ alone (without suffix) is rejected
8. Verify that web+ schemes follow DNS label rules (no spaces, special chars limited)
9. Test registration of multiple different web+ schemes from same origin
10. Verify that web+ handlers work correctly across different browser contexts
11. web+ prefix is recognized and properly handled
12. Schemes are case-insensitive during registration and matching
13. web+ shall be followed by valid scheme name (alphanumeric, hyphens)
14. web+ alone without suffix is invalid
15. Scheme names follow DNS label conventions
16. Multiple web+ schemes can be registered from same origin
17. Links with web+ schemes correctly invoke registered handlers
18. Error messages guide developers on correct web+ format
19. Cross-context invocation works (different tabs, windows)

**Pass Criteria**: web+ prefix required and recognized AND case-insensitive matching AND DNS label rules enforced AND multiple schemes supported per origin

**Fail Criteria**: web+ prefix not recognized OR case-sensitive matching OR invalid scheme names accepted OR only one scheme per origin

**Evidence**: Registration test results for various web+ formats, case sensitivity tests, scheme validation test matrix, multi-scheme registration examples, error message documentation, cross-context invocation tests

**References**:

- WHATWG HTML Standard - web+ Schemes: https://html.spec.whatwg.org/multipage/system-state.html#normalize-protocol-handler-parameters
- RFC 3986 URI Scheme Syntax: https://www.rfc-editor.org/rfc/rfc3986#section-3.1
- Custom Protocol Handler Specification: https://html.spec.whatwg.org/multipage/system-state.html#custom-handlers
- MDN web+ Scheme Documentation: https://developer.mozilla.org/en-US/docs/Web/API/Navigator/registerProtocolHandler#permitted_schemes
- DNS Label Syntax RFC 1035: https://www.rfc-editor.org/rfc/rfc1035
- Browser Protocol Handler Implementation: https://www.chromium.org/developers/design-documents/create-amazing-password-forms/

### Assessment: PRO-REQ-11 (Protocol handler persistence)

**Reference**: PRO-REQ-11 - Browser shall persist protocol handler registrations across sessions while respecting privacy modes

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

**Task**: Verify that protocol handler persistence balances usability with privacy by maintaining registrations across normal browser sessions while ensuring private mode handlers do not leak across sessions. This prevents privacy violations where private browsing handlers could reveal user activity history while maintaining functionality for legitimate persistent handler registrations.

**Verification**:

1. Register a protocol handler in normal browsing mode
2. Close the browser and reopen it
3. Verify that the protocol handler registration persists and is still functional
4. Click a custom protocol link and verify the handler still works after restart
5. Register a protocol handler in private/incognito mode
6. Verify that the handler works during the private session
7. Close the private/incognito window and open a new one
8. Verify that the handler registered in private mode does NOT persist
9. Test that clearing browsing data removes protocol handler registrations
10. Verify that exported browser profiles include protocol handler settings
11. Handler registrations persist across normal browser restarts
12. Registered handlers remain functional after session closure
13. Private/incognito mode handlers are session-only (do not persist)
14. Private mode handlers do not leak to normal mode or vice versa
15. Clearing browsing data removes handler registrations
16. Handler persistence respects user privacy preferences
17. Profile export/import includes handler configurations
18. Handler storage is properly synchronized in multi-device scenarios

**Pass Criteria**: Normal mode handlers persist across sessions AND private mode handlers are session-only AND data clearing removes handlers AND profile export includes handlers

**Fail Criteria**: Normal handlers don't persist OR private handlers persist OR data clearing doesn't remove handlers OR handlers not in profile export

**Evidence**: Persistence test results across restarts, private mode isolation verification, data clearing test results, profile export/import examples, multi-device sync verification (if applicable)

**References**:

- Browser Storage Persistence: https://storage.spec.whatwg.org/
- Private Browsing Mode Specification: https://www.w3.org/TR/tracking-dnt/#private-browsing
- Clear Browsing Data Specification: https://www.w3.org/TR/clear-site-data/
- Firefox Private Browsing: https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history
- Chrome Incognito Mode: https://support.google.com/chrome/answer/95464

### Assessment: PRO-REQ-12 (Protocol confusion mitigation)

**Reference**: PRO-REQ-12 - Browser shall mitigate protocol confusion attacks where similar-looking schemes are used to deceive users

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

**Task**: Verify that protocol confusion mitigation prevents homograph attacks where visually similar scheme names using Unicode characters deceive users into trusting malicious handlers. Attackers could register handlers for schemes that look identical to legitimate ones using Cyrillic or other non-Latin characters, tricking users into believing they're using trusted handlers while data is actually sent to attacker-controlled servers.

**Verification**:

1. Attempt to register a protocol handler using homoglyphs (e.g., web+test with Cyrillic 'e' instead of Latin 'e')
2. Verify that the browser normalizes Unicode in scheme names or rejects homoglyphs
3. Test registration with mixed scripts in scheme names (Latin + Cyrillic)
4. Attempt to register schemes that visually resemble built-in schemes (e.g., web+https with Cyrillic characters)
5. Verify that scheme names are restricted to ASCII alphanumeric and hyphens
6. Test that UI clearly displays scheme names without ambiguity
7. Verify that punycode or IDN homographs are not allowed in scheme names
8. Test registration of schemes with confusable characters (0 vs O, 1 vs l)
9. Verify that handler selection UI disambiguates similar schemes
10. Test that schemes with different Unicode normalization forms are treated as different
11. Scheme names are restricted to ASCII alphanumeric characters and hyphens
12. Unicode homoglyphs in scheme names are rejected
13. Mixed script scheme names are not allowed
14. Schemes visually similar to built-in schemes are flagged or rejected
15. UI displays scheme names in monospace or disambiguating font
16. Punycode/IDN encoding not allowed in scheme names
17. Confusable character combinations are prevented or warned
18. Different Unicode normalizations are properly handled
19. User is warned when schemes are potentially confusing

**Pass Criteria**: Scheme names restricted to ASCII AND homoglyphs rejected AND confusable schemes flagged AND UI clearly displays schemes

**Fail Criteria**: Unicode homoglyphs accepted OR mixed scripts allowed OR confusing schemes not flagged OR ambiguous UI display

**Evidence**: Homoglyph test results, Unicode normalization tests, confusable character test matrix, UI screenshots showing scheme display, rejection error messages, scheme validation code review

**References**:

- Unicode Security Considerations: https://www.unicode.org/reports/tr36/
- Homograph Attacks: https://en.wikipedia.org/wiki/IDN_homograph_attack
- ASCII URI Schemes RFC 3986: https://www.rfc-editor.org/rfc/rfc3986#section-3.1
- Chrome IDN Spoof Protection: https://chromium.googlesource.com/chromium/src/+/master/docs/idn.md
- OWASP Unicode Security: https://owasp.org/www-community/attacks/Unicode_Encoding

### Assessment: PRO-REQ-13 (Handler capability restrictions)

**Reference**: PRO-REQ-13 - Browser shall restrict capabilities available to protocol handlers based on context and permissions

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

**Task**: Verify that handler capability restrictions prevent privilege escalation where malicious handlers exploit protocol invocation to gain unauthorized access to APIs or bypass security policies. Handlers must operate within their origin's security context without inheriting privileges from the protocol scheme itself, preventing attackers from using custom protocols to circumvent same-origin policy or Content Security Policy restrictions.

**Verification**:

1. Register a protocol handler and invoke it with a custom protocol URL
2. Verify that the handler page inherits security context from its origin, not protocol URL
3. Test that handler cannot access privileged APIs without proper permissions
4. Verify that protocol parameters don't grant additional capabilities
5. Test that handlers follow Content Security Policy of their origin
6. Attempt to access local files from handler and verify blocking
7. Test that handlers cannot bypass same-origin policy using protocol parameters
8. Verify that handlers in iframes have restricted capabilities
9. Test that handler invocation doesn't grant automatic permission escalation
10. Verify that handlers respect Permissions Policy (formerly Feature Policy)
11. Handler security context is based on handler URL origin, not protocol
12. Privileged APIs require explicit permissions (not granted by handler status)
13. CSP of handler origin is enforced
14. Protocol parameters cannot inject capabilities or bypass security
15. Local file access is blocked unless explicitly permitted
16. Same-origin policy is enforced for handlers
17. Iframe handlers have sandboxed capabilities
18. No automatic permission grants upon handler invocation
19. Permissions Policy restrictions are enforced

**Pass Criteria**: Handler capabilities based on origin AND CSP enforced AND no privilege escalation via protocol AND same-origin policy maintained

**Fail Criteria**: Protocol grants additional capabilities OR CSP bypassed OR privilege escalation possible OR same-origin policy violated

**Evidence**: Capability restriction test results, CSP enforcement verification, permission escalation tests (negative), same-origin policy tests, iframe sandbox verification, Permissions Policy tests

**References**:

- Content Security Policy Level 3: https://www.w3.org/TR/CSP3/
- Permissions Policy: https://www.w3.org/TR/permissions-policy-1/
- Same-Origin Policy: https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy
- HTML Iframe Sandbox: https://html.spec.whatwg.org/multipage/iframe-embed-object.html#attr-iframe-sandbox
- Web API Permissions: https://www.w3.org/TR/permissions/
- Browser Security Model: https://www.chromium.org/Home/chromium-security/

### 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
2. Navigate to browser settings and locate protocol handler management section
3. Verify that all registered handlers are listed with scheme, origin, and URL template
4. Revoke a specific handler using the settings UI
5. Verify that the revoked handler no longer appears in the handler list
6. Test that clicking custom protocol links no longer invokes the revoked handler
7. Verify that unregisterProtocolHandler() API can programmatically revoke handlers
8. Test that only the registering origin can programmatically unregister its handlers
9. Verify that clearing site data revokes all handlers from that origin
10. Test that browser reset removes all custom protocol handlers
11. Settings UI provides clear handler management interface
12. All registered handlers are visible with complete details
13. Individual handlers can be selectively revoked
14. Revoked handlers stop functioning immediately
15. unregisterProtocolHandler() API works correctly
16. Cross-origin revocation is prevented (only origin can unregister its handlers)
17. Site data clearing includes handler revocation
18. Browser reset removes all handlers
19. Revocation events are logged for audit purposes

**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
2. Create an iframe at https://origin-b.example.com embedded in origin-a
3. Attempt to register a protocol handler from the iframe
4. Verify that the handler is attributed to origin-b (iframe origin), not origin-a (parent)
5. Test that handlers registered by origin-a cannot be unregistered by origin-b
6. Create a cross-origin link to custom protocol and verify handler invocation
7. Test that handler URL templates match the registering origin
8. Verify that postMessage cannot be used to bypass handler origin restrictions
9. Test that CORS policies don't affect protocol handler registration
10. Verify that subdomains are treated as separate origins for handler registration
11. Protocol handlers are attributed to the registering origin (not parent frame)
12. Cross-origin iframes register handlers under their own origin
13. Handlers can only be modified/removed by their registering origin
14. Handler URL templates are same-origin with registration origin
15. Cross-origin invocation works but respects security boundaries
16. postMessage doesn't bypass origin restrictions
17. CORS policies are orthogonal to handler registration
18. Subdomain isolation is enforced (sub.example.com != example.com)
19. Public suffix list respected for origin determination

**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
2. Install the PWA and verify that declared protocol handlers are registered
3. Test manifest protocol handlers with invalid URL templates and verify rejection
4. Verify that manifest handlers require user permission before activation
5. Test that manifest protocol handlers follow same security rules as registerProtocolHandler
6. Attempt to declare privileged schemes (http, https) in manifest and verify rejection
7. Test that manifest handlers are unregistered when app is uninstalled
8. Verify that manifest scope restrictions apply to protocol handlers
9. Test manifest handler updates when app manifest is updated
10. Verify that manifest validation errors are reported to developer console
11. protocol_handlers field in manifest is parsed and validated
12. Declared handlers are registered upon app installation with user permission
13. Invalid handlers in manifest are rejected with clear error messages
14. Same security validations apply as registerProtocolHandler API
15. Privileged schemes cannot be registered via manifest
16. Handlers are removed when app is uninstalled
17. Handlers point to URLs within app scope
18. Manifest updates trigger handler re-validation
19. Developer console shows validation errors
20. 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>
2. Verify that clicking the intent link triggers appropriate security checks
3. Test that malicious intent URLs cannot launch privileged system components
4. Attempt intent URL with dangerous actions (SEND_SMS, CALL, etc.) and verify blocking or permission prompts
5. Test intent URLs with arbitrary extras and verify sanitization
6. Verify that intent URLs cannot bypass app permissions
7. Test that browser validates package names in intent URLs
8. Attempt to use intent URLs to exfiltrate data and verify prevention
9. Test that intent URLs from iframes have additional restrictions
10. Verify that intent URL invocation is logged for security auditing
11. Intent URLs are parsed and validated before invocation
12. Privileged system components cannot be launched via intent URLs
13. Dangerous actions trigger user permission prompts or are blocked
14. Intent extras are sanitized to prevent injection attacks
15. Intent URLs cannot bypass app permission model
16. Package name validation prevents targeting of unintended apps
17. Data exfiltration via intent URLs is prevented
18. Iframe intent URLs have restricted capabilities
19. Intent invocations are logged with target package and action
20. 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
2. Create a link to a URL that matches a Universal Link pattern
3. Verify that the browser validates the apple-app-site-association file before allowing app opening
4. Test that HTTPS is required for Universal Links (HTTP domains should be rejected)
5. Verify that the association file is fetched over HTTPS with certificate validation
6. Test that only domains listed in the association file can trigger the app
7. Attempt to use a malicious association file and verify rejection
8. Test that users can choose to open in app or browser
9. Verify that Universal Link preferences persist across sessions
10. Test that Universal Links respect user privacy (no tracking via link interception)
11. apple-app-site-association file is validated before Universal Link activation
12. HTTPS required for both the association file and triggering URLs
13. Certificate validation enforced when fetching association file
14. Domain validation prevents unauthorized app openings
15. Malformed or malicious association files are rejected
16. User choice between app and browser is preserved
17. User preferences for Universal Links persist
18. No user tracking via Universal Link interception
19. Association file caching follows secure practices
20. 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
2. Verify that the browser validates the deep link format before allowing navigation
3. Test that parameters in deep links are sanitized to prevent injection
4. Attempt to use a deep link with XSS payload and verify sanitization
5. Test that deep links to unverified apps trigger user confirmation
6. Verify that deep link domains are validated against app claims (App Links/Universal Links)
7. Test that deep links cannot bypass app sandbox or permissions
8. Attempt to use deep links for phishing (misleading app names) and verify warnings
9. Verify that HTTPS fallback URLs are used when app is not installed
10. Test that deep link invocation is logged for security monitoring
11. Deep link format and structure validated before processing
12. Parameters in deep links are URL-encoded and sanitized
13. XSS payloads in deep links are neutralized
14. User confirmation required for unverified deep links
15. Domain validation confirms app ownership of deep link domains
16. Deep links cannot escalate privileges or bypass sandbox
17. Phishing detection identifies misleading app names or domains
18. HTTPS fallback works when target app not installed
19. Deep link invocations logged with destination and parameters
20. 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**: