ACTION-399

I took on an action to propose some alternate text for our lock
recommendations.
Original text of Mez' proposal:

Web user agents MUST make information about the state of TLS protection
available. The [defn TLS indicator] SHOULD be part of primary user interface
during usage modes which entail the presence of signalling to the user
beyond only presenting page content. Otherwise, it MUST at least be
available through secondary user interface. Note that there may be usage
modes during which this requirement does not apply: For example, a Web
browser which is interactively switched into a no-chrome, full-screen
presentation mode need not preserve any security indicators in primary user
interface.

User interactions to access the TLS indicator MUST be consistent across all
Web interactions. This includes when TLS has not been used to protect those
interactions. In this case, web user agents SHOULD indicate the interaction
was not TLS protected. User agents with a visual user interface that make
the TLS indicator available in primary user interface SHOULD do so in a
consistent visual position.

On 2/27's call, we talked about a number of variants to further describe the
states of the lock, the one that received the most support was:

The TLS indicator MUST present a state this is only for strongly TLS
protected pages. The TLS indicator SHOULD differentiate between a page that
is weakly TLS-protected, and one that has no TLS protection at all.

The problem I see with this variant is that we are recommending a tri-state
lock. Opera has dropped this, Firefox has dropped this AFAIK, and we have no
literature that says this is a good idea. Indeed, we have literature that
indicates that such an indicator is likely to be confusing to users (to
paraphrase Rachna, more states equals more confusion).

What I was originally pushing for was to allow a two-state lock, i.e. if
there were a problem with a page, to allow the lock simply to not be shown.
I think the problem here is that people thought that users were going to be
in a state where they saw https:// and no lock, and be even more confused.

As such, I would like to propose the following text that I hope will resolve
the conflict:

"The TLS indicator MUST present a state that is only for strongly TLS
protected pages. The User Agent SHOULD inform users when they are viewing a
page that is weakly TLS-protected. The user agent MAY accomplish this by
using a third state in the TLS indicator, or via another mechanism (such as
a dialog, infobar, or other means)"

This still allows a tri-state lock, which I have great reservations against,
but I'm hopeful that many UAs will choose to go the infobar/dialog route
instead. In either case, it ensures that a user is informed that their
connection is using weak TLS, and should avoid the confusing case of seeing
https:// but no lock and being confused because that's all the user sees. It
seems to me that if a user is interacting with a site that is weak TLS, that
generally means there is a problem such as expired cert, weak encrpytion
etc, that the UA should warn the user about anyways.

Thoughts?