Ram A M wrote:
Hmm, posted a response earlier today - I'm trying again as it's been
hours and hasn't shown up.

Actually, I did see your earlier post, reading it off of the news.mozilla.org news server.


In general I think we agree more than we disagree, and in many cases are aggressively in agreement, so I'll confine my followup comments to one key point.

I don't know how many levels of bars there needs to be but I see a risk
to the user in presenting the less robust or lower auth offerings to
the user in such a way that they recognize it as a 'safe for banking.'

This I think is the key question we need to look at: How to differentiate different types of SSL/TLS applications (low assurance vs. high, banking/e-commerce vs. "casual" use, etc.) while not either violating user's existing expectations or overly confusing users.


One approach proposed is CA branding, so that the user makes distinctions directly based on the CA-specific information presented to them (logo, wordmark, whatever). See Ian G for details :-)

Another approach is to provide some sort of UI indicator that is a proxy indicator for the level of assurance. For example, in an earlier message to this forum Gerv proposed using a "site identity verified" message in the status bar:

> Site-ID-verified-by-DNSSec: "site identity verified" indicator
> low-assurance cert: "site identity verified" indicator
> high-assurance cert: lock and "site identity verified" indicator

This proposal is actually quite radical, since it would abandon the traditional use of the lock to indicate an SSL connection, and reserve the lock for use only with certain types of SSL connections, i.e., those made with "high assurance" certs (suitably defined). Other SSL connections would *not* show a lock.

Radical though it might be, something like this might actually work. However rather than using the phrase "site identity verified" (what does this actually mean to users?) or some other textual message, why not use a different graphic, like a check mark? Users would then be free to build new expectations: Seeing a check mark is a good thing, but if you're spending money you'll want to see a lock as well.

In this case to avoid confusing users I would reserve the check mark only for SSL/TLS connections, since I think part of the user expectations would be some level of confidentiality of communications. That would also be part of the marketing message for CAs trying to sell low-assurance certs to new customers not concerned with financial or e-commerce applications.

Otherwise there'd be no distinction to the user between encrypted SSL connections using low-assurance certs and unencrypted connections to sites with domain names verified via DNSSec. I know some would argue that SSL connections using low-assurance certs are indistinguishable from non-SSL connections from a security point of view, but I don't think treating them exactly the same from a UI perspective serves the interests of anyone, least of all users.

Frank

--
Frank Hecker
[EMAIL PROTECTED]
_______________________________________________
mozilla-crypto mailing list
[email protected]
http://mail.mozilla.org/listinfo/mozilla-crypto

Reply via email to