W3C home > Mailing lists > Public > public-wsc-wg@w3.org > April 2007

Meeting record: WSC WG weekly 2007-04-18

From: Thomas Roessler <tlr@w3.org>
Date: Fri, 27 Apr 2007 22:53:00 +0200
To: WSC WG <public-wsc-wg@w3.org>
Message-ID: <20070427205259.GA5230@raktajino.does-not-exist.org>

The minutes from our meeting on 18 April were approved.  They are
available online:


A text version is included below.
Thomas Roessler, W3C  <tlr@w3.org>


                                 WSC WG Weekly
                                  18 Apr 2007


   See also: [3]IRC log


          Mary Ellen Zurko
          Thomas Roessler
          Johnathan Nightingale
          Chuck Wade
          Tyler Close
          Yngve Pettersen
          Jan Vidar Krey
          Maritza Johnson
          Luis Barriga
          Stuart Schechter
          Serge Egelman
          Phillip Hallam-Baker
          Bob Pinheiro
          Bill Doyle
          Mike McCormick

          Tim Hahn
          Bruno von Niman




     * [4]Topics
         1. [5]approving minutes from last meeting
         2. [6]closure of action items without further discussion
         3. [7]FSTC BMA Browser Recommendations
         4. [8]Revisiting Past Decisions
         5. [9]BMA document
         6. [10]ErrorHandling
         7. [11]Revisit ContextPresentation
     * [12]Summary of Action Items

approving minutes from last meeting

   Mez__: no issues

   <tlr> [13]http://www.w3.org/2007/04/11-wsc-minutes

   <tlr> minutes approved

closure of action items without further discussion

   <tlr> - no disagreement -

   Mez__: anyone want to speak to SafeWebBrowsing since Dan isn't here?

   who's speaking right now?

   <tlr> that was bob pinheiro

   thx Mez__

   <tlr> just type "??:", anybody else can do the corrections

   k thx

   bob p: I can speak to it, but let's wait for dan a bit

   Chuck: I can speak to FSTC BMA Browser recs

FSTC BMA Browser Recommendations


   Mez__: you talk for 5 minutes, then we discuss for 10

   <tlr> chuck: give me a second to settle

   <tlr> mez: happy to rearrange

   Mez__: we can re-arrange the schedule

