Re: ACTION-399

On 3-Mar-08, at 2:42 PM, Ian Fette wrote:

> I took on an action to propose some alternate text for our lock  
> recommendations.
> ...
> 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).
> ...
> 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.

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

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

Cheers,

J

---
Johnathan Nightingale
Human Shield
johnath@mozilla.com

Received on Monday, 3 March 2008 20:51:18 UTC