See also: IRC log
Mez__: no issues
<tlr> http://www.w3.org/2007/04/11-wsc-minutes
<tlr> minutes approved
<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
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
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Apr/0004.html
tlr: underlying assumption we make is that
users will make decisions about security...
... 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 http://www.w3.org/2007/04/18-wsc-minutes.html#action01]
<trackbot> Created ACTION-198 - Update Revisiting Past Decisions [on Thomas Roessler - due 2007-04-25].
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: http://fstc.org/projects/docs/Recommendations_and_Requirements_for_BMA_v1.0.pdf?PHPSESSID=20cc0c14758294534c58cac8a9e1a685
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
encryption
... 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 managers?
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
place.
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 http://www.w3.org/2007/04/18-wsc-minutes.html#action02]
<trackbot> Created ACTION-199 - extract possible recommendations from section 3 of BMA results for further discussion [on Chuck Wade - due 2007-05-02].
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 going
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
call
<tlr> ACTION: bob to organize review of Safe Browsing Mode proposal at next call [recorded in http://www.w3.org/2007/04/18-wsc-minutes.html#action03]
<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> 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: http://my.opera.com/yngve/blog/show.dml/461932
Mez__: obviously this pre-supposes that we develop a model for the user's understanding
Chuck: the topic you've just raised is
complemented by the FSTC paper I was discussing.
... 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 decisions.
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 entry
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 http://www.w3.org/2007/04/18-wsc-minutes.html#action04]
<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
<Mez__> 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 info
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 http://www.w3.org/2007/04/18-wsc-minutes.html#action05]
<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 http://www.w3.org/2007/04/18-wsc-minutes.html#action06]
<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