EN-304-617.md

**Task**: Verify that updates are applied automatically without any user intervention or ability to postpone, ensuring that security patches are deployed immediately to minimize the window of vulnerability exploitation, protecting users who might otherwise delay critical updates, while accepting the trade-off of reduced user control in exchange for maximum security posture.

**Verification**:

1. Configure browser in UPD-0 mode with forced automatic updates → Test that updates install in background without interrupting user workflows
2. Trigger an update availability (use test update server if available) → Verify that only browser restart (if needed) may be delayed to safe moment
3. Verify that update is downloaded automatically without user prompt → Test that critical updates force installation even if browser is in use
4. Verify that update is applied immediately without user confirmation → Verify that users cannot disable automatic update mechanism
5. Test that no UI options exist to postpone or decline update → Test that settings UI shows no postponement options
6. Verify that update application proceeds even during active browsing sessions → Verify that update process cannot be interrupted or canceled by user

**Pass Criteria**: Updates download automatically AND install without user confirmation AND no postponement options available AND settings prevent disabling automatic updates

**Fail Criteria**: Updates require user confirmation OR postponement is possible OR automatic updates can be disabled OR update process can be interrupted

**Evidence**: Update installation logs showing automatic application, UI screenshots showing no postponement options, settings verification showing forced updates, test scenarios demonstrating immediate installation

**References**:

- NIST Secure Software Development: https://csrc.nist.gov/projects/ssdf
- Automatic Security Updates Best Practices: https://www.us-cert.gov/ncas/tips/ST04-006

### Assessment: UPD-REQ-25 (Automatic browser restart after critical updates)

**Reference**: UPD-0-REQ-24 - Browser shall restart automatically after critical updates when safe

**Given**: A conformant browser with UPD-0 capability after critical update installation

**Task**: Verify that the browser automatically restarts after critical security updates are installed, but only when safe to do so (when user is not in middle of sensitive tasks), ensuring updates become effective immediately while minimizing disruption, balancing security urgency against user experience by detecting safe restart windows and providing brief warnings.

**Verification**:

1. Install critical security update that requires browser restart → Test that brief warning is displayed before automatic restart (e.g., 60 seconds)
2. Verify that browser detects restart requirement → Verify that warning cannot be dismissed or canceled for critical updates
3. Test browser behavior in various states: → Test that browser session state is preserved across restart
   - Idle state (no active tabs or forms)
   - Active browsing (tabs open but no form input)
   - Form input in progress (unsaved data)
   - File downloads in progress
   - Media playback active
4. Verify that browser waits for safe moment to restart in each scenario → Verify that tabs, windows, and browsing history are restored
5. Test that unsaved form data prevents immediate restart → Test that restart occurs automatically if browser remains idle after update
6. Verify that active downloads are protected from restart → Verify that maximum delay before forced restart is reasonable (e.g., 8 hours)

**Pass Criteria**: Browser restarts automatically after critical updates AND waits for safe moments AND preserves user session AND provides brief warning AND forced restart occurs if delayed too long

**Fail Criteria**: No automatic restart OR unsafe restart timing OR session not preserved OR no warning provided OR indefinite delay possible

**Evidence**: Restart behavior logs, timing analysis across different browser states, session preservation verification, warning dialog screenshots, maximum delay testing

**References**:

- User Experience in Security Updates: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/mathur
- Browser Session Management: https://developer.mozilla.org/en-US/docs/Web/API/Window/sessionStorage

### Assessment: UPD-REQ-26 (Update postponement with time limits)

**Reference**: UPD-1-REQ-23 - Users shall be able to postpone non-critical updates for limited time (max 7 days)

**Given**: A conformant browser with UPD-1 capability (automatic with postponement)

**Task**: Verify that users can postpone non-critical updates for a limited time (maximum 7 days), providing flexibility for users to control update timing while ensuring that security patches are not delayed indefinitely, balancing user autonomy with security needs by enforcing reasonable time limits after which updates shall be applied.

**Verification**:

1. Trigger availability of non-critical update → Test that postponed update becomes mandatory when deadline approaches
2. Verify that update notification provides postponement option → Verify that warning increases in urgency as deadline nears
3. Test postponing update and verify it is not installed immediately → Test that update is automatically installed when maximum postponement expires
4. Verify that postponement options offer reasonable durations (1 day, 3 days, 7 days) → Verify that users cannot extend postponement beyond maximum limit
5. Test selecting maximum postponement period (7 days) → Test that multiple postponements don't extend total delay beyond limit
6. Verify that browser tracks postponement deadline → Verify that update notification persists until user takes action