Revisiting Past Decisions


   tlr: underlying assumption we make is that users will make decisions about
   ... these decisions determine the context they are in
   ... if that happens, it must be transparent to the user what impact their
   decisions have had
   ... those decisions should be reversible
   ... e.g. "Accept this certificate" should be a decision they can revisit,
   and can see the effect of
   ... if I override a warning, the browser shouldn't tell me "this is fine",
   it should tell me "you over-rode this"

   <ses> (Is Thomas on a speakerphone?)

   <Mez__> yes, that's tlr on a headset

   tlr: should be able to call up these decisions

   Mez__: swing into discussion portion
   ...  how  does  this  interact with the feedback we've gotten from the
   accessibility community
   ...  there  are  already mechanisms that let end users choose level of
   presentation detail, that the disabled community works more with info depth

   tlr: I admit, I hadn't considered it initially. I would hope it would be
   consistent with existing mechanisms for drilling down.

   Mez__: So there might be such mechanisms, but I haven't been able to figure
   that out
   ... Rob Y might be a point of reference here

   johnath I like reflecting the difference between native trust and your
   personal override

   johnath: are we suggesting, in addition to context-specific reflecting of
   decisions, a collecting-place with ALL of the user-override decisions?

   tlr: I could see an expert user being interested in the overall log of
   decisions, but not as relevant for avg users

   Mez__: I think we could use some concrete examples

   tlr: one example could be during drill down on a tls certificate, that
   should include whether the user made the decision

   Mez__: any more comments?
   ... what due date for the action item to update based on discussion (@tlr)

   <tlr> ACTION: roessler to update Revisiting Past Decisions [recorded in

   <trackbot> Created ACTION-198 - Update Revisiting Past Decisions [on Thomas
   Roessler - due 2007-04-25].

BMA document

   Mez__: chuck, ready to swing into fstc stuff?

   Chuck: yes, but are you aware that the docs on the website reference a
   broken doc?

   Mez__: I was able to dl it and open that way

   Chuck: the referenced file also doesn't match my own references, so I'm not
   sure which doc to speak to

   <Chuck> FSTC paper:

   Chuck: it could be the original doc submitted in March, or it could be the
   actual recs posted on fstc.org
   ... first point to make - the doc is long, covers a lot of territory, the
   most relevant for us is section 3 - Web Authentication Requirements
   ... it's a requirements document for the financial industry, addressing
   browser  and  server-side  requirements for authentication, focused on
   usability issues
   ...  this  doesn't  represent  anything new and surprising, but it's a
   pre-existing collection of data that's relevant
   ... the document from Mike M was really more of a source document, the
   fstc.org document is the output of the process.
   ... section 3.1 is about usability/security for persons - obviously relevant
   to us
   ... section 3.1.1 comes from the mass confusion around recommending browser
   configs to banking users
   ... section 3.1.2 talks about browser chrome - no surprises there
   ... section 3.1.3 talks about dialogs and alerts - how do users make sense
   of them
   ... section 3.2 is about security protocols, TLS, etc. Browser support for
   them, there is a concern around older browsers, supporting only weaker
   ... section 3.3 is about challenge/response dialogs
   ... section 3.3.2 talks about rowser support for these
   ... section 3.4 is all about cookies and automated form entry
   ... talks about techniques that would blind passwords, or support safer
   password communication like pwdhash
   ... financial industry is really keen on having this support built directly
   into the browsers

   <Zakim> tlr, you wanted to note cache overrun

   Mez__: stop, over time

   tlr: my short-term memory ran over. Can we split these into individual
   recommendation proposal that can be discussed individually?

   Tyler:  are there numbers on what percentage of customers use password

   Chuck: no hard stats - broad agreement that the majority of users do

   PHB: I see separate issues here. One is a "distinguished browsing mode" that
   reflects that the user is not in the normal state
   ... the second issue is around developing better methods for authentication
   (e.g. cardspace) that eliminate the need to secure the password in the first

   Chuck: Right, and this was discussed by the group. Another thing we are
   interested in is "liveness" testing - to ensure we're talking to a person.

   tlr: I think it would be valuable, independent of this discussion, to have a
   discussion about liveness tests and the interplay with accessibility since
   liveness tests often interfere with accessibility tools

   Chuck: having trouble hearing you

   tlr: (re-iterates)

   Chuck:  completely  agree,  and the financial services industry has an
   obligation to be accessible

   tlr: and that discussion might be outside the scope of this working group

   Chuck:  Just to clarify - fstc does discrete pieces of work. This work
   finished up last year, there is no active project doing BMA work at the
   moment for us to interact with.

   Mez__: time's up
   ...  Chuck  to  take  action to extract out the relevant-to-this-group
   recommendations from that document.

   Chuck: I will need to get permission to extract content (right now we only
   have permission to share the content, not to copy it)

   <tlr> ACTION: chuck to extract possible recommendations from section 3 of
   BMA   results  for  further  discussion  -  due  May  2  [recorded  in

   <trackbot>  Created ACTION-199 - extract possible recommendations from
   section  3  of BMA results for further discussion [on Chuck Wade - due

   Mez__: Bob have you heard anything from dan?

   <Mez__> zakim doesn't know that I'm the same person as the phone person

   <Mez__> unless I'm not?

   Bob: no, but we have had a phonecall on this topic to go over some of this -
   FSTC will be meeting next month to talk about Safe browsing
   ... does it make sense to defer for a month?

   Mez__: reluctant to defer for a month

   Bob: so the point here is just to get some discussion right?

   Mez__: yes, to get something written down, and to get some conversation

   Bob: okay, let's postpone till Dan is available

   tlr: I think there's an action on you Bob, to track him down
   ... I propose you take an action to organize this discussion for the next

   <tlr> ACTION: bob to organize review of Safe Browsing Mode proposal at next
   call [recorded in

   <trackbot>  Created ACTION-200 - Organize review of Safe Browsing Mode
   proposal at next call [on Bob Pinheiro - due 2007-04-25].

   <ses> ses has to leave in 2 minutes.


   <tlr> [20]http://www.w3.org/2006/WSC/wiki/ErrorHandling

   Mez__: we have discussed, as a group, error handling in a number of contexts
   ... lots of errors occur in terms of security context information, sometimes
   they are actually things masquerading as security info (imo) and sometimes
   they are errors in the process of acquiring information
   ... when they are actually security context information, they should be
   represented as such
   ... e.g. authenticating TLS with an untrusted self-signed cert - that is a
   piece of security context information and should be treated as such.
   ... but it needs to be something they understand in terms of their own
   mental model and understanding of risk
   ... otherwise the action should be taking for them
   ... text and explanations should follow our models (once we have them). Make
   it understandable for the user, actionable to the user.

   <yngve>      possible      relevant      article      I've     posted:

   Mez__: obviously this pre-supposes that we develop a model for the user's

   Chuck: the topic you've just raised is complemented by the FSTC paper I was
   ... Error handling keeps coming to the surface as a central challenge
   ... one thing I haven't heard so much in this group is the prevalence of
   badging on sites these days that say "you can trust this website, click here
   for information"
   ... what happens if some validation site says it's not a valid site - is
   that an error?

   Mez__: one thing that came to my mind during that discussion is that the
   negative state is actually two states - a bad state and a no-info state

   Chuck: right - EV cert without OCSP server, for example
   ... the technology doesn't provide users with the necessary information to
   decide how to cope with the uncertainty condition

   <Mez__>  wondering  if  we  will  need  to  say  something  about  the
   robustness/relaibility of inputs to the security context information

   tlr: I queued him based on his mention of a web article above

   yngve: that article is about problems with weak encryption
   ... in Opera 9 we have disabled small key lengths and SSLv2, but there are
   other cases (e.g. short RSA keys) are warnings
   ... the question is how to handle that kind of situation - perhaps we go
   ahead but don't display the padlock, perhaps we actively display that it
   isn't secure
   ... other examples are self-signed certs, domain mismatches

   <Mez__>  note  to self - consider detailed configuration of mapping of
   security context state, based on data/errors

   <Mez__> with good defaults

   yngve: for EV, our plan is not to show the green bar for certs we can't
   verify completely

   Mez__: do you have situations where you ask "if only the browser supported
   X, we could display better information"?

   yngve: don't follow

   Mez__: basically - are there a small number of states we could map all these
   error conditions to? Would 3 states do? 2?

   <Mez__> note to self - understanding vs using effectively

   yngve: I'm not sure. When we put up a warning, we don't really know if a
   site can be trusted. Or, in the case of weak encryption, where do we draw
   the line? Is this really strong enough?
   ... serious sites shouldn't trigger security warnings.

   Mez__: My reaction is that the user won't understand what's going on - so
   what  is it that we can communicate that will tell them enough to make

   yngve: I confess that I am more under the hood than usability
   ... at the moment, I think it's best to evaluate what the possibilities are.

   <Mez__> note to self - extract potential recommendations from yngve's blog

   tlr - one minute left

   Chuck: just going to observe that we also need to have security indicators
   be clearer about what kind of problem and what assurance exists
   ...  concrete  example.  Padlock is awkward because it sends radically
   different signals
   ... many proposals are about one or the other of these, trying to tease
   apart the signals
   ... people understand identity/privacy, if we break the signals apart,
   things will be easier to understand in error states

   yngve: opera has a multilevel padlock

   tlr - sorry to interrupt, we are past time

   <tlr> ACTION: zurko to extract refined proto-recs from record of discussion
   about  ErrorHandling  and Yngve's blog item on same topic [recorded in

   <trackbot> Created ACTION-201 - Extract refined proto-recs from record of
   discussion about ErrorHandling and Yngve\'s blog item on same topic [on Mary
   Ellen Zurko - due 2007-04-25].

   <tlr> ACTION-201 is due May 2.

   <tlr> due date fixed

Revisit ContextPresentation

   <Mez__> [23]http://www.w3.org/2006/WSC/wiki/ContextPresentation

   Mez__: are there other things to extract here in terms of recommendations?
   ... I feel like, for instance, we must have a whole cluster of recs around
   PKI detail/trust chains

   tlr: if I remember correctly, Mike M has an action to cover this

   Chuck: are we letting you overview this and then commenting, or are we
   interacting all the way down?

   Mez__: the latter

   Chuck: I would hate to see the table go away, it is a useful reference -
   even if we don't get any more recommendations out of it directly

   Mez__: I'm looking to extract recommendations from this table

   <yngve> HTTP in HTTPS: Opera remove padlock, but warn about POST HTTPS->HTTP

   tlr: may I suggest that we defer this and make it an agenda item of its own?

   Mez__: it already is - it's here, in the lightning discussions

   Tyler: I think it's useful as a list of tests for recommendations

   tlr: I think the problem is that people haven't gone through it yet and
   continue to suggest we make it an item on its own

   Chuck: I don't disagree with thomas, but was on queue to talk about cookie

   Mez__: would you be willing to do a lightning discussion on cookies and how
   they are presented?

   Chuck: I think the browser vendors would be better suited to speak to this
   ... there's a lot of information associated with cookies, but it isn't
   penetrable by users
   ... I think there's a lot of questions there that browser vendors are better
   suited to speak to?

   <tlr>  ACTION:  chuck  to  start  list  thread re cookies [recorded in

   <trackbot> Created ACTION-202 - Start list thread re cookies [on Chuck Wade
   - due 2007-04-25].

   Mez__: did you want to propose a follow up action?

   tlr: My proposal is to add an agenda item to next week's agenda

   Mez__: anyone else want it on there?

   johnath: I think it might be useful

   Mez__: okay - might not be next week because I'd like to get more discussion
   on robustness in next week if possible

   <tlr> ACTION: zurko to put another pass through ContextPresentation on one
   of   the   next   two   agendae   -   due   2007-05-02   [recorded  in

   <trackbot> Created ACTION-203 - put another pass through ContextPresentation
   on one of the next two agendae [on Mary Ellen Zurko - due 2007-05-02].

   Mez__: that's it

Summary of Action Items

   [NEW] ACTION: bob to organize review of Safe Browsing Mode proposal at next
   call [recorded in
   [NEW] ACTION: chuck to extract possible recommendations from section 3 of
   BMA   results  for  further  discussion  -  due  May  2  [recorded  in
   [NEW]  ACTION:  chuck  to  start  list  thread re cookies [recorded in
   [NEW] ACTION: roessler to update Revisiting Past Decisions [recorded in
   [NEW] ACTION: zurko to extract refined proto-recs from record of discussion
   about  ErrorHandling  and Yngve's blog item on same topic [recorded in
   [NEW] ACTION: zurko to put another pass through ContextPresentation on one
   of   the   next   two   agendae   -   due   2007-05-02   [recorded  in
   [End of minutes]

    Minutes formatted by David Booth's [32]scribe.perl version 1.128 ([33]CVS
    $Date: 2007/04/27 20:47:48 $


   1. http://www.w3.org/
   2. http://www.w3.org/mid/OFD4F466C3.E6DE6EA6-ON852572BB.00739399-852572BF.00721C00@LocalDomain
   3. http://www.w3.org/2007/04/18-wsc-irc
   4. file://localhost/home/roessler/W3C/WWW/2007/04/18-wsc-minutes.html#agenda
   5. file://localhost/home/roessler/W3C/WWW/2007/04/18-wsc-minutes.html#item01
   6. file://localhost/home/roessler/W3C/WWW/2007/04/18-wsc-minutes.html#item02
   7. file://localhost/home/roessler/W3C/WWW/2007/04/18-wsc-minutes.html#item03
   8. file://localhost/home/roessler/W3C/WWW/2007/04/18-wsc-minutes.html#item04
   9. file://localhost/home/roessler/W3C/WWW/2007/04/18-wsc-minutes.html#item05
  10. file://localhost/home/roessler/W3C/WWW/2007/04/18-wsc-minutes.html#item06
  11. file://localhost/home/roessler/W3C/WWW/2007/04/18-wsc-minutes.html#item07
  12. file://localhost/home/roessler/W3C/WWW/2007/04/18-wsc-minutes.html#ActionSummary
  13. http://www.w3.org/2007/04/11-wsc-minutes
  14. http://www.w3.org/2006/WSC/wiki/DocsRepository/FSTC_Contributed_Documents?action=AttachFile&do=get&target=FSTC+BMA+Browser+Recommendations
  15. http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0004.html
  16. http://www.w3.org/2007/04/18-wsc-minutes.html#action01
  17. http://fstc.org/projects/docs/Recommendations_and_Requirements_for_BMA_v1.0.pdf?PHPSESSID=20cc0c14758294534c58cac8a9e1a685
  18. http://www.w3.org/2007/04/18-wsc-minutes.html#action02
  19. http://www.w3.org/2007/04/18-wsc-minutes.html#action03
  20. http://www.w3.org/2006/WSC/wiki/ErrorHandling
  21. http://my.opera.com/yngve/blog/show.dml/461932
  22. http://www.w3.org/2007/04/18-wsc-minutes.html#action04
  23. http://www.w3.org/2006/WSC/wiki/ContextPresentation
  24. http://www.w3.org/2007/04/18-wsc-minutes.html#action05
  25. http://www.w3.org/2007/04/18-wsc-minutes.html#action06
  26. http://www.w3.org/2007/04/18-wsc-minutes.html#action03
  27. http://www.w3.org/2007/04/18-wsc-minutes.html#action02
  28. http://www.w3.org/2007/04/18-wsc-minutes.html#action05
  29. http://www.w3.org/2007/04/18-wsc-minutes.html#action01
  30. http://www.w3.org/2007/04/18-wsc-minutes.html#action04
  31. http://www.w3.org/2007/04/18-wsc-minutes.html#action06
  32. http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/scribe/scribedoc.htm
  33. http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 27 April 2007 20:53:04 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 5 February 2008 03:52:47 GMT