On 14/08/2019 21:55, Peter Bowen wrote:
On Wed, Aug 14, 2019 at 10:16 AM Jakob Bohm wrote:

On 14/08/2019 18:18, Peter Bowen wrote:
On thing I've found really useful in working on user experience is to
discuss things using problem & solution statements that show the before
after.  For example, "It used to take 10 minutes for the fire sprinklers
activate after sensing excessive heat in our building.  With the new
sprinkler heads we installed they will activate within 15 seconds of
detecting heat above 200ºC, which will enable fire suppression long
it spreads."

It used to be easy for fraudsters to get an OV certificate with untrue
company information from smaller CAs.  By only displaying company
information for more strictly checked EV certificates, it now becomes
much more difficult for fraudsters to pretend to be someone else, making
fewer users fall for such scams.

Displaying an overly truncated form of the company information, combined
with genuine high-trust companies (banks, credit card companies) often
using obscure subsidiary names instead of their user trusted company
names for their EV certs has greatly reduced this benefit.

If we assume for a minute that Firefox had no certificate information
anywhere in the UI (no subject info, no issuer info, no way to view
etc), what user experience problem would you be solving by adding
information about certificates to the UI?

This hasn't been the case since before Mozilla was founded.

But lets assume we started from there, the benefit would be to tell
users when they were dealing with the company they know from the
physical world versus someone almost quite unlike them.

Making this visible with as few (maybe 0) extra user actions increases
the likelihood that users will spot the problem when there is one.

What is the problem being solved?  You specify the benefit but I'm still
not clear why this info is needed in the first place.

Problem example: User wants to visit the website of the well-known high
street bank whose massive sign on the outside wall and letterhead in
actual paper documents is "Example Bank of Lalaland".  User receives a
(fake) e-mail telling him to go to "example.net" (or just makes a
trivial typo) for their new online offerings, that mail is genuinely
from "notificati...@example.net", because the scammers actual registered
example.net (the real bank is example.com).  User opens
https://example.net in the latest browser and
is told by the UI that they are safely (padlock) connected to
example.net.  But not that this isn't the "Example Bank of Lalaland"
properly registered with "the companies registry of Lalaland" and
regulated by "the banking authority of Lalaland" and with an official
company address at "central square 2, capitalcity, Lalaland" (a well
known 19th century banking building currently containing the mahogany
board room and a regular branch office).

With EV as currently implemented they (don't if the wrong domain) get a
green color indicating this certificate was issued to someone with a
proven ID, the name actually verified by the national corporate registry
(responsible for uniqueness) and the Lalaland country code.  All with
near 0 user effort.

With the proposed UI change they get nothing (just a default padlock)
and with a bit of effort that this certificate was EV validated for
"Example Bank Ltd" (but not if this is "Example Bank of Lalaland" or
"Example Bank of Enemy Country Full of Phishers").  Users have to dig
into technical dialogs to see that this EV certificate may have the
wrong "JurisdictionOfIncorporation" value.  And there's nothing that
Example Bank of Lalaland or even the government of Lalaland can do to
stop this or even prosecute the phishers, because there is no legal
cooperation with that enemy country.

See also the original summary from 2007 by Gerv:


Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
dev-security-policy mailing list

Reply via email to