EN-304-617_v0.0.6.md

   - Confirm no scheduled background checks
   - Verify no update checks on browser startup
4. Test that updates are not downloaded automatically: → Verify that update configuration cannot be bypassed by browser or OS
   - Available updates not pre-downloaded
   - No background downloads
   - Network traffic shows no update downloads
5. Verify that updates are not installed without user action: → Test that enterprise policies cannot override manual-only setting
   - No automatic installation during idle time
   - No installation on browser restart
   - No forced installation for critical updates

**Pass Criteria**: No automatic update checks AND no automatic downloads AND no automatic installation AND all actions require explicit user initiation AND applies to all update types AND cannot be bypassed

**Fail Criteria**: Any automatic update behavior OR checks without user action OR downloads without initiation OR installation without explicit action OR critical updates bypass manual mode

**Evidence**: Network traffic analysis showing no automatic update activity, manual workflow verification for all update steps, critical update handling in manual mode, policy override testing, mode persistence across updates

**References**:

- Change Control Procedures: https://www.cisecurity.org/controls/v8/
- User Autonomy Principles: https://www.w3.org/TR/design-principles/#user-control

### Assessment: UPD-REQ-38 (Update changelog and security impact display)

**Reference**: UPD-3-REQ-15 - Browser shall display update changelog and security impact

**Given**: A conformant browser with UPD-3 capability with updates available

**Task**: Verify that the browser provides comprehensive changelog and security impact information for updates, enabling informed manual update decisions by clearly documenting what changes each update introduces, what vulnerabilities are addressed, and what security improvements are included, supporting users who need detailed information before authorizing system changes.

**Verification**:

1. Trigger availability of update with mixed changes (security fixes, features, bug fixes) → Verify that changelog includes version numbers and dates
2. Access update details or changelog in browser UI → Test that changelog is accessible before update installation:
   - Available in update notification
   - Viewable in update check results
   - Accessible from browser help/about page
3. Verify that changelog is comprehensive and well-organized: → Verify that changelog links to detailed documentation if available
   - Grouped by category (security, features, bug fixes, performance)
   - Chronological or logical ordering
   - Clear, understandable language
4. Test that security section is prominent and detailed: → Test that changelog format is readable (not raw git commits)
   - List of CVEs addressed
   - Vulnerability descriptions
   - Severity ratings
   - Attack scenarios prevented
   - Credit to security researchers if applicable
5. Verify that feature changes are clearly documented: → Verify that security impact is emphasized visually in changelog
   - New capabilities added
   - Changed behaviors
   - Deprecated features
6. Test that bug fixes are listed with impact descriptions → Test that changelog is available in multiple languages if browser is localized

**Pass Criteria**: Comprehensive changelog provided AND security impact prominently detailed AND CVE information included AND accessible before installation AND well-organized and readable AND emphasized security sections

**Fail Criteria**: No changelog available OR minimal security details OR missing CVE information OR only accessible after installation OR poorly formatted OR security not emphasized

**Evidence**: Changelog screenshots showing all sections, security detail depth analysis, CVE reference verification, accessibility before installation, formatting quality assessment, localization testing

**References**:

- Security Disclosure Best Practices: https://www.cisa.gov/coordinated-vulnerability-disclosure-process
- Software Release Notes Standards: https://docs.gitlab.com/ee/development/changelog.html

## 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() → Verify that successful registrations require user permission or confirmation
2. Test registration with a valid web+custom scheme (e.g., web+music, web+calendar) → Valid web+custom scheme registrations are accepted after validation
3. Attempt to register a handler for a dangerous built-in scheme (http, https, file, javascript) → Built-in privileged schemes (http, https, file, javascript, data, blob) cannot be registered
4. Verify that the browser rejects registration attempts for privileged schemes → Only HTTPS origins can register protocol handlers
5. Test registration with malformed URL templates (missing %s placeholder, invalid URL format) → URL templates shall include %s placeholder and be valid URLs
6. Verify that only HTTPS origins can register protocol handlers (HTTP origins should be rejected) → Malformed registrations are rejected with appropriate error messages
7. Test that the handler URL template is properly validated for XSS vectors → XSS vectors in handler URLs are sanitized or rejected
8. Attempt to register handlers with data: or blob: URLs and verify rejection → Registration from iframes follows same-origin policy
9. Test registration from an iframe and verify same-origin policy enforcement → 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 → Verify that permission prompts cannot be spoofed or triggered without user action
2. Verify that registration triggers a permission prompt to the user → Protocol handler registration shows clear permission prompt
3. Test that the permission prompt clearly identifies the scheme and handling origin → Permission prompt identifies the custom scheme and requesting origin
4. Click a link with the custom protocol (web+test:example) and verify activation prompt → Activation of custom protocol shows confirmation before launching handler
5. Test that users can allow, deny, or remember the choice for the handler → Users can allow, deny, or set persistent preferences
6. Verify that denying handler activation falls back to default behavior or shows error → Permission choices persist across sessions
7. Test that remembered choices persist across browser sessions → Settings provide UI to view and revoke handler permissions
8. Navigate to browser settings and verify users can revoke protocol handler permissions → Each origin requires independent user consent
9. Test that each origin requires separate consent (cross-origin isolation) → Permission prompts are genuine browser UI (not web content)

