BrowserLockDown, SafeBrowsingMode

Tim, I'm reviewing BrowserLockDown, currently here:

  http://www.w3.org/2006/WSC/wiki/RecommendationDisplayProposals/BrowserLockDown

In the requirements, you write:

  A user agent MUST support the configuring of several "profiles"
  (sets of configuration settings) to be used when visiting
  different categories of sites.

  A user agent MUST support the configuring of different "usage
  modes" and allow the specification of which profiles are active in
  which modes.

It strikes me that the "usage modes" and some of the requirements
around them are probably all we need to talk about in the spec; how
they map to profiles (or the like) might actually be an
implementation detail.

This requirement:

  A user agent SHOULD allow users to view details of why a request
  or access to a site was blocked based on profile settings,
  including a description of which configuration setting or settings
  contributed to the site being blocked (but displayed only on
  request).
  
  A user agent SHOULD keep a history of blocked sites and the
  reasons for the block to allow analysis of these at a later date
  and time (and possibly by a person other than the user).
  
... could effectively turn into material for 5.3 (error handling),
and a requirement for a drill down on error pages.

I wonder how we would deal with users hitting error pages and
wanting to reduce their security mode interactively.


Dan, I think that this sets a nice framework for Safe Browsing Mode,
which could effectively turn into a somewhat standardized "usage
mode."

  http://www.w3.org/2006/WSC/wiki/SafeWebBrowsingTemplate

One interesting aspect in SBM in this regard is the idea that the
user should express their "intent to deal with a certain community."
That actually suggests a classification of usage modes by intended
tasks as a paradigm that should possibly be exposed -- "safe for
banking" could be one way to communicate such a mode, maybe
triggered with a secure attention key (and subject to questions
whether that trigger is actually effective).

SBM could then be phrased in terms of other material in the
specification, essentially tying up some loose ends:

- strict path validation (maybe this is really where that should
  become a MUST, not sme more general material on EV-certificates)
- expectation of strong TLS; weak TLS leads to a "hard error"
  interaction
- when an MITM attack is detected, clients MUST NOT use the
  approach in 5.3.2

The current text in the editor's draft includes a strawman
requirement on "downgrades" from EV certificates causing a "change
of security level"; I wonder if that would also be better done in
Safe Browsing Mode, as opposed to generic browsing profiles.

Thoughts welcome.

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

Received on Sunday, 9 September 2007 12:36:32 UTC