Re: ACTION-399

Ian wrote:

>> "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, 

It actually encourages a tri-state lock.

Add me to the list of those who have reservations about that.

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

Based on earlier discussions, I thought we were converging toward
*not* bothering the user with interruptive warnings if there is no
useful information available that would enable either the machine or
the user to come up with a decent decision?

On 2008-03-03 15:50:54 -0500, Johnathan Nightingale wrote:

> My support for the text Ian quotes from the Feb. 27 call was
> based in the fact that it seemed to a better job of anticipating
> the need/desire of browsers to indicate "broken" SSL as being
> different than SSL or non-SSL.  In cases where the SSL has been
> undermined - where a trusted "https://www.paypal.com/" bookmark
> is suddenly presenting a self-signed certificate, I didn't want
> text that recommended we signal that as being indistinguishable
> from a vanilla http connection.  I have very little interest in
> multi-level indicator schemes, for all the reasons Ian cites 
> (and more!) but I do view "broken" as being an importantly
> different state than "intact" or "not present".

I agree.

> Ian's text does an even better job of calling out that
> distinction, so +1.

While it's not spelled out in the current editor's draft, yet, the
example that you describes sounds like one in which we're not just
dealing with "mild" brokenness, but probably with a situation in
which a danger message [1] would be appropriate.  The entire idea
behind "weak" TLS was to capture situations in which that kind of
behavior is *not* acceptable, precisely because there are no strong
indications that a real danger occurs.  Whether the concrete case
should be a danger message, a warning / caution message, or a mere
notification (in Serge's taxonomy), is anohter question.

I still need to clean up the error condition part and make it
dovetail usefully with that taxonomy.

1. http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#errors-danger

-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Tuesday, 4 March 2008 01:41:17 UTC