**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 → Verify that only approved safelist schemes bypass the web+ prefix requirement
2. Attempt to register a handler for web+validname and verify acceptance → Custom schemes use web+ prefix unless on explicit safelist
3. Test registration with schemes that don't follow web+ prefix convention → Safelisted schemes (mailto, tel, sms) can be registered without web+ prefix
4. Verify that safelisted schemes (mailto, tel, sms) can be registered with special handling → Dangerous schemes (javascript, data, vbscript, shell) are blocklisted
5. Attempt to register handlers for blocklisted dangerous schemes (vbscript, shell, etc.) → Scheme names follow DNS label conventions (alphanumeric, hyphens, no spaces)
6. Test enterprise policy controls for custom protocol allowlists → Scheme matching is case-insensitive
7. Verify that scheme names follow DNS label conventions (alphanumeric, hyphens) → Length limits prevent excessively long scheme names (e.g., 64 character limit)
8. Test that scheme names are case-insensitive during registration and matching → Enterprise policies can extend or restrict allowlists
9. Attempt registration with excessively long scheme names and verify length limits → 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 → Verify that resetting browser settings revokes all custom protocol handlers
2. Attempt to register a competing handler for web+test from https://malicious.example.com → Multiple handlers for same scheme trigger user choice rather than silent override
3. Verify that the browser either prevents the override or prompts user for choice → User can see and select from all registered handlers for a scheme
4. Test that the most recently used or user-preferred handler takes precedence → Built-in handlers maintain priority or require explicit user override
5. Verify that built-in handlers (mailto, tel) cannot be completely overridden without permission → Handler selection UI clearly displays origin and scheme information
6. Test that unregistering a handler doesn't automatically activate an attacker's handler → Private/incognito mode handlers are session-only
7. Attempt to register a handler that impersonates a well-known service → Browser reset revokes all custom handlers
8. Verify that handler selection UI clearly shows the origin of each handler → No automatic activation of handlers after unregistration
9. Test that handlers registered in private/incognito mode don't persist → 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 → Verify that Unicode characters are properly normalized and encoded
2. Create a test link with XSS payload: <a href="web+test:<script>alert(1)</script>">Click</a> → All special characters in protocol URLs are properly URL-encoded
3. Click the link and verify that the script payload is URL-encoded when passed to handler → Script tags and JavaScript code are encoded, not executed
4. Test with SQL injection characters in protocol URL and verify proper encoding → SQL injection characters are escaped/encoded
5. Attempt protocol URL with newline/CRLF characters and verify sanitization → CRLF and newline characters are stripped or encoded
6. Test with null bytes and other control characters in protocol URL → Null bytes and control characters are removed or encoded
7. Verify that the %s placeholder is properly substituted with encoded parameter → Parameter substitution uses safe encoding (encodeURIComponent or equivalent)
8. Test with extremely long protocol parameters and verify truncation or rejection → Extremely long parameters are truncated or rejected
9. Attempt to include additional parameters beyond the defined template → Template structure is enforced (no parameter injection)

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

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

**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 → Verify that downgrade attempts are logged for security monitoring
2. Attempt to register a handler for the same scheme from an HTTP origin: http://insecure.example.com/handler?url=%s → HTTP origins cannot register handlers if HTTPS origin has already registered
3. Verify that the HTTP handler registration is rejected or requires explicit user confirmation → Handler URL templates are HTTPS for security-sensitive schemes
4. Test that handler URL templates are HTTPS if registered from HTTPS origins → Existing HTTPS handlers cannot be downgraded to HTTP
5. Attempt to update an existing HTTPS handler to use an HTTP URL template → HSTS policies prevent HTTP handler registration for HSTS hosts
6. Verify that downgrades are prevented or trigger security warnings → Mixed content blocking applies to handler URLs
7. Test that HSTS policies affect protocol handler registration → Upgrade-insecure-requests policy upgrades handler URLs when applicable
8. Verify that mixed content policies apply to handler URL templates → Downgrade attempts generate security warnings or errors
9. Test that handler invocation follows upgrade-insecure-requests policy → 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 → Export protocol handler logs and verify they are in structured format
2. Register a custom protocol handler and verify the event is logged → All handler lifecycle events are logged (registration, invocation, modification, removal)
3. Check that the log entry includes: timestamp, origin, scheme, handler URL template, user decision → Log entries include complete metadata: timestamp, origin, scheme, URL template, user action
4. Invoke a registered protocol handler and verify the invocation is logged → Failed registration attempts are logged with error details
5. Modify an existing handler (if supported) and verify the change is logged → External handler invocations are logged separately from web handlers
6. Unregister a protocol handler and verify the removal is logged → Logs distinguish between user-initiated and script-initiated events
7. Test that failed registration attempts are logged with error reasons → Log format is structured (JSON or similar) for analysis
8. Verify that external protocol handler launches are logged → Logs can be exported for security monitoring
9. Test that logs include sufficient context for security analysis → Log retention follows security event retention policies

