IDN abuses are far more hostile, to my mind, than EV positive indicators. At least within certain locales.
Why is IDN even displayed in styled form if the client locale belongs to a jurisdiction or language for which non-roman characters would be abnormal? Additionally, many vehicles provide non-boolean data regarding various operational measures and audits even when problems are not indicated: Ex: engine temperate gauge, tachometer, etc, all can be tells of a problem or lack of a category of a problem, and may help a user determine an impending problem prior to a critical alert threshold crossing. A more apropos example might be the immediate (short period) fuel economy value. (miles per gallon, kilometers per liter) Vehicle manufacturer research indicated that this data influences driver behavior toward conserving fuel and in general performing gradual speed changes, etc, (generally a better style of driving). Is it not possible that EV indicators can similarly encourage better ecommerce behaviors? On Mon, Dec 18, 2017 at 1:27 PM, Ryan Sleevi via dev-security-policy < [email protected]> wrote: > On Mon, Dec 18, 2017 at 1:26 PM, Andrew via dev-security-policy < > [email protected]> 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 > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