**Pass Criteria**: Non-critical updates can be postponed AND maximum postponement is 7 days AND forced installation after deadline AND multiple postponements don't exceed limit AND critical updates have stricter limits

**Fail Criteria**: Indefinite postponement possible OR maximum exceeds 7 days OR no forced installation after deadline OR deadline can be extended indefinitely

**Evidence**: Postponement UI screenshots, deadline tracking verification, forced installation logs after expiry, multiple postponement tests, critical vs non-critical update handling comparison

**References**:

- Update Management Best Practices: https://www.cisecurity.org/insights/white-papers/software-update-and-patch-management-best-practices
- User Control in Security Updates: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/mathur

### Assessment: UPD-REQ-27 (Critical update postponement restrictions)

**Reference**: UPD-1-REQ-24 - Critical security updates shall not be postponable beyond 24 hours

**Given**: A conformant browser with UPD-1 capability with critical security update available

**Task**: Verify that critical security updates addressing actively exploited vulnerabilities or high-severity issues cannot be postponed beyond 24 hours, ensuring that urgent patches are deployed rapidly while still providing minimal user control, recognizing that critical vulnerabilities represent immediate threats requiring prompt mitigation despite user preference for delayed updates.

**Verification**:

1. Trigger availability of critical security update (e.g., zero-day patch) → Test that warning messages escalate as postponement deadline approaches
2. Verify that update is clearly marked as "Critical" or "Security Update" → Verify that browser displays prominent warning if critical update is postponed
3. Test that postponement options are limited for critical updates → Test that update is automatically installed when 24-hour deadline expires
4. Verify that maximum postponement for critical update is 24 hours or less → Verify that users cannot extend critical update postponement
5. Test that postponement UI emphasizes urgency and security risk → Test that "remind me later" options are limited (1 hour, 4 hours, 24 hours max)
6. Verify that security rationale is provided explaining criticality → Verify that background browser processes trigger update even if UI postponed

**Pass Criteria**: Critical updates identified separately AND maximum postponement is 24 hours AND forced installation after deadline AND prominent warnings displayed AND no extension possible

**Fail Criteria**: Critical updates can be postponed beyond 24 hours OR no distinction from non-critical OR insufficient warnings OR deadline can be extended OR no forced installation

**Evidence**: Critical update UI showing restricted postponement, urgency warnings, 24-hour deadline enforcement logs, automatic installation verification, security rationale display

**References**:

- CISA Known Exploited Vulnerabilities: https://www.cisa.gov/known-exploited-vulnerabilities-catalog
- Rapid Security Update Deployment: https://www.nist.gov/publications/guide-enterprise-patch-management-technologies

### Assessment: UPD-REQ-28 (Update severity indication)

**Reference**: UPD-1-REQ-25 - Browser shall notify users of pending updates with severity indication

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

**Task**: Verify that update notifications clearly indicate update severity (critical, high, medium, low) to help users understand urgency and make informed decisions about update timing, providing transparency about security impact and enabling users to prioritize critical patches while potentially deferring less urgent updates, supporting risk-aware update management.

**Verification**:

1. Trigger updates of various severity levels:
   - Critical security fix for actively exploited vulnerability
   - High severity security patch
   - Medium priority bug fixes and security improvements
   - Low priority feature updates
2. Verify that update notifications display severity level prominently
3. Test that severity is indicated through multiple cues:
   - Text labels ("Critical", "High", "Medium", "Low")
   - Color coding (red for critical, yellow for medium, etc.)
   - Icon indicators (warning symbols, shields)
   - Urgency language in notification text
4. Verify that severity explanation is provided when requested
5. Test that critical severity triggers most prominent notification
6. Verify that postponement options vary based on severity
7. Test that update details explain security impact:
   - CVE identifiers for security issues
   - Brief description of vulnerability addressed
   - Potential attack scenarios prevented
8. Verify that severity assessment is based on objective criteria
9. Test that multiple updates are ordered by severity in UI
10. Verify that severity indication is consistent across all notification channels

**Pass Criteria**: Severity clearly indicated through multiple UI cues AND explanation provided AND varies postponement options AND includes security impact details AND consistent across notifications

