Skip to content
This repository has been archived by the owner on Dec 11, 2019. It is now read-only.

Prominently show validated legal identity & jurisdiction to users #791

Closed
mikemaccana opened this issue Feb 16, 2016 · 15 comments
Closed

Prominently show validated legal identity & jurisdiction to users #791

mikemaccana opened this issue Feb 16, 2016 · 15 comments
Assignees
Labels
priority/P5 Cosmetic. Spelling, copy, layout. New features (which should also be part of an initiative). QA/checked-Linux QA/checked-macOS QA/checked-Win64 QA/test-plan-specified release-notes/include suggestion

Comments

@mikemaccana
Copy link

mikemaccana commented Feb 16, 2016

Test plan

#11776 (comment)


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
Copy link
Member

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

Here is one counterargument to showing EV:

  • Alice goes to Venmo.com. It looks like a legit site so she enters her credentials.
  • Alices goes to Venmo.com.mg. It also looks legit, so she also enters her credentials.

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.

@diracdeltas diracdeltas added the needs-info Another team member needs information from the PR/issue opener. label Feb 16, 2016
@jlemming41
Copy link

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
Copy link
Author

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

@mikemaccana
Copy link
Author

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
Copy link

vtlynch commented Feb 17, 2016

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
Copy link
Member

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
Copy link

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
Copy link
Member

bsclifton commented Jun 16, 2016

If a decision is made to show EV certs as green, there is an SVG icon available:
0d53add
#5891

Proposed spec (if decision is made to handle EV differently):
#2178 (comment)

@bsclifton
Copy link
Member

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
Copy link
Author

mikemaccana commented Jul 7, 2016

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
Copy link

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
Copy link

roybadami commented Nov 29, 2016

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
Copy link
Author

mikemaccana commented Nov 30, 2016

@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.

  • If the site is receiving high-trust data, eg personal info (think feeld.com) proving a specific legal entity controls a site provides some degree of accountability to where that info is going vs someone who just registered a domain

  • The 'fake news' of recent discussion. There's a lot of sites with similar names to major newspapers, but 'The Washington Post [US]' is actually the Washington Post, vs someone who just registered a domain.

  • Some industries - particularly fashion - have a lot of affiliates and resellers. When you purchase an item, are you purchasing it from the actual label or an affiliate? It's useful for a label to be able to prove that yes, this is actually the label themselves and not an affiliate vs.... someone who just registered a domain.

  • And phishing attacks.

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

@darkdh darkdh self-assigned this Nov 2, 2017
@darkdh darkdh added the hackday Legacy label for a one-day hack-session. label Nov 2, 2017
sashaperigo added a commit to sashaperigo/browser-laptop that referenced this issue Nov 3, 2017
@cezaraugusto cezaraugusto added this to the Triage Backlog milestone Nov 8, 2017
@bsclifton bsclifton modified the milestones: Triage Backlog, Prioritized Backlog Nov 21, 2017
darkdh pushed a commit to sashaperigo/browser-laptop that referenced this issue Nov 21, 2017
@bsclifton bsclifton added priority/P5 Cosmetic. Spelling, copy, layout. New features (which should also be part of an initiative). and removed needs-info Another team member needs information from the PR/issue opener. priority/low (deprecated) labels Nov 22, 2017
darkdh pushed a commit to sashaperigo/browser-laptop that referenced this issue Nov 29, 2017
@bsclifton bsclifton modified the milestones: Backlog (Prioritized), 0.21.x (Developer Channel) Dec 23, 2017
@srirambv
Copy link
Collaborator

srirambv commented Mar 22, 2018

Verified on Windows x64

  • 0.22.6 e6ff4ea
  • libchromiumcontent: 65.0.3325.162
  • muon: 5.1.0

Verified on macOS 10.12.6 x64 using the following build:

  • 0.22.6 e6ff4ea
  • libchromiumcontent: 65.0.3325.162
  • muon: 5.1.0

Verified on Ubuntu 10.10 x64

  • 0.22.7 8bb7e77
  • libchromiumcontent: 65.0.3325.181
  • muon: 5.1.1

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
priority/P5 Cosmetic. Spelling, copy, layout. New features (which should also be part of an initiative). QA/checked-Linux QA/checked-macOS QA/checked-Win64 QA/test-plan-specified release-notes/include suggestion
Projects
None yet
Development

No branches or pull requests