EN-304-617.md.backup

- Google Transparency Report - HTTPS Security: https://transparencyreport.google.com/https/overview

### Assessment: ENC-REQ-16 (HTTPS-first mode)

**Reference**: ENC-REQ-16 - Browser shall implement HTTPS-first mode to automatically upgrade HTTP connections to HTTPS when available

**Given**: A conformant browser with encryption capability (ENC-2 or higher)

**Task**: Verify that HTTPS-first mode protects users from accidental insecure connections where attackers perform SSL-stripping attacks to downgrade HTTPS to HTTP, enabling interception of credentials and session tokens. Automatic HTTPS upgrade eliminates the window of vulnerability before secure connections are established, while user warnings for HTTP-only sites ensure informed consent before transmitting data over insecure channels.

**Verification**:

1. Enable HTTPS-first mode in browser settings
2. Navigate to HTTP URLs of sites that support HTTPS (http://example.com)
3. Verify that browser automatically upgrades to HTTPS
4. Test fallback behavior when HTTPS is unavailable:
   - Site doesn't support HTTPS
   - HTTPS connection fails/times out
   - Certificate error on HTTPS version
5. Verify user is prompted before loading HTTP-only sites
6. Test HTTPS upgrade for embedded resources (images, scripts, iframes)
7. Test interaction with HSTS and upgrade-insecure-requests
8. Measure performance impact of HTTPS upgrade attempts
9. Test HTTPS-first with different types of navigation (typed URL, bookmarks, links)
10. Verify browser remembers HTTP-only sites to avoid repeated upgrade attempts
11. HTTP URLs are automatically upgraded to HTTPS
12. Address bar shows HTTPS protocol after upgrade
13. Fallback to HTTP works with user consent when HTTPS unavailable
14. User is warned before loading HTTP-only sites
15. Browser remembers HTTP-only sites (cache/allowlist)
16. Embedded resources are also upgraded
17. HTTPS-first works alongside HSTS
18. Network panel shows upgrade attempts
19. Performance impact is minimal (parallel attempts)

**Pass Criteria**: HTTP connections are automatically upgraded to HTTPS when available AND users are warned before HTTP-only sites load

**Fail Criteria**: HTTP URLs are not upgraded OR no warnings for HTTP-only sites OR fallback doesn't work

**Evidence**: Network logs showing HTTP to HTTPS upgrades, address bar screenshots, warning dialog screenshots, performance measurements, browser settings showing HTTPS-first configuration

**References**:

- Chrome HTTPS-First Mode: https://blog.chromium.org/2021/07/increasing-https-adoption.html
- Firefox HTTPS-Only Mode: https://support.mozilla.org/en-US/kb/https-only-prefs
- HTTPS Upgrade Mechanisms: https://www.w3.org/TR/upgrade-insecure-requests/
- EFF HTTPS Everywhere: https://www.eff.org/https-everywhere
- OWASP Transport Layer Protection: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html

### Assessment: ENC-REQ-17 (Certificate pinning bypass detection)

**Reference**: ENC-REQ-17 - Browser shall detect and prevent attempts to bypass certificate pinning protections

**Given**: A conformant browser with encryption capability (ENC-2 or higher)

**Task**: Verify that certificate pinning bypass detection prevents attackers or malware from installing rogue root certificates to perform man-in-the-middle attacks against pinned domains. Detecting bypass attempts protects browser vendor properties and high-security sites from SSL interception, while logging and user warnings ensure transparency when certificate validation is weakened by enterprise policies or security tools.

**Verification**:

1. Configure test environment with certificate pinning enabled
2. Attempt various bypass techniques:
   - Installing custom root CA certificates
   - Using SSL/TLS interception proxies (corporate MITM)
   - Modifying browser certificate store
   - Using browser extensions to disable pinning
   - Command-line flags to disable certificate validation
3. Test browser's built-in static pins (Google, Mozilla properties)
4. Verify that pin bypass attempts are detected and logged
5. Test enterprise policy controls for pinning exceptions
6. Verify user notifications for certificate store modifications
7. Test that developer tools can't silently bypass pinning
8. Examine browser internal state for pin enforcement
9. Test interaction between pin bypass and security indicators
10. Static pins for built-in domains cannot be bypassed
11. Custom root CA installation triggers user warnings
12. SSL interception is detected and indicated in UI
13. Browser logs pin bypass attempts
14. Certificate store modifications are visible to users
15. Enterprise policies can override pins with explicit configuration
16. Developer tools respect pinning (or show clear bypass warnings)
17. Security indicators reflect weakened security when pins bypassed
18. Console logs show certificate validation details

**Pass Criteria**: Static certificate pins cannot be bypassed without explicit user/admin action AND pin bypass attempts are logged and indicated

**Fail Criteria**: Pins can be silently bypassed OR no indication when certificate validation is weakened

**Evidence**: Console logs showing pin enforcement, certificate store modification warnings, test results from bypass attempts, enterprise policy documentation, security indicator screenshots

**References**:

- Chrome Certificate Pinning: https://www.chromium.org/Home/chromium-security/education/tls/
- OWASP Certificate Pinning: https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
- SSL Interception Detection: https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/
- Mozilla Pin Override: https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning

### Assessment: ENC-REQ-18 (TLS downgrade protection)

**Reference**: ENC-REQ-18 - Browser shall implement protections against TLS version and cipher suite downgrade attacks

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that TLS downgrade protection prevents man-in-the-middle attackers from forcing browsers to use older TLS versions or weaker cipher suites with known vulnerabilities like POODLE or BEAST. Downgrade protection ensures that even when attackers intercept and modify handshake messages, the browser detects the manipulation and aborts the connection rather than proceeding with weakened cryptographic parameters.

**Verification**:

1. Set up test environment capable of simulating man-in-the-middle attacks
2. Configure server supporting TLS 1.3 and TLS 1.2
3. Attempt to force downgrade from TLS 1.3 to TLS 1.2 by manipulating ClientHello
4. Test TLS_FALLBACK_SCSV signaling value (RFC 7507)
5. Attempt downgrade attacks during connection:
   - Version rollback to older TLS versions
   - Cipher suite downgrade to weaker algorithms
   - Extension stripping attacks
6. Verify browser detects and rejects downgrade attempts
7. Test that Finished message MAC includes all handshake messages
8. Verify TLS 1.3 downgrade protection sentinel values in ServerHello.random
9. Test protection against truncation attacks
10. Browser signals maximum supported TLS version correctly
11. TLS_FALLBACK_SCSV is included in fallback connections
12. Version rollback attacks are detected and connection aborted
13. Cipher suite downgrade attempts trigger handshake failure
14. Browser validates ServerHello.random for downgrade sentinels
15. Extension stripping is detected through transcript hash validation
16. Finished message properly authenticates handshake
17. Console shows error messages for detected downgrade attempts
18. Connection fails securely rather than completing with weakened security

**Pass Criteria**: All TLS downgrade attempts are detected AND connections fail rather than proceed with weakened security

**Fail Criteria**: Any downgrade attack succeeds OR browser accepts weakened connection parameters

**Evidence**: Packet captures showing downgrade attempts and rejection, Wireshark showing TLS_FALLBACK_SCSV, console error logs, test scripts demonstrating attack attempts

**References**:

- RFC 7507 - TLS Fallback SCSV: https://datatracker.ietf.org/doc/html/rfc7507
- RFC 8446 - TLS 1.3 Downgrade Protection: https://datatracker.ietf.org/doc/html/rfc8446#section-4.1.3
- POODLE Attack and Downgrade Prevention: https://www.openssl.org/~bodo/ssl-poodle.pdf
- Chrome TLS Implementation: https://www.chromium.org/Home/chromium-security/education/tls/

### Assessment: ENC-REQ-19 (Legacy crypto deprecation)

**Reference**: ENC-REQ-19 - Browser shall deprecate and remove support for legacy cryptographic algorithms and protocols

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that legacy crypto deprecation prevents attackers from exploiting known cryptographic weaknesses in outdated algorithms like SHA-1 collision attacks, RC4 biases, or short RSA key factorization. Progressive deprecation with clear timelines gives organizations migration paths while ensuring browsers eventually reject severely compromised cryptography that no longer provides meaningful security guarantees.

**Verification**:

1. Test browser behavior with legacy cryptographic elements:
   - TLS 1.0 and TLS 1.1 protocols
   - SHA-1 certificates
   - 1024-bit RSA keys
   - MD5-based signatures
   - RC4 cipher suite
   - CBC-mode cipher suites
   - DSA certificates
2. Verify that legacy protocols/algorithms are rejected or trigger warnings
3. Test deprecation timeline (when were features removed)
4. Verify that browser update notes document deprecated features
5. Test enterprise policy overrides for legacy support (temporary exceptions)
6. Check browser developer documentation for deprecation roadmap
7. Test fallback behavior when modern crypto unavailable
8. Verify that critical errors can't be bypassed for severely deprecated crypto
9. TLS 1.0 and 1.1 connections are rejected or show warnings
10. SHA-1 certificates trigger security errors
11. 1024-bit RSA keys are rejected
12. MD5 and RC4 are completely disabled
13. Legacy crypto rejections show clear error messages
14. Browser documentation lists deprecated features with timelines
15. Enterprise policies can temporarily enable legacy support (if necessary)
16. No silent fallback to insecure legacy protocols
17. Console logs indicate when legacy crypto is encountered

**Pass Criteria**: All severely deprecated cryptographic elements are rejected AND users are warned about moderately deprecated features

**Fail Criteria**: Legacy crypto is accepted without warnings OR deprecated features work without indication

**Evidence**: Connection error screenshots for legacy servers, browser release notes documenting deprecations, console error logs, test results across browser versions showing deprecation timeline

**References**:

- Chrome Deprecation Timeline: https://www.chromium.org/Home/chromium-security/education/tls/
- Mozilla Security Roadmap: https://wiki.mozilla.org/Security/Server_Side_TLS
- RFC 8996 - Deprecating TLS 1.0 and TLS 1.1: https://datatracker.ietf.org/doc/html/rfc8996
- CA/B Forum - SHA-1 Deprecation: https://cabforum.org/2014/10/16/ballot-118-sha-1-sunset/
- NIST Cryptographic Algorithm Deprecation: https://csrc.nist.gov/projects/hash-functions

### Assessment: ENC-REQ-20 (Cryptographic key isolation)

**Reference**: ENC-REQ-20 - Browser shall isolate cryptographic keys and prevent cross-origin key access

**Given**: A conformant browser with encryption capability (ENC-2 or higher)

**Task**: Verify that cryptographic key isolation enforces same-origin policy for Web Crypto API keys, preventing malicious cross-origin scripts from accessing or exfiltrating cryptographic keys generated by other origins. Key isolation ensures that even if an attacker compromises one origin, they cannot steal cryptographic keys belonging to other origins to impersonate users or decrypt sensitive data protected by those keys.

**Verification**:

1. Create test scenarios with Web Crypto API key generation on different origins
2. Generate cryptographic keys on https://origin-a.com using Web Crypto API
3. Attempt to access keys from https://origin-b.com
4. Test IndexedDB key storage isolation across origins
5. Verify that keys marked as non-extractable cannot be extracted
6. Test key export restrictions based on key usage
7. Test that key handles cannot be passed between origins via postMessage
8. Verify key isolation in browser's internal key storage
9. Test hardware-backed key storage (if available, e.g., WebAuthn)
10. Test key isolation for different user profiles/contexts
11. Keys generated on one origin cannot be accessed from another origin
12. IndexedDB key storage respects same-origin policy
13. Non-extractable keys cannot be exported or extracted
14. Key usage restrictions are enforced (keys can't be used for unauthorized operations)
15. Key handles are opaque and cannot be transferred cross-origin
16. Browser internal key storage is isolated per origin
17. Hardware-backed keys are protected by platform security
18. Different user profiles have separate key storage
19. Attempts to access cross-origin keys throw SecurityError

**Pass Criteria**: Cryptographic keys are strictly isolated by origin AND non-extractable keys cannot be exported

**Fail Criteria**: Keys can be accessed across origins OR key usage restrictions can be bypassed

**Evidence**: Console logs showing SecurityError for cross-origin key access, test code demonstrating isolation, browser internal state showing key storage separation, WebAuthn test results

**References**:

- W3C Web Cryptography API - Key Storage: https://www.w3.org/TR/WebCryptoAPI/#concepts-key-storage
- MDN CryptoKey: https://developer.mozilla.org/en-US/docs/Web/API/CryptoKey
- Chrome Web Crypto Key Isolation: https://chromium.googlesource.com/chromium/src/+/master/components/webcrypto/README.md
- OWASP Key Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html
- WebAuthn Specification - Credential Storage: https://www.w3.org/TR/webauthn-2/#credential-storage

### Assessment: ENC-REQ-21 (Certificate store security)

**Reference**: ENC-REQ-21 - Browser shall maintain secure certificate store with integrity protection and auditing

**Given**: A conformant browser with encryption capability (ENC-1 or higher)

**Task**: Verify that certificate store security prevents attackers from installing rogue root certificates to enable man-in-the-middle attacks against all TLS connections. Protected certificate stores with integrity checking and audit trails detect unauthorized modifications, while requiring explicit user consent for root CA changes prevents malware from silently compromising the foundation of TLS trust.

**Verification**:

1. Examine browser's certificate store location and access controls
2. Test that certificate store is protected with appropriate file system permissions
3. Attempt to modify certificate store while browser is running
4. Verify that certificate store changes are logged/auditable
5. Test root CA certificate management:
   - View installed root certificates
   - Add custom root CA (with user consent)
   - Remove root CA (with user consent)
   - Verify certificate trust settings
6. Test that system certificate store is used appropriately
7. Verify that enterprise-managed certificates are clearly indicated
8. Test certificate store integrity verification mechanisms
9. Test that certificate store updates are secure and authenticated
10. Verify user notifications for certificate store modifications
11. Certificate store files have restrictive permissions (not world-readable)
12. Certificate store cannot be modified without appropriate privileges
13. Browser detects and handles certificate store corruption
14. Root CA additions/removals require explicit user consent
15. Certificate store UI shows all installed root certificates
16. System certificate store integration works correctly
17. Enterprise-managed certificates are visibly marked
18. Certificate store modifications are logged
19. Users are notified of certificate store changes
20. Certificate store updates are signed and verified

**Pass Criteria**: Certificate store is protected with appropriate access controls AND modifications require user consent and are logged

**Fail Criteria**: Certificate store can be modified without user knowledge OR no audit trail for modifications

**Evidence**: File system permission analysis, certificate store UI screenshots, audit log samples, test results from modification attempts, enterprise policy documentation

**References**:

- Mozilla Root Store Program: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/
- Chrome Root Store: https://chromium.googlesource.com/chromium/src/+/main/net/data/ssl/chrome_root_store/
- Microsoft Trusted Root Program: https://learn.microsoft.com/en-us/security/trusted-root/program-requirements
- Apple Root Certificate Program: https://www.apple.com/certificateauthority/ca_program.html
- OWASP Certificate Management: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html#certificate-and-public-key-pinning

### Assessment: ENC-REQ-22 (Certificate pinning override prohibition)

**Reference**: ENC-0-REQ-22 - Browser shall not allow user override of certificate pinning failures

**Given**: A conformant browser with ENC-0 capability (full encryption with HSM support)

**Task**: Verify that the browser prohibits user override of certificate pinning failures to prevent users from being socially engineered into accepting fraudulent certificates, ensuring that pinning violations - which indicate active man-in-the-middle attacks or certificate misissuance - are treated as hard failures that cannot be bypassed, protecting high-security environments where certificate pinning is a critical defense against targeted attacks on specific domains.

**Verification**:

1. Configure test server with certificate pinning via HTTP header or browser built-in pins
2. Establish baseline connection to verify pinning is active
3. Modify server certificate to trigger pinning violation:
   - Use different certificate authority
   - Use expired pin
   - Use self-signed certificate
   - Use certificate from wrong domain
4. Attempt to connect to server with pinning violation
5. Verify that browser blocks connection with clear error message
6. Verify that no "proceed anyway" or "add exception" option is available
7. Test that advanced settings do not provide override mechanism
8. Verify that enterprise policies cannot disable pinning for pinned domains
9. Test that developer tools cannot bypass pinning enforcement
10. Verify that command-line flags cannot disable pinning
11. Test that error message explains pinning failure clearly
12. Verify that pinning failures are logged for security monitoring
13. Test that users are directed to contact site administrators, not bypass warnings

**Pass Criteria**: Pinning failures cannot be overridden through any mechanism AND no bypass options exist in UI OR settings AND error messages explain pinning violations AND failures are logged

**Fail Criteria**: Users can bypass pinning failures OR override mechanisms exist OR pinning can be disabled for pinned domains OR unclear error messages

**Evidence**: Pinning violation error screenshots showing no bypass option, settings inspection showing no override controls, policy test results, developer tools verification, log entries showing pinning failures

**References**:

- HTTP Public Key Pinning: https://www.rfc-editor.org/rfc/rfc7469
- Certificate Pinning Best Practices: https://owasp.org/www-community/controls/Certificate_and_Public_Key_Pinning
- CWE-295: Improper Certificate Validation: https://cwe.mitre.org/data/definitions/295.html

### Assessment: ENC-REQ-23 (Hardware-backed cryptographic operations)

**Reference**: ENC-0-REQ-23 - All cryptographic operations shall be performed in hardware-backed secure enclaves when available

**Given**: A conformant browser with ENC-0 capability on hardware with secure enclave support

**Task**: Verify that all cryptographic operations utilize hardware-backed secure enclaves (such as TPM, Secure Enclave, or TEE) when available, ensuring that private keys and sensitive cryptographic material never exist in unencrypted form in main memory, protecting against memory dumps, cold boot attacks, and malware that attempts to extract cryptographic keys from software-based key storage, providing defense-in-depth through hardware isolation.

**Verification**:

1. Identify available hardware security features on test platform:
   - TPM (Trusted Platform Module) on Windows/Linux
   - Secure Enclave on macOS/iOS
   - TEE (Trusted Execution Environment) on Android
   - Hardware security modules (HSM)
2. Install browser on platform with hardware security support
3. Verify that browser detects and initializes hardware security features
4. Perform cryptographic operations requiring key generation or usage:
   - TLS client certificates
   - Web Crypto API key generation
   - Password manager encryption keys
   - Browser sync encryption keys
5. Verify that keys are generated and stored in hardware-backed storage
6. Test that private keys cannot be exported from hardware storage
7. Verify that cryptographic operations occur within secure enclave
8. Test that key material is not accessible via memory dumps
9. Verify that browser preferences or about page indicates hardware security status
10. Test that browser falls back gracefully if hardware security is unavailable
11. Verify that enterprise policies can require hardware-backed crypto
12. Test that hardware security failures are logged and reported to users

**Pass Criteria**: Cryptographic operations use hardware-backed storage when available AND private keys are non-exportable AND key material is protected from memory access AND hardware security status is visible to users

**Fail Criteria**: Keys are stored in software despite hardware availability OR keys can be exported OR no hardware security detection OR silent fallback without user notification

**Evidence**: Platform security feature verification, key storage location inspection, memory dump analysis showing no key exposure, browser status page screenshots, enterprise policy configuration tests

**References**:

- Trusted Platform Module: https://trustedcomputinggroup.org/resource/tpm-library-specification/
- Web Crypto API Key Storage: https://www.w3.org/TR/WebCryptoAPI/#concepts-key-storage
- Hardware Security Modules: https://csrc.nist.gov/glossary/term/hardware_security_module

### Assessment: ENC-REQ-24 (Encryption strictness configuration)

**Reference**: ENC-2-REQ-17 - Users shall be able to configure encryption strictness levels

**Given**: A conformant browser with ENC-2 capability (selective encryption)

**Task**: Verify that users can configure encryption strictness levels to balance security requirements with compatibility needs, enabling organizations and advanced users to enforce stricter encryption policies than defaults (such as TLS 1.3-only, strong cipher suites only, or mandatory HSTS) or relax policies for specific legitimate scenarios (such as internal legacy systems), providing flexibility while maintaining security visibility and audit trails.

**Verification**:

1. Access browser encryption settings or configuration interface
2. Identify available encryption strictness options:
   - Minimum TLS version selection (TLS 1.2, TLS 1.3 only)
   - Cipher suite policy (strong only, compatible, allow weak)
   - Mixed content policy (block all, block active only, allow)
   - Certificate validation strictness (strict, standard, permissive)
   - HSTS enforcement level
3. Test configuring each strictness level and verify enforcement:
   - Set TLS 1.3-only mode and verify TLS 1.2 connections fail
   - Configure strong cipher suites only and verify weak cipher rejection
   - Enable strict mixed content blocking and verify all mixed content blocked
   - Set strict certificate validation and verify self-signed cert rejection
4. Verify that strictness changes take effect immediately or after restart
5. Test that configuration changes are persistent across browser sessions
6. Verify that enterprise policies can override user strictness settings
7. Test that per-site exceptions can be configured for compatibility
8. Verify that strictness level changes are logged
9. Test that current strictness level is visible in security indicators
10. Verify that documentation explains security implications of each level
11. Test that strictness cannot be weakened below secure baseline without warnings

**Pass Criteria**: Multiple encryption strictness levels are available AND configuration changes are enforced AND settings persist AND per-site exceptions are possible AND changes are logged

**Fail Criteria**: No strictness configuration available OR changes not enforced OR settings don't persist OR no audit trail OR no security baseline

**Evidence**: Settings UI screenshots showing strictness options, connection test results at different levels, persistence verification, per-site exception demonstrations, audit logs

**References**:

- TLS Configuration Recommendations: https://wiki.mozilla.org/Security/Server_Side_TLS
- OWASP Transport Layer Protection: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html

### Assessment: ENC-REQ-25 (Connection security visual indicators)

**Reference**: ENC-2-REQ-18 - Browser shall provide visual indicators for connection security status

**Given**: A conformant browser with ENC-2 capability (selective encryption)

**Task**: Verify that the browser provides clear, prominent visual indicators for connection security status, enabling users to quickly identify secure HTTPS connections, insecure HTTP connections, and connection security issues, preventing users from entering sensitive information on insecure sites and helping users recognize potential man-in-the-middle attacks or certificate problems through consistent, understandable security indicators in the browser UI.

**Verification**:

1. Navigate to various sites with different security states:
   - Valid HTTPS with strong encryption (https://example.com with TLS 1.3)
   - Valid HTTPS with weak encryption (https://site.com with TLS 1.2, weak cipher)
   - HTTP site (http://insecure.com)
   - HTTPS with certificate error (expired, self-signed, wrong domain)
   - HTTPS with mixed content (active and passive)
   - HTTPS with Extended Validation certificate
2. Verify that each security state has distinct visual indicator:
   - Padlock icon or security indicator in address bar
   - Color coding (green for secure, red for insecure, warning for issues)
   - Text labels ("Secure", "Not Secure", "Connection is not secure")
   - Icon states (locked, unlocked, warning symbol)
3. Test that clicking security indicator shows detailed connection information:
   - TLS version and cipher suite
   - Certificate details and validity
   - Mixed content warnings
   - Permission grants
4. Verify that indicators are visible in all browser UI states (fullscreen, focus mode, etc.)
5. Test that indicators cannot be spoofed by web content
6. Verify that security indicator changes are immediate upon navigation
7. Test that security indicators are accessible (screen reader compatible)
8. Verify that indicators follow consistent design across all platforms
9. Test that users can easily distinguish secure from insecure connections
10. Verify that connection security details are easy to access
11. Test that security indicators work in private/incognito mode

**Pass Criteria**: Distinct visual indicators for each security state AND indicators are prominent and clear AND detailed information is accessible AND indicators cannot be spoofed AND consistent across platforms

**Fail Criteria**: Security indicators are unclear OR states are not visually distinct OR detailed information not available OR indicators can be spoofed OR inconsistent across platforms

**Evidence**: Screenshots of security indicators for each connection state, detailed security info panel screenshots, accessibility testing results, spoofing attempt tests, cross-platform consistency verification

**References**:

- Browser Security Indicators: https://www.w3.org/TR/design-principles/#priority-of-constituencies
- User Security Awareness: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/felt

### Assessment: ENC-REQ-26 (User encryption settings control)

**Reference**: ENC-3-REQ-11 - Users shall have full control over encryption settings

**Given**: A conformant browser with ENC-3 capability (basic encryption with optional enhanced protection)

**Task**: Verify that users have full control over all encryption settings, enabling advanced users and specific deployment scenarios to configure encryption behavior according to their unique requirements, such as enabling legacy protocols for compatibility with older systems, configuring custom cipher suite preferences, or managing certificate exceptions, while ensuring that users are informed of the security implications of relaxing encryption requirements.

**Verification**:

1. Access browser advanced encryption settings
2. Verify that comprehensive encryption controls are available:
   - TLS version selection (TLS 1.0, 1.1, 1.2, 1.3)
   - Individual cipher suite enable/disable
   - Certificate validation options
   - Mixed content policy configuration
   - HSTS bypass capabilities
   - Certificate exception management
   - Revocation checking options
3. Test modifying each encryption setting:
   - Enable legacy TLS 1.0/1.1 and verify older servers accessible
   - Disable specific cipher suites and verify negotiation changes
   - Relax certificate validation and verify self-signed cert acceptance
   - Allow mixed content and verify passive content loads
   - Add certificate exceptions and verify accepted
4. Verify that each setting change shows security warning explaining risks
5. Test that changes require user acknowledgment of risks
6. Verify that current encryption configuration is clearly documented in UI
7. Test that dangerous configurations trigger prominent warnings
8. Verify that encryption settings can be exported/imported for consistency
9. Test that enterprise policies can restrict user control over specific settings
10. Verify that reset-to-defaults option exists for safe rollback
11. Test that encryption setting changes are logged
12. Verify that help documentation explains each setting clearly

**Pass Criteria**: All encryption settings are user-configurable AND security warnings accompany risky changes AND current configuration is visible AND reset option exists AND changes are logged

**Fail Criteria**: Encryption settings are not configurable OR no security warnings for risky changes OR configuration not visible OR no rollback option OR no audit trail

**Evidence**: Advanced settings UI screenshots, configuration change workflows, security warning examples, setting export/import tests, policy restriction demonstrations, audit logs

**References**:

- TLS Configuration: https://wiki.mozilla.org/Security/Server_Side_TLS
- User Control Principles: https://www.w3.org/TR/design-principles/#user-control

### Assessment: ENC-REQ-27 (Encryption status UI indicators)

**Reference**: ENC-3-REQ-12 - Browser shall provide encryption status indicators in UI

**Given**: A conformant browser with ENC-3 capability (basic encryption with optional enhanced protection)

**Task**: Verify that the browser provides comprehensive encryption status indicators throughout the user interface, enabling users to understand the current encryption configuration and connection security state at any time, helping users make informed decisions about whether their current settings are appropriate for their security needs and alerting them to potential security issues that may result from configuration changes.

**Verification**:

1. Access browser with various encryption configurations active
2. Verify that encryption status is visible in multiple UI locations:
   - Address bar security indicator
   - Settings page encryption section
   - About/information pages
   - Developer tools security panel
3. Test that status indicators show:
   - Current TLS version in use
   - Active cipher suite
   - Certificate validity status
   - Enabled/disabled encryption features (HSTS, CT, OCSP)
   - Legacy protocol status (if enabled)
   - Number of certificate exceptions
4. Navigate to sites with different security configurations
5. Verify that indicators update dynamically to reflect current connection
6. Test that clicking indicators provides detailed encryption information
7. Verify that weak encryption configurations trigger visual warnings
8. Test that encryption status persists in browser session info
9. Verify that status indicators are accessible via keyboard navigation
10. Test that indicators work in all browsing modes (normal, private, reader)
11. Verify that encryption dashboard or summary page exists
12. Test that status information is exportable for security audits

**Pass Criteria**: Encryption status visible in multiple UI locations AND indicators show detailed configuration AND indicators update dynamically AND weak configurations trigger warnings AND status is exportable

**Fail Criteria**: Encryption status not visible OR indicators lack detail OR no dynamic updates OR no warnings for weak config OR status not exportable

**Evidence**: UI screenshots from various locations showing status, status detail panel captures, dynamic update demonstrations, weak config warning examples, audit export samples

**References**:

- Security Indicators Design: https://www.usenix.org/conference/soups2016/technical-sessions/presentation/felt
- Transparency in Browser Security: https://www.w3.org/TR/design-principles/#transparency

### Assessment: ENC-REQ-28 (Legacy protocol compatibility mode)

**Reference**: ENC-3-REQ-13 - Legacy protocol support may be enabled for compatibility with user consent

**Given**: A conformant browser with ENC-3 capability (basic encryption with optional enhanced protection)

**Task**: Verify that legacy protocol support (SSL 3.0, TLS 1.0, TLS 1.1) can be enabled for compatibility with older systems when necessary, but requires explicit, informed user consent with clear security warnings, ensuring users understand the risks of downgrading to deprecated protocols while enabling access to legacy systems that cannot be immediately upgraded, such as embedded devices, industrial control systems, or archived services.

**Verification**:

1. Verify that legacy protocols are disabled by default
2. Attempt to connect to server requiring legacy protocol (TLS 1.0 or TLS 1.1)
3. Verify that connection fails with clear error message explaining protocol version mismatch
4. Access browser settings to enable legacy protocol support
5. Verify that enabling legacy protocols requires:
   - Navigation to advanced settings section
   - Explicit checkbox or toggle action
   - Acknowledgment of security warning dialog
6. Test that security warning clearly explains:
   - Legacy protocols have known vulnerabilities
   - Connections may be susceptible to downgrade attacks
   - Sensitive information should not be transmitted
   - Recommendation to upgrade server instead
7. Verify that legacy protocol enablement is persistent across sessions
8. Test that legacy protocol usage triggers visual indicator in address bar
9. Verify that connections using legacy protocols show prominent warning
10. Test that legacy protocol can be enabled for specific sites only (not globally)
11. Verify that legacy protocol enablement is logged for security auditing
12. Test that reset to defaults disables legacy protocols

**Pass Criteria**: Legacy protocols disabled by default AND enablement requires explicit consent AND clear security warnings shown AND usage is indicated visually AND site-specific enablement possible AND changes logged

**Fail Criteria**: Legacy protocols enabled by default OR no consent required OR warnings unclear OR no visual indicators OR only global enablement OR no audit trail

**Evidence**: Default protocol test results, enablement workflow screenshots, security warning content, visual indicator examples, site-specific configuration tests, audit log samples

**References**:

- Deprecating Legacy TLS: https://datatracker.ietf.org/doc/rfc8996/
- TLS 1.0 and 1.1 Deprecation: https://www.rfc-editor.org/info/rfc8996

### Assessment: ENC-REQ-29 (Complete encryption policy control)

**Reference**: ENC-4-REQ-6 - Users shall have complete control over all encryption policies

**Given**: A conformant browser with ENC-4 capability (minimal encryption)

**Task**: Verify that users have unrestricted control over all encryption policies without artificial limitations, enabling specialized use cases such as security research, penetration testing, legacy system maintenance, or air-gapped environments where standard encryption enforcement may need to be completely disabled, while ensuring that the browser clearly indicates when insecure configurations are active and the risks associated with completely disabling encryption protections.

**Verification**:

1. Access all available encryption policy controls in browser
2. Verify that users can modify every encryption-related setting:
   - Completely disable TLS/SSL enforcement
   - Allow HTTP for all connections
   - Disable all certificate validation
   - Accept any cipher suite including export-grade
   - Disable HSTS, OCSP, CT, and all security features
   - Allow unlimited certificate exceptions
   - Disable mixed content blocking entirely
   - Remove all protocol version restrictions
3. Test disabling each encryption protection individually
4. Verify that disabled protections do not activate even in dangerous scenarios
5. Test that completely insecure configuration allows access to test servers:
   - HTTP-only servers
   - Self-signed certificate servers
   - Expired certificate servers
   - Weak cipher servers (3DES, RC4)
6. Verify that browser displays persistent warning when encryption is disabled
7. Test that insecure configuration status is highly visible in all UI
8. Verify that browser warns before entering sensitive input on insecure connections
9. Test that configuration can be saved and restored
10. Verify that no enterprise policies can override user's complete control
11. Test that security researchers can use browser for SSL/TLS testing
12. Verify that documentation explains appropriate use cases for insecure configs

**Pass Criteria**: All encryption policies are user-modifiable without restriction AND disabled protections do not activate AND insecure status is highly visible AND configuration is persistent AND appropriate for specialized use cases

**Fail Criteria**: Some encryption policies cannot be disabled OR disabled protections still activate OR insecure status not visible OR configuration doesn't persist OR inappropriate for intended use cases

**Evidence**: Complete settings access screenshots, disabled protection test results, insecure configuration visual indicators, specialized use case demonstrations, security researcher testimonials

**References**:

- Security Research Ethics: https://www.w3.org/Security/wiki/Improving_Web_Security
- Penetration Testing Requirements: https://owasp.org/www-community/Penetration_testing

### Assessment: ENC-REQ-30 (User-enabled legacy protocol support)

**Reference**: ENC-4-REQ-7 - Browser shall support legacy protocols when explicitly enabled by user

**Given**: A conformant browser with ENC-4 capability (minimal encryption)

**Task**: Verify that browser supports legacy cryptographic protocols (SSL 3.0, TLS 1.0, TLS 1.1) when explicitly enabled by user, ensuring that legacy systems, embedded devices, or historical services that cannot be upgraded remain accessible through modern browsers in specialized scenarios, while making it clear that these protocols have known security vulnerabilities and should only be used when absolutely necessary with full understanding of the risks.

**Verification**:

1. Access browser protocol version settings
2. Verify that legacy protocol options are available:
   - SSL 3.0 enable/disable
   - TLS 1.0 enable/disable
   - TLS 1.1 enable/disable
3. Enable each legacy protocol individually
4. Test connection to servers requiring each legacy protocol:
   - SSL 3.0-only server (if available for testing)
   - TLS 1.0-only server
   - TLS 1.1-only server
5. Verify that connections succeed when protocol is enabled
6. Verify that connections fail when protocol is disabled
7. Test that protocol negotiation prefers newest enabled version
8. Verify that legacy protocol connections show security warnings
9. Test that mixed protocol versions work correctly (e.g., TLS 1.0 and 1.3 both enabled)
10. Verify that legacy protocol usage is logged
11. Test that browser identifies which protocol version was used for each connection
12. Verify that legacy protocol support can be toggled without browser restart
13. Test that documentation explains security risks of each legacy protocol

**Pass Criteria**: All legacy protocols can be enabled by user AND enabled protocols function correctly AND protocol negotiation works properly AND legacy usage is warned and logged AND risks are documented

**Fail Criteria**: Legacy protocols cannot be enabled OR enabled protocols don't work OR protocol negotiation fails OR no warnings/logging OR risks not explained

**Evidence**: Legacy protocol enablement screenshots, successful connection tests to legacy servers, protocol version negotiation logs, security warning examples, risk documentation excerpts

**References**:

- SSL 3.0 Vulnerabilities (POODLE): https://www.rfc-editor.org/rfc/rfc7568
- TLS 1.0 and 1.1 Deprecation: https://datatracker.ietf.org/doc/rfc8996/
- Legacy Protocol Security Risks: https://www.nist.gov/publications/transitioning-use-cryptographic-algorithms-and-key-lengths

## 6.4 Security Event Logging Assessments

This section covers assessment procedures for requirements LOG-REQ-1 through LOG-REQ-20, addressing security event logging, audit trails, privacy-preserving telemetry, log retention, and security monitoring capabilities.

### Assessment: LOG-REQ-1 (Security event logging)

**Reference**: LOG-REQ-1 - Browser shall implement comprehensive security event logging for security-relevant events

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

**Task**: Verify that comprehensive security event logging enables detection and investigation of attacks, providing audit trails for security incidents like XSS attempts, CSP violations, and CORS bypasses. Complete logging with timestamps, origins, and outcomes allows security teams to identify attack patterns, correlate events across multiple targets, and respond to threats effectively while supporting compliance with security monitoring requirements.

**Verification**:

1. Configure the browser to enable security event logging in developer or enterprise mode
2. Access the browser's internal logging interfaces (chrome://net-internals/#events, about:networking, or equivalent)
3. Navigate to a test page that triggers multiple security events (mixed content, certificate errors, XSS attempts)
4. Attempt cross-origin requests that violate CORS policies
5. Load test pages with Content Security Policy violations
6. Trigger sandbox violations by attempting to access restricted APIs
7. Review the logged events to verify all security-relevant actions are captured
8. Export the security event log to verify it contains timestamps, event types, origins, and outcomes
9. Verify that security events include sufficient context for investigation (URL, origin, error type, timestamp)
10. Test that security events persist across browser restarts if configured for persistent logging
11. All security policy violations are logged with accurate timestamps
12. Logs include sufficient context to identify the origin and nature of security events
13. Security events include: CSP violations, CORS failures, mixed content blocks, certificate errors, sandbox violations
14. Logs distinguish between blocked and allowed actions with clear outcomes
15. Event log format is structured and machine-readable (JSON or similar)
16. Logs can be exported for analysis or forwarding to external systems

**Pass Criteria**: All tested security events are captured in logs with complete context (timestamp, origin, event type, outcome) AND logs are exportable in a structured format

**Fail Criteria**: Any security event fails to be logged OR logs lack critical context (timestamp, origin, or outcome) OR logs are not exportable

**Evidence**: Screenshots of security event logs showing various event types, exported log files in JSON/structured format, video recordings of security events being triggered and logged, comparison matrices showing event coverage

**References**:

- W3C Reporting API: https://www.w3.org/TR/reporting-1/
- OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- NIST SP 800-92 Guide to Computer Security Log Management: https://csrc.nist.gov/publications/detail/sp/800-92/final

### Assessment: LOG-REQ-2 (Certificate error logging)

**Reference**: LOG-REQ-2 - Browser shall log all certificate validation failures with detailed error information

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

**Task**: Verify that certificate error logging enables detection of man-in-the-middle attacks and certificate misconfigurations, providing detailed information for security investigations. Comprehensive certificate logs with chain details, error types, and revocation status help identify patterns of TLS interception, rogue certificates, or systematic validation failures that could indicate ongoing attacks against users or infrastructure.

**Verification**:

1. Set up a test web server with various certificate issues (expired, self-signed, wrong hostname, revoked)
2. Navigate to https://expired.badssl.com/ and verify the certificate error is logged
3. Navigate to https://wrong.host.badssl.com/ and verify hostname mismatch is logged
4. Navigate to https://self-signed.badssl.com/ and verify self-signed certificate is logged
5. Navigate to https://revoked.badssl.com/ and verify revocation status is logged
6. Review the certificate error logs to verify they include: certificate chain, error type, validation date, origin
7. Test certificate pinning failures by creating a pinning policy and violating it
8. Verify that certificate transparency failures are logged when CT enforcement is enabled
9. Test that HSTS violations involving certificates are properly logged
10. All certificate validation failures are logged with specific error codes
11. Logs include certificate subject, issuer, validity period, and error reason
12. Certificate chain information is captured in logs
13. Revocation check results (OCSP/CRL) are included
14. Certificate pinning violations are logged separately
15. Logs distinguish between hard failures (blocked) and soft failures (warnings)

**Pass Criteria**: All certificate validation failures are logged with complete certificate details AND error reasons are specific and actionable

**Fail Criteria**: Any certificate error is not logged OR logs lack certificate details OR error reasons are generic/unhelpful

**Evidence**: Certificate error log entries showing various failure types, screenshots of BadSSL.com test results with corresponding logs, certificate chain dumps from logs, network traces showing certificate validation process

**References**:

- RFC 5280 X.509 Certificate Validation: https://www.rfc-editor.org/rfc/rfc5280
- Certificate Transparency RFC 6962: https://www.rfc-editor.org/rfc/rfc6962
- Chrome Certificate Error Logging: https://www.chromium.org/Home/chromium-security/certificate-transparency/
- OWASP Transport Layer Protection Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html

### Assessment: LOG-REQ-3 (Extension security events)

**Reference**: LOG-REQ-3 - Browser shall log extension-related security events including installation, permission changes, and security violations

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

**Task**: Verify that extension security event logging enables detection of malicious extensions that abuse permissions, access sensitive APIs without authorization, or attempt to bypass security policies. Detailed extension logs with lifecycle events, permission changes, and security violations help identify compromised or rogue extensions that could exfiltrate data, inject malicious scripts, or escalate privileges beyond their declared capabilities.

**Verification**:

1. Install a test extension and verify the installation event is logged with extension ID, name, and permissions
2. Modify extension permissions and verify permission changes are logged
3. Create a test extension that attempts to access APIs without proper permissions
4. Trigger extension content script injection and verify it's logged
5. Test extension network requests to verify they are logged separately from normal browsing
6. Uninstall the extension and verify the removal event is logged
7. Test developer mode extension loading and verify it's flagged in logs
8. Simulate an extension attempting to bypass CSP and verify the violation is logged
9. Test extension update events and verify version changes are logged
10. Extension lifecycle events (install, update, uninstall) are logged with metadata
11. Permission requests and grants are logged with timestamp and user action
12. Extension security violations are logged separately from web page violations
13. Extension API access attempts are logged with success/failure status
14. Developer mode extensions are clearly marked in logs
15. Extension-injected content is distinguishable in logs from page content

**Pass Criteria**: All extension lifecycle and security events are logged with complete metadata AND extension actions are distinguishable from page actions

**Fail Criteria**: Any extension security event is not logged OR extension actions cannot be distinguished from page actions OR permission changes are not logged

**Evidence**: Extension event logs showing lifecycle events, permission change logs, screenshots of extension security violations with corresponding log entries, comparison of extension vs. page event logs

**References**:

- Chrome Extension Security Architecture: https://developer.chrome.com/docs/extensions/mv3/security/
- WebExtensions API Security: https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API
- Extension Permission Model: https://www.chromium.org/Home/chromium-security/extension-content-script-fetches/
- OWASP Browser Extension Security: https://owasp.org/www-community/vulnerabilities/Unsafe_Mobile_Code

### Assessment: LOG-REQ-4 (CSP violation reporting)

**Reference**: LOG-REQ-4 - Browser shall implement Content Security Policy violation reporting and logging

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

**Task**: Verify that CSP violation reporting enables detection of XSS attempts and policy bypasses, providing actionable intelligence about attacks targeting web applications. Automated reporting with complete violation context allows security teams to identify attack vectors, adjust CSP policies, and detect systematic attempts to inject malicious scripts or load unauthorized resources that could compromise user data.

**Verification**:

1. Create a test page with a strict CSP policy: `Content-Security-Policy: default-src 'self'; report-uri /csp-report`
2. Attempt to load external scripts that violate the CSP policy
3. Verify CSP violation reports are sent to the report-uri endpoint
4. Check browser console for CSP violation messages
5. Test inline script violations and verify they are reported
6. Test eval() violations and verify they are blocked and reported
7. Configure CSP with report-to directive and Report-To header for modern reporting
8. Test CSP reporting with report-only mode using Content-Security-Policy-Report-Only header
9. Verify that violation reports include: violated-directive, blocked-uri, source-file, line-number
10. All CSP violations trigger console warnings in developer tools
11. Violation reports are sent to configured report-uri endpoints
12. Reports include complete context: violated directive, blocked resource, source location
13. Report-only mode generates reports without blocking resources
14. Modern Reporting API (report-to) is supported for CSP reporting
15. Reports are generated in standard JSON format per W3C specification

**Pass Criteria**: All CSP violations are reported to configured endpoints AND console warnings are displayed AND reports contain complete violation context

**Fail Criteria**: Any CSP violation is not reported OR reports lack critical information OR report-uri/report-to mechanisms don't function

**Evidence**: CSP violation reports in JSON format, server logs showing received reports, browser console screenshots with CSP warnings, network traces showing report transmission, comparison of report-only vs. enforce mode

**References**:

- Content Security Policy Level 3: https://www.w3.org/TR/CSP3/
- CSP Violation Reports: https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP#violation_reports
- W3C Reporting API: https://www.w3.org/TR/reporting-1/
- CSP Evaluator Tool: https://csp-evaluator.withgoogle.com/

### Assessment: LOG-REQ-5 (Network Error Logging - NEL)

**Reference**: LOG-REQ-5 - Browser shall support Network Error Logging (NEL) for monitoring network failures

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

**Task**: Verify that Network Error Logging enables detection of network-level attacks and infrastructure issues, monitoring connection failures that could indicate DNS hijacking, TLS interception, or targeted denial of service. NEL provides visibility into network failures that occur before HTTP layer, helping identify systematic attacks, CDN failures, or connectivity issues affecting user security and availability.

**Verification**:

1. Set up a test server that sends NEL policy header: `NEL: {"report_to":"network-errors","max_age":86400,"success_fraction":0.1,"failure_fraction":1.0}`
2. Configure Report-To header: `Report-To: {"group":"network-errors","max_age":86400,"endpoints":[{"url":"https://collector.example.com/nel"}]}`
3. Trigger DNS resolution failures by attempting to navigate to non-existent domains
4. Trigger connection timeout errors by connecting to a filtered port
5. Trigger TLS handshake failures by using misconfigured certificates
6. Trigger HTTP protocol errors by sending malformed responses
7. Verify that NEL reports are generated and sent to the configured endpoint
8. Check that success sampling works correctly (success_fraction parameter)
9. Verify NEL reports include: type, url, server-ip, protocol, status-code, elapsed-time, phase
10. NEL policy is correctly parsed from HTTP headers
11. Network failures trigger NEL report generation
12. Reports are sent to configured endpoints asynchronously
13. Sampling fractions are respected for success/failure events
14. NEL reports include detailed failure context (phase, type, status)
15. Reports distinguish between DNS, connection, TLS, and HTTP errors
16. NEL reports are batched and sent efficiently

**Pass Criteria**: NEL policy is respected AND all configured failure types generate reports AND reports include complete network error context

**Fail Criteria**: NEL policy is ignored OR network failures don't generate reports OR reports lack critical failure information

**Evidence**: NEL policy headers from server, collected NEL reports in JSON format, server logs showing received reports, network traces demonstrating various failure types, NEL report timing analysis

**References**:

- Network Error Logging Specification: https://www.w3.org/TR/network-error-logging/
- Reporting API Specification: https://www.w3.org/TR/reporting-1/
- NEL Deployment Guide: https://developers.google.com/web/updates/2018/09/reportingapi
- MDN Network Error Logging: https://developer.mozilla.org/en-US/docs/Web/HTTP/Network_Error_Logging

### Assessment: LOG-REQ-6 (Crash reporting)

**Reference**: LOG-REQ-6 - Browser shall implement privacy-preserving crash reporting with user consent

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

**Task**: Verify that privacy-preserving crash reporting enables browser vendors to identify and fix security vulnerabilities without exposing user browsing history or personal information. User consent requirements ensure transparency while crash report anonymization prevents data leakage, balancing the need for diagnostic information to address exploitable bugs with user privacy rights and regulatory compliance.

**Verification**:

1. Review browser settings for crash reporting consent options
2. Enable crash reporting and verify user consent is obtained before activation
3. Force a controlled browser crash using debugging tools or crash test pages
4. Verify a crash report is generated locally
5. Check that crash reports are anonymized and don't contain browsing history or personal data
6. Verify crash reports include: crash signature, stack trace (symbolicated), browser version, OS version
7. Test that crash reports are only uploaded after user consent
8. Verify users can view and delete crash reports before submission
9. Test opt-out functionality and verify no reports are sent when opted out
10. Verify renderer process crashes are reported separately from browser process crashes
11. User consent is required before crash reporting is enabled
12. Crash reports are generated for browser and renderer crashes
13. Reports include technical diagnostics (stack traces, crash signatures) but no personal data
14. Users can review crash reports before submission
15. Crash reporting can be disabled and re-enabled in settings
16. Crash reports are transmitted securely (HTTPS) to vendor endpoints
17. Local crash report storage has size/age limits to prevent disk exhaustion

**Pass Criteria**: User consent is obtained before crash reporting AND crash reports exclude personal data AND users can review/delete reports

**Fail Criteria**: Crash reports are sent without consent OR reports contain personal/browsing data OR users cannot control crash reporting

**Evidence**: Crash report consent dialogs, sanitized crash reports showing included data, settings screenshots showing crash reporting controls, privacy policy documentation, crash report upload network traces

**References**:

- Breakpad Crash Reporting: https://chromium.googlesource.com/breakpad/breakpad/
- Firefox Crash Reporter: https://support.mozilla.org/en-US/kb/mozilla-crash-reporter
- GDPR Crash Reporting Compliance: https://gdpr.eu/what-is-gdpr/

### Assessment: LOG-REQ-7 (Log data minimization)

**Reference**: LOG-REQ-7 - Browser shall minimize data collection in logs, collecting only information necessary for security purposes

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

**Task**: Verify that log data minimization prevents excessive collection of personal information, balancing security monitoring needs with privacy rights and regulatory compliance. Collecting only necessary security-relevant data with automatic retention limits reduces the risk of data breaches exposing user browsing history, credentials, or sensitive personal information while still enabling effective threat detection and incident response.

**Verification**:

1. Review all log categories to identify what data is collected (security events, network, performance, etc.)
2. Examine security event logs to verify they don't contain unnecessary personal information
3. Check that URLs in logs are sanitized (query parameters removed or hashed)
4. Verify that user credentials are never logged, even in error conditions
5. Test that cookies and authentication tokens are redacted from network logs
6. Review crash reports to ensure they exclude browsing history and form data
7. Verify that IP addresses in logs are anonymized (last octet removed) or hashed
8. Test that logs have automatic retention limits (time-based and size-based)
9. Verify that sensitive form fields (passwords, credit cards) are never logged
10. Check that telemetry aggregates data rather than logging individual user actions
11. Logs contain only security-relevant events, not general browsing activity
12. Personal identifiable information (PII) is redacted or hashed in logs
13. URL parameters that may contain session tokens are removed
14. Credentials, cookies, and authentication headers are never logged
15. IP addresses are anonymized or removed from logs
16. Logs automatically expire based on retention policies
17. Form input data is excluded from all logs
18. Aggregated metrics replace individual event logging where possible

**Pass Criteria**: All logs demonstrate data minimization (no unnecessary PII) AND sensitive data is consistently redacted AND retention limits are enforced

**Fail Criteria**: Logs contain unnecessary PII OR credentials/tokens appear in logs OR no retention limits exist

**Evidence**: Log samples showing redaction of sensitive data, privacy analysis of log contents, retention policy documentation, comparison of logged vs. available data showing minimization, code review of logging implementations

**References**:

- OWASP Logging Cheat Sheet - Data Sanitization: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- NIST Privacy Framework: https://www.nist.gov/privacy-framework
- W3C Privacy Principles: https://www.w3.org/TR/privacy-principles/

### Assessment: LOG-REQ-8 (Log anonymization)

**Reference**: LOG-REQ-8 - Browser shall implement anonymization techniques for logs that require user-related data

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

**Task**: Verify that log anonymization prevents re-identification of users from telemetry data, protecting user privacy while maintaining the ability to detect security incidents and diagnose technical issues. Proper anonymization defends against correlation attacks where adversaries combine multiple log entries to de-anonymize users, as well as against data breaches where stolen logs could reveal sensitive user information.

**Verification**:

1. Review telemetry logs to identify user-related fields (user ID, device ID, session ID)
2. Verify that user identifiers are hashed with secure cryptographic hash functions
3. Check that hash salts are rotated periodically to prevent correlation
4. Test that IP addresses are anonymized using techniques like IP truncation or hashing
5. Verify that timestamps are rounded to reduce precision (hour or day level) where appropriate
6. Test that geographic data is generalized (city level rather than GPS coordinates)
7. Review aggregation techniques to ensure k-anonymity (minimum group size) is maintained
8. Verify differential privacy techniques are applied to statistical queries on logs
9. Test that user fingerprints cannot be reconstructed from anonymized logs
10. Check that pseudonymous identifiers change across different log contexts
11. User identifiers are consistently hashed with strong cryptographic algorithms
12. Hash salts are documented and rotated on a defined schedule
13. IP addresses are truncated or hashed before storage
14. Timestamps are appropriately rounded to reduce granularity
15. Geographic data is generalized to prevent precise location tracking
16. Aggregated data maintains k-anonymity with k >= 5
17. Differential privacy noise is added to prevent individual identification
18. Cross-log correlation attacks are prevented through identifier rotation

**Pass Criteria**: All user-related data is anonymized using documented techniques AND re-identification is demonstrably prevented AND k-anonymity is maintained

**Fail Criteria**: User data is logged in plaintext OR anonymization is reversible OR re-identification is possible through correlation

**Evidence**: Anonymized log samples with hash values, salt rotation policy documentation, privacy analysis showing k-anonymity, differential privacy parameters, re-identification attack test results (negative results expected)

**References**:

- Differential Privacy: https://www.microsoft.com/en-us/research/publication/differential-privacy/
- K-Anonymity Model: https://epic.org/privacy/reidentification/Sweeney_Article.pdf
- NIST De-Identification Guidelines: https://nvlpubs.nist.gov/nistpubs/ir/2015/NIST.IR.8053.pdf
- Google's Privacy-Preserving Techniques: https://policies.google.com/technologies/anonymization

### Assessment: LOG-REQ-9 (User consent for telemetry)

**Reference**: LOG-REQ-9 - Browser shall obtain explicit user consent before collecting and transmitting telemetry data