**Fail Criteria**: No severity indication OR unclear severity communication OR severity doesn't affect options OR no security impact details OR inconsistent indication

**Evidence**: Notification screenshots for each severity level, severity explanation text, postponement option variations, security impact descriptions, CVE references in updates

**References**:

- CVSS (Common Vulnerability Scoring System): https://www.first.org/cvss/
- Security Update Communication Best Practices: https://www.cisa.gov/coordinated-vulnerability-disclosure-process

### Assessment: UPD-REQ-29 (Automatic updates disabled by default)

**Reference**: UPD-2-REQ-14 - Automatic updates shall be disabled by default

**Given**: A conformant browser with UPD-2 capability (optional automatic updates)

**Task**: Verify that automatic updates are disabled by default in UPD-2 mode, requiring explicit user opt-in before automated update installation occurs, respecting user autonomy and system control in environments where automatic changes may conflict with testing requirements, system stability needs, or bandwidth constraints, while clearly communicating the security risks of manual update management.

**Verification**:

1. Perform fresh browser installation in UPD-2 mode → Verify that settings clearly show automatic updates are disabled
2. Verify that automatic updates are disabled by default on first run → Test that manual update check is available
3. Check browser settings to confirm automatic update state → Verify that enabling automatic updates requires explicit user opt-in:
   - Navigate to settings
   - Locate automatic update toggle
   - Click to enable with confirmation
4. Trigger update availability with automatic updates disabled → Test that opt-in decision is persistent across browser restarts
5. Verify that update is not downloaded or installed automatically → Verify that first-run wizard or setup offers automatic update option with clear explanation
6. Test that update notification is displayed but requires user action → Test that security implications of disabled automatic updates are explained

**Pass Criteria**: Automatic updates disabled by default AND manual action required for updates AND explicit opt-in to enable automatic updates AND security implications explained AND opt-in persists

**Fail Criteria**: Automatic updates enabled by default OR automatic installation occurs without opt-in OR no clear opt-in mechanism OR no security explanation

**Evidence**: Fresh installation default state verification, settings screenshots showing disabled state, manual update workflow, opt-in process documentation, security warning examples

**References**:

- User Autonomy in Software Updates: https://www.w3.org/TR/design-principles/#user-control
- Update Policy Best Practices: https://www.cisecurity.org/insights/blog/patch-management-best-practices

### Assessment: UPD-REQ-30 (Automatic update recommendations)

**Reference**: UPD-2-REQ-15 - Browser shall prominently recommend enabling automatic updates

**Given**: A conformant browser with UPD-2 capability with automatic updates disabled

**Task**: Verify that the browser prominently recommends enabling automatic security updates, educating users about security benefits while respecting their choice to manage updates manually, using clear messaging that explains risks of manual update management without employing dark patterns or coercive tactics, supporting informed decision-making about update policies.

**Verification**:

1. Access browser with automatic updates disabled
2. Verify that recommendation to enable automatic updates is displayed:
   - During initial browser setup/first run
   - In browser settings near update controls
   - In security or privacy dashboard
   - Periodically as gentle reminder (not nagging)
3. Test that recommendation clearly explains benefits:
   - Automatic security patches protect against threats
   - Reduced window of vulnerability exploitation
   - No need to remember to check for updates
   - Background installation minimizes disruption
4. Verify that recommendation is prominent but not intrusive:
   - Visible and easy to find
   - Not blocking workflow or annoying
   - Can be acknowledged/dismissed
   - Does not reappear constantly (dark pattern)
5. Test that enabling automatic updates from recommendation is easy (single click)
6. Verify that recommendation respects user's choice to decline:
   - Clear "No thanks" or "Keep manual" option
   - Choice is remembered
   - Not repeatedly prompted in same session
7. Test that recommendation is balanced and informative, not fear-mongering
8. Verify that recommendation links to detailed information if user wants to learn more

**Pass Criteria**: Recommendation is prominent and visible AND clearly explains benefits AND easy to enable from recommendation AND respects user's choice to decline AND not intrusive or nagging

**Fail Criteria**: No recommendation shown OR unclear benefits OR difficult to enable OR forced enablement OR dark patterns used OR constantly nagging user

**Evidence**: Recommendation display locations and frequency, message content analysis, enablement workflow, dismissal behavior, user choice respect verification

**References**:

- Ethical Design Principles: https://www.w3.org/TR/design-principles/
- Dark Pattern Prevention: https://www.deceptive.design/
- Security Awareness Communication: https://www.nist.gov/itl/applied-cybersecurity/nice/resources/online-learning-content

### Assessment: UPD-REQ-31 (Security warnings for available updates)

**Reference**: UPD-2-REQ-16 - Browser shall display security warnings when updates are available

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

**Task**: Verify that the browser displays clear security warnings when security updates are available but not yet installed, informing users about increased risk from running outdated versions with known vulnerabilities, providing actionable information to encourage timely manual installation without resorting to scare tactics, supporting security awareness for users managing updates manually.

**Verification**:

1. Trigger availability of security update (patch for known vulnerability)
2. Verify that security warning is displayed prominently:
   - Banner or notification in browser UI
   - Icon or badge indicating security risk
   - Entry in security dashboard or settings
3. Test that warning clearly communicates security risk:
   - Updates address security vulnerabilities
   - Outdated version may be vulnerable to attacks
   - Recommendation to install updates promptly
   - Severity indicator if critical update
4. Verify that warning provides direct link to update installation
5. Test that warning persists until update is installed
6. Verify that warning visibility increases with time since update available:
   - Subtle notification initially
   - More prominent after several days
   - Prominent warning after one week
7. Test that warning is informative but not alarmist:
   - Factual language about security risks
   - No fear-mongering or exaggeration
   - Clear call to action
8. Verify that warning includes timestamp (update available since X days)
9. Test that multiple security updates aggregate into single clear warning
10. Verify that warning disappears immediately after update installation

**Pass Criteria**: Security warnings displayed prominently AND clearly communicate risk AND provide direct update link AND escalate with time AND informative without fear-mongering AND disappear after installation

**Fail Criteria**: No security warnings OR unclear risk communication OR no update link OR static visibility OR alarmist language OR warnings persist after update

**Evidence**: Security warning screenshots, warning visibility escalation timeline, language tone analysis, update link functionality, persistence behavior verification

**References**:

- Security Warning Design: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/felt
- Effective Security Communication: https://www.usenix.org/conference/soups2013/proceedings/presentation/akhawe

### Assessment: UPD-REQ-32 (Easy update check and install mechanism)

**Reference**: UPD-2-REQ-17 - Browser shall provide easy mechanism to check for and install updates

**Given**: A conformant browser with UPD-2 capability (optional automatic updates)

**Task**: Verify that users can easily check for available updates and install them manually through intuitive UI controls, ensuring that manual update management is practical and convenient for users who prefer explicit control, providing clear workflow from update check to installation without requiring technical knowledge or complex procedures.

**Verification**:

1. Access browser settings or help menu → Test that update installation is reliable and completes successfully
2. Verify that "Check for Updates" option is easily findable: → Verify that any restart requirement is clearly communicated
   - Located in expected place (About, Settings, Help menu)
   - Clear, understandable label
   - Accessible within 2-3 clicks from main UI
3. Test manually triggering update check → Test that update check and install work from multiple entry points
4. Verify that update check provides clear feedback: → Verify that update changelog or release notes are accessible
   - Checking animation or progress indicator
   - Clear result message (up-to-date or updates available)
   - Details about available updates
5. Test that update installation is straightforward: → Test that errors during update are handled gracefully with clear messages
   - Single "Install Update" or "Update Now" button
   - Clear indication of what will happen
   - Progress indicator during download and installation
6. Verify that update process doesn't require advanced technical knowledge → Verify that users can cancel update download if needed (before installation)

**Pass Criteria**: Update check easily accessible AND clear feedback provided AND simple installation process AND reliable completion AND restart requirements communicated AND multiple access points AND release notes available

**Fail Criteria**: Update check hard to find OR no feedback OR complex installation OR frequent failures OR unclear requirements OR only one access point OR no release information

**Evidence**: UI navigation path to update check, update check workflow screenshots, installation process recordings, error handling examples, accessibility from multiple locations

**References**:

- Usability in Security Features: https://www.usenix.org/conference/soups2006/proceedings
- User-Centered Design for Updates: https://www.w3.org/TR/design-principles/#user-control

### Assessment: UPD-REQ-33 (Full user control over update timing)

**Reference**: UPD-2-REQ-18 - Users shall have full control over update timing and installation

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

**Task**: Verify that users have complete control over when and whether to install updates, enabling users to manage update timing according to their needs, workflows, and system requirements, respecting user autonomy fully while acknowledging the security trade-offs, ensuring that users who choose manual update management have necessary tools and information to do so effectively.