**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/27001

### 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') → Verify that web+ handlers work correctly across different browser contexts
2. Verify that the registration succeeds for properly formatted web+ schemes → web+ prefix is recognized and properly handled
3. Test that web+ schemes are case-insensitive (web+music equals WEB+MUSIC) → Schemes are case-insensitive during registration and matching
4. Create a link with web+music:track123 and verify it invokes the handler → web+ shall be followed by valid scheme name (alphanumeric, hyphens)
5. Test that schemes without web+ prefix (except safelisted) are rejected → web+ alone without suffix is invalid
6. Verify that web+ is followed by at least one alphanumeric character → Scheme names follow DNS label conventions
7. Test that web+ alone (without suffix) is rejected → Multiple web+ schemes can be registered from same origin
8. Verify that web+ schemes follow DNS label rules (no spaces, special chars limited) → Links with web+ schemes correctly invoke registered handlers
9. Test registration of multiple different web+ schemes from same origin → Error messages guide developers on correct web+ format

**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 → Verify that exported browser profiles include protocol handler settings
2. Close the browser and reopen it → Handler registrations persist across normal browser restarts
3. Verify that the protocol handler registration persists and is still functional → Registered handlers remain functional after session closure
4. Click a custom protocol link and verify the handler still works after restart → Private/incognito mode handlers are session-only (do not persist)
5. Register a protocol handler in private/incognito mode → Private mode handlers do not leak to normal mode or vice versa
6. Verify that the handler works during the private session → Clearing browsing data removes handler registrations
7. Close the private/incognito window and open a new one → Handler persistence respects user privacy preferences
8. Verify that the handler registered in private mode does NOT persist → Profile export/import includes handler configurations
9. Test that clearing browsing data removes protocol handler registrations → 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') → Test that schemes with different Unicode normalization forms are treated as different
2. Verify that the browser normalizes Unicode in scheme names or rejects homoglyphs → Scheme names are restricted to ASCII alphanumeric characters and hyphens
3. Test registration with mixed scripts in scheme names (Latin + Cyrillic) → Unicode homoglyphs in scheme names are rejected
4. Attempt to register schemes that visually resemble built-in schemes (e.g., web+https with Cyrillic characters) → Mixed script scheme names are not allowed
5. Verify that scheme names are restricted to ASCII alphanumeric and hyphens → Schemes visually similar to built-in schemes are flagged or rejected
6. Test that UI clearly displays scheme names without ambiguity → UI displays scheme names in monospace or disambiguating font
7. Verify that punycode or IDN homographs are not allowed in scheme names → Punycode/IDN encoding not allowed in scheme names
8. Test registration of schemes with confusable characters (0 vs O, 1 vs l) → Confusable character combinations are prevented or warned
9. Verify that handler selection UI disambiguates similar schemes → Different Unicode normalizations are properly handled

**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 shall 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 → Verify that handlers respect Permissions Policy (formerly Feature Policy)
2. Verify that the handler page inherits security context from its origin, not protocol URL → Handler security context is based on handler URL origin, not protocol
3. Test that handler cannot access privileged APIs without proper permissions → Privileged APIs require explicit permissions (not granted by handler status)
4. Verify that protocol parameters don't grant additional capabilities → CSP of handler origin is enforced
5. Test that handlers follow Content Security Policy of their origin → Protocol parameters cannot inject capabilities or bypass security
6. Attempt to access local files from handler and verify blocking → Local file access is blocked unless explicitly permitted
7. Test that handlers cannot bypass same-origin policy using protocol parameters → Same-origin policy is enforced for handlers
8. Verify that handlers in iframes have restricted capabilities → Iframe handlers have sandboxed capabilities
9. Test that handler invocation doesn't grant automatic permission escalation → No automatic permission grants upon handler invocation

**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 → 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/