On Mon, Dec 18, 2017 at 1:26 PM, Andrew via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:
> On Friday, December 15, 2017 at 4:06:02 PM UTC-6, Ryan Sleevi wrote: > > It also perpetuates the myopic and flawed view as a phishing mitigation, > > whose reliance is upon users checking it (again, user hostile) > > Ryan, several times now you've characterized the expectation that users > check that the name listed on an EV certificate matches their expectations > as "user-hostile". Could you clarify why it is you believe this practice is > user-hostile while at the same time, expecting users to check the domain > name listed in the URL bar is not? (Or perhaps you believe that both > practices are user-hostile?) Indeed, both are user-hostile. Much like telling the user to 'look for the green lock' is user-hostile. The reason for this user-hostility is we try to shift the burden of responsibility onto the user, for what is an otherwise unrealistic task that requires a rather substantial degree of specialized knowledge. Things like "look for the green lock" - or "look for https://"; - are inherently user-hostile because they're designs that rely on positive security indicators. You can see some browsers [1][2] starting to more proactively warn when things are bad, rather than expecting users to notice the lack of positive security. You can also see the challenges in this, such as URL IDN display policies [3][4]. Think about your car - it doesn't show you lights for "OIL OK" "ENGINE OK" "TIRES OK" - it shows you warnings when they're actionable and relevant, but is otherwise quiet. Yet for navigating the web, we expect users to notice "SCHEME OK" "HOSTNAME OK" "IDENTITY MAYBE GOOD" before going anywhere. Specific to URLs, we have a number of realistic mitigations for domain name checking - such as password managers or solutions such as WebAuthN, both of which can perform that checking automatically. Are there gaps? For sure - but at least there's objective reason to believe the harm done versus good caused is defensible, and the technical controls are in place. [1] https://www.chromium.org/Home/chromium-security/marking-http-as-non-secure [2] https://support.mozilla.org/en-US/kb/insecure-password-warning-firefox [3] https://wiki.mozilla.org/IDN_Display_Algorithm [4] https://www.chromium.org/developers/design-documents/idn-in-google-chrome _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