**Verification**:

1. Trigger availability of various updates (critical and non-critical) → Test that users can selectively install some updates while skipping others
2. Verify that users can choose whether to install each update → Verify that skipping updates doesn't prevent checking for newer updates
3. Test that users can defer updates indefinitely: → Test that users can postpone updates without time limits
   - No forced installation deadlines
   - No automatic installation after time period
   - User always has option to decline
4. Verify that update notifications can be dismissed → Verify that even critical security updates can be declined by user
5. Test that dismissed updates don't automatically reinstall → Test that users understand consequences of their choices through clear warnings
6. Verify that users can choose specific installation timing: → Verify that update preferences are respected across browser sessions
   - Install now
   - Install on next restart
   - Install later (no deadline)
   - Don't install (skip update)

**Pass Criteria**: Users can defer updates indefinitely AND can decline any update AND can choose specific installation timing AND selective installation possible AND preferences persist AND consequences clearly communicated

**Fail Criteria**: Forced installation occurs OR time limits enforced OR cannot decline updates OR no selective installation OR preferences not persistent OR inadequate consequence communication

**Evidence**: Update control UI showing all options, indefinite deferral testing, selective installation demonstrations, critical update decline verification, preference persistence tests, warning message examples

**References**:

- User Autonomy in Software Design: https://www.w3.org/TR/design-principles/#user-control
- Update Management for Advanced Users: https://www.cisecurity.org/insights/white-papers/software-update-and-patch-management-best-practices

### Assessment: UPD-REQ-34 (Manual update check mechanism)

**Reference**: UPD-3-REQ-11 - Browser shall provide manual update check mechanism

**Given**: A conformant browser with UPD-3 capability (manual updates only)

**Task**: Verify that the browser provides a reliable manual update check mechanism allowing users to check for available updates on demand, ensuring that users who have disabled all automatic update behaviors can still maintain security through manual update management, providing necessary tools for deliberate update workflows in controlled environments.

**Verification**:

1. Verify that automatic update checks are fully disabled in UPD-3 mode → Verify that update check can be performed multiple times without restriction
2. Access manual update check mechanism in browser UI → Test that check does not automatically download or install anything
3. Verify that "Check for Updates" is easily accessible: → Verify that check completes in reasonable time (< 10 seconds typically)
   - Available in About page, Settings, or Help menu
   - Clear labeling and prominent placement
   - Functional even with all automatic features disabled
4. Test triggering manual update check → Test that check works across different network conditions
5. Verify that check contacts update servers and retrieves current information: → Verify that check failure doesn't prevent retrying
   - Network request to update endpoint
   - Retrieval of latest version metadata
   - Comparison with current browser version
6. Test that check provides clear results: → Test that update metadata includes security information and changelog
   - "You are up to date" if current
   - "Update available" with version details if outdated
   - Error message if check fails (network issue, server unavailable)

**Pass Criteria**: Manual check mechanism easily accessible AND reliably contacts update servers AND provides clear results AND doesn't auto-download/install AND works in various network conditions AND includes security information

**Fail Criteria**: No manual check OR difficult to access OR unreliable OR automatically downloads/installs OR frequent failures OR no security information

**Evidence**: Update check UI location and access path, network traffic during check, result message examples for various scenarios, reliability testing across networks, metadata content analysis

**References**:

- Manual Update Management: https://www.cisecurity.org/controls/v8/
- User-Initiated Security Updates: https://www.nist.gov/publications/guide-enterprise-patch-management-technologies

### Assessment: UPD-REQ-35 (Outdated version security warnings)

**Reference**: UPD-3-REQ-12 - Browser shall display security warnings for outdated versions

**Given**: A conformant browser with UPD-3 capability running outdated version

**Task**: Verify that the browser displays persistent security warnings when running significantly outdated versions with known vulnerabilities, informing users about security risks of delayed updates and encouraging timely manual installation, balancing respect for user autonomy with responsibility to communicate security status, especially when manual update management results in vulnerable configurations.

**Verification**:

1. Run browser with outdated version (multiple updates behind current) → Test that warning can be acknowledged but returns periodically
2. Verify that security warning is displayed indicating outdated status: → Verify that warning does not block browser functionality (not modal dialog)
   - Visible banner, icon, or notification
   - Clear message about being out of date
   - Indication of how far behind current version
