brave / browser-laptop

[DEPRECATED] Please see https://github.com/brave/brave-browser for the current version of Brave
https://www.brave.com
Other
7.94k stars 974 forks source link

Prominently show validated legal identity & jurisdiction to users #791

Closed mikemaccana closed 6 years ago

mikemaccana commented 8 years ago

Test plan

https://github.com/brave/browser-laptop/pull/11776#issue-270846712


Hi Yan, you mentioned the issue of whether to show these details is separate, so as mentioned, I've filed a separate ticket. Thanks for giving this some thought.

Current Brave beta

Alice wants to connect to Bob, Inc.

Brave 0.7.14 looks like:

www.bob.com | Bob — Banking, Credit Cards, Mortgages and Auto Loans

The real Bob, Inc has had background checks to match a legal entity to their public key. Thus the verified organization and jurisdictionOfIncorporatedCompanyName are included inside their certificate. Other browsers show this to prominently to Alice when she connects. However, based on current Brave proposals, this is not shown to Alice in Brave unless she explicitly investigates the certificate.

Malory registers www.bob.com.mg and gets a certificate. Brave 0.7.14 looks like:

www.bob.com.mg | Bob — Banking, Credit Cards, Mortgages and Auto Loans

Not noticing the subtle difference from Brave's normal display, Alice POSTs her banking credentials to a site that is not Bob Inc. The site that is not Bob Inc uses these credentials to steal from Alice.

A study showed IE7's security UI wasn't very good at this.

That's correct. The Jackson study showed that extended validation as implemented in IE7's security UI was not understood by users. Brave can do security UI better than IE7, which showed the DNS domain as the first thing in address bar, right aligning and contracting the verified organisation name.

Here's the browser used in Jackson. The 'Identified by Microsoft' is the truncated version of the organisation name, though in this image (taken from Jackson) the truncation makes the verified organisation name not appear to the user:

screen shot 2016-02-16 at 20 35 32

A decade later, here's the current version of the same browser. Note how prominently show the validated legal entity is shown to users:

screen shot 2016-02-16 at 21 13 58

Alice is busy and has other things to do besides look for subtle DNS differences

Alice is busy and has other things to do than spot the subtle distinction between:

www.bob.com.mg | Bob — Banking, Credit Cards, Mortgages and Auto Loans

and

www.bob.com | Bob — Banking, Credit Cards, Mortgages and Auto Loans

Alice wishes to connect to the legal identity that is her bank, not a DNS domain.

Has there been independent studies on the effectiveness of EV UIs of modern browsers?

I've asked APF and unfortunately Chrome hasn't run any tests on the effectiveness of their EV UI. It could be interesting to chase the Edge and FF teams.

Proposal: prominently show validated legal identity & jurisdiction to users

Show the verified organization and jurisdictionOfIncorporatedCompanyName in a way that is effective at making similar looking DNS domains where the identity has not been verified appear different to users.

Bob, Inc [US] | Bob — Banking, Credit Cards, Mortgages and Auto Loans

Or any better way that achieves the same objective - you're the security engineer, this is your show!

diracdeltas commented 8 years ago

Thanks for filing this ticket and also checking in with Adrienne from Chrome.

Here is one counterargument to showing EV:

Could showing EV status prominently in the browser have helped Alice in the latter case? Not really, because Venmo.com doesn't use EV.

A large number of legitimate sites that accept "sensitive" information like credit cards and passwords don't use EV. Yahoo (according to my experience working on their security team) and Google (according to https://security.stackexchange.com/questions/52387/does-google-use-extended-validation-certificates) are just two large examples.

So I posit that EV user interface signals are helpful for preventing phishing attacks in exactly the case where:

  1. Alice is sure that the specific site she is visiting should have an EV cert, given that many legit sites don't.
  2. When Alice visits the fake site, she is fastidious enough to notice that it doesn't have the EV UI.

Better user interface than presented in the Jackson study can help with (2). I'm not sure it can help with (1).

We are a small team and too overloaded currently to do an EV user study. The best we can do before 1.0 is piggyback off other browsers who've experimented with EV UI. In the absence of studies showing that prominent EV UI helps a non-trivial percentage of users against actual attacks, I am going to mark this low-priority.

jlemming41 commented 8 years ago

Hi Mike - I don't have opinion on if EV shown prominent, but I do think for transparency u should disclose your business is selling EV. Maybe all other know, but maybe not.. -JL

mikemaccana commented 8 years ago

Hey @jlemming41! Yan already knows me, but to be clear, it's Mike from CertSimple here.

mikemaccana commented 8 years ago

Venmo, like Stripe or Paypal or other mobile wallets, should have a cert with a background checked organisation. I'm not sure it's wise to reduce indicators for all sites, eg not show identity indicators for PayPal or Stripe, because Venmo's certificate does not include them.

I get and understand your concern re: 1. On day 0 of a user's interaction with a particular website there's no way to know that a particular site should show an organisation and jurisdiction and other associated UI. Repeated user interaction with the real site - and a UI that prominently shows validated legal identity & jurisdiction - indicate that the site normally has an identity associated with it.

Totally understood re: a small team, and not having any information on current browsers UI effectiveness making it difficult. Going to reach out to Edge - maybe you can do the same for FF since I imagine you're closer? Will email you some more details off-list - some other folk we both know are interested in EV too. It's also worth considering, as the main purpose of the browser security UI is to show the user where they're connected to, whether erring on the side of providing the user with more information is preferable.

