Meta: Security hints for the picker

[mortenn]

This issue tracks the security-hints initiative. Implementation is split into focused issues so each phase can be designed, reviewed, and shipped independently.

Child issues

• Prerequisite — Granular network toggles: Settings: granular network permissions (split DisableNetworkAccess) #251
• A — Local UI (no network): Security hints: local URL parsing, domain highlight, and IDN visibility #247
• B — User-triggered TLS / cert: Security hints: user-triggered TLS and certificate summary #248
• C — Opt-in external lookups: Security hints: opt-in external reputation, CT, and domain metadata #249
• D — Enterprise / Umbrella docs: Security hints: enterprise proxy and Umbrella documentation #250

Principles

• Phased delivery: ship local presentation before network probes; add third-party lookups only with explicit opt-in.
• Privacy: default must not send URLs or hostnames to external reputation services; any target-host check should be clearly labeled and preferably user-triggered.
• Performance: avoid blocking picker open on network I/O; use timeouts and cancellation.
• Honest UX: padlock and colors should reflect verifiable signals, not a false sense of “safe site.”

Original brainstorm (preserved)

In this day and age, we should probably try to enhance our security profile.

Feature to probe the url/host to determine possible security risks:

• http/https
• valid certificate
• certificate transparency
• age of domain
• cipher list quality
• highlight domain part of url
• highlight non-ascii characters in url
• add a padlock icon with different colours for different security risks next to favicon

Need to do some research on public resources for malware domain checks.

Not all checks should run every time; try only connecting to the host when other tests look relatively safe. If in doubt, let user probe further with the click of a button. Some users will have Cisco Umbrella — we can maybe detect that and act accordingly, or let users manually enable umbrella mode?

[mortenn]

Cross-cutting product notes (for milestone 3.2 / child issues):

When a URL matches a user default

If the URL matches a configured rule in Defaults (same matching as DefaultSetting / IApplicationSettings.Defaults), treat it as user-trusted for routing:

• Defer automatic, network-backed security work (TLS prefetch, reputation APIs, CT/domain-age lookups, etc.) when the picker opens—do not probe in the background just because the UI appeared.
• Manual actions (“Check connection,” reputation checks, etc.) must remain available for users who want to verify anyway.
• Local-only Phase A presentation (scheme, IDN, domain highlighting) may still be shown (no extra privacy cost); optional later polish to dim or simplify when a default matched.
• Caveat: Default rules can be broad (e.g. hostname suffix). Deferral is a heuristic (“you said you trust this pattern”), not a safety guarantee—worth a line in UX/docs.

Network settings (#251)

Split DisableNetworkAccess so shortener resolution, favicon fetch, and future probes can be controlled independently; security features should respect those toggles and the default-match deferral above.

Milestone

All initiative issues are on milestone 3.2.