3. Test that warning communicates security implications: → Test that warning includes last update check timestamp
   - Known vulnerabilities in current version
   - Security fixes available in newer versions
   - Recommendation to update
4. Verify that warning escalates with age of browser version: → Verify that critically outdated versions show prominent, persistent warnings
   - Minor warning if one version behind
   - Moderate warning if several versions behind
   - Strong warning if critically outdated (>6 months, contains CVEs)
5. Test that warning provides direct path to update mechanism → Test that warning differentiates between minor feature updates and security patches
6. Verify that warning persists across browser sessions → Verify that warning disappears after update installation

**Pass Criteria**: Warnings displayed for outdated versions AND clearly communicate security risk AND escalate with version age AND provide update path AND persistent but not blocking AND distinguish security vs feature updates

**Fail Criteria**: No warnings for outdated versions OR unclear risk communication OR static visibility regardless of age OR no update path OR blocking workflow OR doesn't distinguish update types

**Evidence**: Warning screenshots at various version ages, warning escalation timeline, security messaging content, update path accessibility, persistence behavior across sessions

**References**:

- Security Communication Best Practices: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/felt
- Vulnerability Disclosure: https://www.cisa.gov/coordinated-vulnerability-disclosure-process

### Assessment: UPD-REQ-36 (Clear indication of available security updates)

**Reference**: UPD-3-REQ-13 - Browser shall provide clear indication of available security updates

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

**Task**: Verify that the browser clearly distinguishes security updates from feature updates, providing prominent indication when security patches are available, enabling users to prioritize security-critical updates over general improvements, supporting informed manual update decisions by highlighting updates that address vulnerabilities even when user prefers manual installation control.

**Verification**:

1. Trigger availability of mixed updates:
   - Security patch fixing vulnerabilities
   - Feature update adding new capabilities
   - Bug fix update improving stability
2. Verify that security updates are clearly marked:
   - "Security Update" label or badge
   - Security icon (shield, lock) indicator
   - Color coding (red or yellow for security)
   - Separate section in update list
3. Test that security update details explain vulnerability addressed:
   - CVE identifier if applicable
   - Brief vulnerability description
   - Severity rating
   - Potential attack scenarios prevented
4. Verify that security updates are visually prioritized in UI:
   - Listed first in update list
   - Larger or bold text
   - More prominent notification
5. Test that non-security updates are clearly differentiated:
   - "Feature Update" or "Bug Fix" labels
   - Different visual treatment
   - Lower priority in list
6. Verify that mixed updates (security + features) are accurately labeled
7. Test that security update indicators are consistent across all UI locations
8. Verify that users can filter or view only security updates
9. Test that security update urgency is communicated appropriately
10. Verify that users can choose to install only security updates, skipping features

**Pass Criteria**: Security updates clearly distinguished from other types AND vulnerability details provided AND visual prioritization AND consistent indicators AND filtering possible AND selective installation supported

**Fail Criteria**: No distinction between update types OR missing vulnerability details OR no visual differentiation OR inconsistent indicators OR no filtering OR cannot selectively install security updates

**Evidence**: Update list screenshots showing mixed update types, security indicators across various UI locations, CVE information display, filtering UI, selective installation workflow

**References**:

- CVE Program: https://cve.mitre.org/
- Security Update Best Practices: https://www.cisa.gov/sites/default/files/publications/CISA-Cyber-Essentials-Toolkit_Mar2022_508.pdf

### Assessment: UPD-REQ-37 (Explicit user initiation for all updates)

**Reference**: UPD-3-REQ-14 - All updates shall require explicit user initiation

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

**Task**: Verify that absolutely no updates occur without explicit user initiation, ensuring complete user control over browser modifications and system changes, respecting environments requiring change control procedures, stability priorities, or bandwidth management, confirming that manual-only update mode provides true autonomy without any automatic behaviors.

**Verification**:

1. Configure browser in UPD-3 (manual only) mode → Test that user should explicitly:
   - Manually check for updates
   - Manually trigger download
   - Manually initiate installation
   - Manually restart browser if needed
2. Trigger availability of various updates (critical security and non-critical) → Verify that even critical security updates require user initiation
3. Verify that no automatic update checks occur: → Test that no "soft" automatic behaviors occur (e.g., automatic check with manual install)
   - Monitor network traffic for update check requests
   - 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/