vtlynch commented 8 years ago

It's also worth considering, as the main purpose of the browser security UI is to show the user where they're connected to, whether erring on the side of providing the user with more information is preferable. (mikemaccana )

A cluttered UI can certainly have negative effects, but in this case it seems like following the established behavior of other browsers has little downside.

Better user interface than presented in the Jackson study can help with (2). I'm not sure it can help with (1). (diracdeltas )

I certainly see Yan's concern regarding EV UI's inability to help a user with step (1). I would think a majority of users are not confident that sites they visit have EVs or if they use other types of SSL. However, for users that are confident, the EV UI is a quick and easy way for them to make a decision on a situation that occurs frequently.

I think there are enough users out there frequently (multiple times a day) visiting Paypal.com, Discover.com, or any other number of sites handling highly-sensitive information who fulfill both conditions Yan outlined that would be inconvenienced if the EV-specific UI was removed.

Since transparency concerns were brought up above, I will also state that I am employed by a company that sells EV SSL, however we also sell DV and OV SSL.

diracdeltas commented 8 years ago

Here are a few questions I'm interested in for an EV user study, if anyone is up for conducting one:

  1. Do users know what the EV UI means compared to the regular SSL UI? What do they think each means?
  2. Show users a site they've never seen before. What percentage of them would enter their credit card number on an EV site compared to a regular SSL site that has the EV logo convincingly displayed in the page? Same for downloading an executable file.
  3. Show users phishing variants of sites that have EV (paypal, bankofamerica, etc). These phishing sites are HTTPS but don't have EV. What % of users recognize these sites as not legitimate?
  4. Repeat step 3 but for phishing variants of sites that don't have EV (google, yahoo, venmo, etc.)
andreasgal commented 8 years ago

I hate floating an undemocratic idea here but this problem is trivial to solve for 99% of the cases and very hard for the long tail. Most sensitive traffic goes to a few sites. Hand audit and approve certs for eBay, PayPal, amazon.com etc, and give a powerful UI hint. Allow community to contribute to the list and publish it. I think that brings a lot more happiness than EV.

bsclifton commented 8 years ago

If a decision is made to show EV certs as green, there is an SVG icon available: ~https://github.com/brave/browser-laptop/commit/0d53add11642853ccca022d04f5ad6d9a3b663ee~ https://github.com/brave/browser-laptop/issues/5891

Proposed spec (if decision is made to handle EV differently): https://github.com/brave/browser-laptop/issues/2178#issuecomment-226618866

bsclifton commented 8 years ago

Whatever we choose, we should consider being consistent with the iOS version. I noticed that in the iPhone app, a green icon there for a regular SSL site (non-EV)

mikemaccana commented 8 years ago

Hand audit and approve certs for eBay, PayPal, amazon.com etc, and give a powerful UI hint.

This is an excellent suggestion. We could come up with an standard for hand auditing, to be consistent. And then we could audit the implementation of those background checks. Then we could create an x509 field in the cert to indicate that someone has verified that this legal entity controls this public key. Then we could make it available to anyone who'd be willing to pay to have their identity audited, so new smaller companies could have background checks too rather than just eBay and Amazon.

As a 'powerful UI hint', I propose showing the audited legal name, in a prominent part of the browser Chrome associated with identity, for example, the address bar. ??

[--- Commented from Asana.com

commenter brad richter

---[aa]

andreasgal commented 8 years ago

You missed the point. The problem is unsolvable for the long tail. You end up with the CA shitshow we have today that is only marginally more deterministic than rolling the dice. It is very solvable for the short head of sites that make up 99% of phishing. Brave Inc. can audit the top sites (eBay, PayPal) that are targets of phishing (Brave can even see which sites are subject to it by monitoring user traffic anomalies) and then Brave should certify the cert. "Trusted by Brave" or whatever. The idea is to eliminate CAs not build CAs. The UI hint is from the browser and users will blame the browser if it's wrong. The browser vendor should stand behind it.

roybadami commented 7 years ago

I'd really like to have EV support. At least in the UK, pretty much all banks use EV on their Internet banking services, and I'm generally in the habit of glancing at the address bar when I access my bank. I realise that EV doesn't solve the general problem, but it does help with Internet banking, and IMHO that is an important enough use case.

I shouldn't have to switch back to Firefox to access my bank, but at the moment dong banking in Brave makes me uncomfortable. I realise that the discomfort is not entirely rational - but when you've been in the habit for several years of checking that the bank's name appears in the adress bar then using Brave is quite disconcerting.

mikemaccana commented 7 years ago

@andreasgal Denying sites outside the top 500 the ability to authenticate their identity obviously sucks. There are many reasons to prove a real legal identity online that have nothing to do with phishing.

You can support web of trust concepts, but not showing existing authentication info to users is a bad idea.

cndouglas commented 6 years ago

+1 from community: https://community.brave.com/t/please-make-padlock-icon-and-address-box-green-when-connecting-to-a-site-with-ev-ssl-certificate/783

srirambv commented 6 years ago

Verified on Windows x64

Verified on macOS 10.12.6 x64 using the following build:

Verified on Ubuntu 10.10 x64