Re: ACTION-399

On 2008-03-03 11:42:03 -0800, Ian Fette wrote:

> I took on an action to propose some alternate text for our lock
> recommendations.

Thanks for doing that, and thanks for the reminder you gave on the
call today.  I've merged Mez's and your text into the current
editor's draft, with slight changes to your text:

  <p>Web user agents MUST make information about the state of TLS
  protection available. The <termdef id="tls-indicator"><term>TLS
  indicator</term></termdef> 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.</p>

(Incidentally, part of this requirement is *weaker* than what's
implemented in pretty much all browsers that I know of (including
mobile browsers that I have easy access to) -- i.e., a padlock,
somewhere.  So, I wonder if the SHOULD in here isn't actually a
proper MUST.)

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

Ian's text:

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

Current editor's draft:

  <p>The TLS indicator MUST present a distinct state that is used
  only for <termref def="def-secure-page">TLS-secured</termref> Web
  pages. The User Agent SHOULD inform users when they are viewing a
  page that, along with all dependent resources, was retrieved
  through at least <termref def="def-weak-tls">weaky TLS
  protected</termref> transactions, including <termref
  def="def-mixed-content">mixed content</termref>.</p>

  <p>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).</p>

(Note that we don't seem to have the "at least it's all weak" notion
in use anywhere else, so I haven't bothered coining another
definition for that.  Or, if we use it elsewhere, I forgot.)

While this text has for the moment taken the place of the security
confidence estimate in section 6, I've kept the original SCE text
around in appendix C.

The TLS indicator is now here:

http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#sec-tls-indicator

Web Security Context: Experience, Indicators, and Trust
Editor's Draft 19 March 2008
$Revision: 1.200 $ $Date: 2008/03/19 20:01:16 $

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

Received on Wednesday, 19 March 2008 20:07:26 UTC