EN-304-617.md.backup

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 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
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**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

### 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:
   - 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
3. Test that blocked navigation displays clear error message
4. Verify that error message does not suggest workarounds
5. Test that links with custom protocols do not activate handlers
6. Verify that registerProtocolHandler() API is not available
7. Test that WebSocket connections are blocked (ws:// and wss://)
8. Verify that WebRTC connections cannot be established
9. Test that FTP protocol is not supported
10. Verify that data: URIs are blocked or heavily restricted
11. Test that no custom protocol registration UI exists
12. 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
2. Verify that API call is rejected or API is undefined
3. Test registration attempts for various schemes:
   - web+custom schemes
   - mailto: handler override
   - Custom application protocols
4. Verify that all registration attempts fail
5. Test that no protocol handler registration UI is available in settings
6. Verify that manifest-based handler registration is not supported
7. Test that browser extensions cannot register protocol handlers
8. Verify that enterprise policies cannot enable protocol registration
9. Test that command-line flags cannot bypass restriction
10. Verify that error messages clearly indicate feature is disabled
11. Test that web applications cannot detect registered handlers
12. 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:
   - In address bar navigation
   - In links (<a href="javascript:...">)
   - In iframe src attributes
   - In form action attributes
2. Verify that data: URLs are blocked:
   - In navigation
   - In iframe src
   - In image src
   - In script src
3. Test that file: URLs are blocked:
   - In navigation
   - In resource loading (images, scripts, styles)
   - In iframe src
4. Verify that blob: URLs are blocked or restricted
5. Test that about: URLs are limited to safe pages only
6. Verify that view-source: scheme is blocked
7. Test that custom app schemes (mailto:, tel:, sms:) are blocked
8. Verify that blocked schemes return consistent error messages
9. Test that scheme blocking applies to all contexts (main frame, iframes, workers)
10. Verify that CSP cannot override scheme blocking
11. Test that redirects to non-standard schemes are blocked
12. 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
2. Verify that attempting to call the API produces clear error
3. Test that navigator.isProtocolHandlerRegistered() is also unavailable
4. Verify that navigator.unregisterProtocolHandler() is unavailable
5. Test that Feature Policy cannot re-enable protocol handler API
6. Verify that no polyfills or fallback mechanisms exist
7. Test that Content-Security-Policy cannot enable the API
8. Verify that browser feature detection shows API as unavailable
9. Test that JavaScript cannot detect if API was previously available
10. Verify that web platform tests for protocol handlers are skipped
11. Test that browser documentation indicates API is not supported
12. Verify that removal is consistent across all browsing contexts (windows, workers, iframes)

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

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

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

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

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

**References**:

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

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

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

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

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

**Verification**:

1. Register multiple protocol handlers for different schemes
2. Access browser settings to find protocol handler management
3. Verify that handler list is easily accessible: