On Thursday, August 29, 2019 at 12:17:22 PM UTC-7, Ryan Sleevi wrote: > On Thu, Aug 29, 2019 at 2:49 PM Kirk Hall via dev-security-policy < > [email protected]> wrote: > > > Sure, I’m happy to explain, using Bank of America as an example. > > > Kirk, > > Thanks for providing this example. Could you help me understand how it > helps determine that things are safe? For example, the reputation system > you described, which is more akin to code signing than what is generally > practiced an anti-phishing, seems like if it was implemented, it would > leave users at significant risk from compromise on EV sites. That is, if an > EV-using site was compromised and displayed a phishing form, the fact that > it had "good" reputation would actually be actively harmful to users > security, because it would make it harder to provide timely responsiveness. > That is, it would be a false negative. > > In this case, the use of EV certificates, and the presumption of > reputation, would lead to actively worse security. > > Did I misunderstand the scenario?
Don't argue with me, argue with the browser phishing filters and anti-phishing services who do, in fact, use EV website information to protect users as I described. Presumably they know what they are doing. And go argue with Facebook, which has just decided that binding confirmed identity information to Facebook posts will help in combating fraud, fake identities, foreign powers, etc. Presumably they also know what they are doing. There's also a difference between EV code signing and EV websites. For EV code signing, this creates a permanent artifact associated with the signed code that helps applications decide whether or not to trust the code - and it has become a de facto requirement in some environments. For EV certificates, the appeal for website owners over the past 10 years has been that they get a distinctive EV UI that they believe protects their consumers and their brands (again, don't argue with me but argue with them - but these website owners include many of the top enterprises and brands, so presumably they are smart people too with significant technical skills and have made their own EV decisions on a rational basis, even if you disagree with them or have a different commercial interest in supporting or not supporting website identity). EV identity information as used by phishing filters and anti-phishing services is an *incidental* benefit (but a huge one), and is not a benefit that most EV website owners are focused on - and website owners may not be willing to continue using EV certs for their websites for this incidental anti-phishing benefit alone if the EV UI goes away. So again - why don't Mozilla and Chrome move to the simple, binary Apple UI which tells users at a glance whether or not the site has been identified (green URL and lock symbol, yes / black URL and lock symbol, no) so users can be informed and make their own decisions, instead of making the EV and DV UIs the same and hiding EV information from users. And please conduct one more Google research paper - but this time, don't just ask users what they *know* about the Chrome UI (and then show them websites without any training or other information - the Chrome UI has changed so often in recent years that no one knows what it means anymore - from green "Secure" for DV phishing sites until last year, to turning the EV UI gray). Instead, research what users *can* know with 30 seconds of training. I'll bet the Apple binary UI (identity / no identity) will be easy for users to understand. Now that would be research worth using. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
