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 <
> dev-security-policy@lists.mozilla.org> 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 

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

Reply via email to