See also: IRC log
Â
Â
<trackbot-ng> Date: 22 August 2007
<tlr> ScribeNick: hal
<tlr> http://www.w3.org/2007/08/15-wsc-minutes.html
resolution: approved unanamously
tlr: suggest switching items 7
& 8
... should cover 9 for sure
mez: will move 9 up
<ifette> no
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0123.html
tyler: need to apply usability
principles
... in order to meet criteria should drop page info
summary
... studies show little benefit
... could still put out doc saying what should be done
... but not part of rec
... not dilute efforts
... want readers to immediatly see benefit form following
recommendation
... invites simple criticisms
tlr: tyler have you looked at most recent draft?
tyler: no
tlr: I don't think we are
claiming this section will help prevent phising
... moving it to a note will consume as much time
... support keeping it in now
... need to consider restructuring infomaiton
... need to separate secondary from primary info
serge: what sort of security
scenarios will this help with?
... users ignore it and it can be spoofed
... why leave it in?
chuck: attack scenarios change
radically
... industry is always playing catchup
... allow users to prevent future attacks
... few people detecting attacks alert others
... providing better tools to the few will help the rest
<tlr> totally +1 to what Maritza says.
<Zakim> ifette, you wanted to talk about expert users having separate tools and not needing something in the browser
maritzaj: offering improvements will be valuable and not too much work - current is real bad
<Zakim> Mez, you wanted to suggest that if we continue to carry forward Info bar we not do any usablity testing on it (as inspired by a comment from tyler)
<Zakim> rachna, you wanted to suggest that assumptions should be clearly spelled out in proposals
<tlr> actually, the "Additional Security Context Information", as it is called in the latest draft.
<serge> We don't need to do any usability testing, because it's already been done and shown that this is ineffective.
mez: suggest including it but not doing usability testing
rachna: would be useful to expert users
tyler: use by experts is why I propose moving not deleting - make it a note
<Zakim> johnath, you wanted to try to pull good reasons for dropping it out from bad
rachna: couldn't say so in rec instead of moving it ot note
<Mez> btw, Rachna, PII editor bar use eval is up after this discussion, not last, as the original agenda suggested
<Mez> so stick around :-)
johnath: need to separate good
reasons from bad
... effort may not be most important factor
<tlr> If arguing that a section puts the document into disrepute, it would be refreshing if the argument was at least against the latest draft.
johnath: if we feel we should
recommend
... current page info is poor, does not prove better would not
help
<tlr> oh yes, indeed. Tech-supporting my mother on a browser that I don't run is *so* much fun.
bill-d: hard for hellp desks to deal with non-std page info
<Mez> Q: "The page info summary recommendation proposal http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#pageinfosummary should become a Note, similar to the Threat Trees work, and not be included in our FPWD recommendations" (yes/can live with/no)
<tlr> no
mez: will do straw poll now
<Mez> Tim: no
<Mez> Michael M: no
<tlr> bill-d: no
<bill-d> no
<johnath> no
<sduffy> no
<ifette> No (Should *not* become a note, stay in rec)
no
<Chuck> no
<tyler> yes
<serge> yes
<Mez> abstain
<asaldhan> no
<maritzaj> no
<luis> neutral
<luis> no
<Mez> Dan: yes
<tlr> (confusion what is meant)
mez: vote in favor of leaving it
<tlr> ACTION: thomas to obtain disclaimer-style text for Additional Security Context Information [recorded in http://www.w3.org/2007/08/22-wsc-minutes.html#action01]
<trackbot-ng> Created ACTION-282 - Obtain disclaimer-style text for Additional Security Context Information [on Thomas Roessler - due 2007-08-29].
<tlr> With the observation that this might be reassigned to somebody else.
tlr: 2 or 3 observations
... in usability section some parts were so unclear they could
not be tested
... need to know if discussions have clarified this
<tlr> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0127.html
tlr: need to look at difference between PII and current
<tlr> http://www.w3.org/2006/WSC/wiki/RecommendationUsabilityEvaluationFirstCut
<tlr> http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor
<tyler> http://www.w3.org/2006/WSC/drafts/rec/#piieditor
tyler: wiki is not up to date
<Mez> PII EditorBar
<Mez> Requirements - this proposal assumes that:
<Mez> Users have the extension installed in their browser.
<Mez> Users are novice users- they are not security experts and received no training.
<Mez> User Expectations- this proposal assumes that:
<Mez> Users will complete the bootstrap scenario, and they will select petnames for sites they care about.
<Mez> When a user wants to fill out a web form, the user will enact the attention sequence key to move from the web form to the editor bar.
<Mez> The user will notice when an illegitimate page requests information that has previously been submitted to this website.
<Mez> The user will not submit data to a website that requests data which has been previously submitted to that website.
confusion over what is current text
<Mez> The user will not be tricked by an illegitimate page that tries to convince the user to create a new relationship with the site.
<Mez> The user will remember that they previously created a relationship with this website and be suspicious, OR
<Mez> The browser will detect the reuse of a petname, because the user will rename the same site with the same petname as used previously.
<Mez> Users will pick unique petnames, and they won't be tricked by PII editor bar spoofing that attempts to mimic their customization.
<Mez> Relevant Literature
<Mez> What is known
<Mez> Can users use the activation sequence correctly? One prior study (A Usability Study and Critique of Two Password Managers by Sonia Chiasson and P.C. van Oorschot) indicates that users have trouble remembering to activate an attention sequence, activating it at the right time (e.g., when focus is in the text box), or in knowing when it has been activated. For example, in the study of Password Multiplier, they found that users would not know if they had entered the attent
<Mez> Are users willing to make site specific nicknames? From deployments of the petname toolbar (e.g., at HP), we can get an estimate of how many users gave a petname to what sites, and how many chose the same petname for a given site.
<Mez> Unknown
<Mez> Will users be willing to use the attention sequence for each form field? Shifting focus away from each field may require more effort than the effort of typing, because it is cumbersome and a new skill (most users do not use keyboard shortcuts and use the mouse to move between fields).
<Mez> Will users correctly fulfill the behavioral expectations described above and not succumb to spoofing attacks?
<Mez> Testing
<Mez> We require a prototype implementation of this proposal to do further analysis, because much of the usability and security will depend on specific design decisions.
<Mez> http://lists.w3.org/Archives/Public/public-wsc-wg/2007Aug/0029.html
those to URIs point to the same message
tyler: will need to provide some user training before usability testing
rachna: possible to train part way thru or train some users and not others
<serge> the Jackson study, it's in the Bookmarks
<johnath> mez - the picture in picture
rachna: sometimes training can hurt
<Zakim> johnath, you wanted to ask if that would artificially inflate the success?
rachna: study of IE 7 is an example
joahath: need to at least do some with no training
<Zakim> ifette, you wanted to ask about realism of expecting training for browsers?
joahath: to get realistic results
ifette: +1 to Johnath
<ifette> but nobody reads start screens
<johnath> rachna: true
rachna: could have some initial help screens
<Zakim> johnath, you wanted to reply to tyler
<ifette> +1 to no training
tyler: if decide no training, should apply to all tests
<serge> there's another issue: if we show them how to do it in the lab, will they continue to do it at home
johnath: should be clear on what testing is trying to accomplish
tlr: critical piece is to be
clear about what a particular test is about
... not immediate decision
... suggest getting back to main thread
maritzaj: is this for everyone all the time or just certain situaitons
tyler: all the time for everyone
maritzaj: not unreasonable to
assume some training
... problem with lock is most people don't know what it
indicates
tyler: this apporach is not passive, interrupts user
<ifette> what they're talking about right now (what user action is required, for all vs for some etc)
maritzaj: user needs to take initiatave first time
<Mez> http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor
<tlr> http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor-usecases-bootstrap
tyler: not so look at doc - user is prompted for Pet name
<tlr> point of order, can we keep *this* discussion to essential clarifications and move to the merits at one of the next calls, to stick somewhat to the agenda?
ifette: very worried about interupting users flow or turn off feature
tyler: does not interrupt - form filler drives it
ifette: if I am on site and create new account and password will I be interupted?
tyler: only if you use pass manager or form filler
ifette: worried about dictating UI
tyler: thats the purpose of WG
tlr: rather than getting into merits, just stick to clarifications
<tlr> The user will notice when an illegitimate page requests information that has previously been submitted to this website. The user will not submit data to a website that requests data which has been previously submitted to that website.
tlr: clarification needed in usability evaluaton
<Mez> The user will notice when an illegitimate page requests information that has previously been submitted to this website.
<Mez> The user will not submit data to a website that requests data which has been previously submitted to that website.
rachna: wanted to list spoofing conditions that user might notice and see if they do
<tlr> http://www.w3.org/2006/WSC/drafts/rec/Overview.html#piieditor-usecases-imposter
rachna: if user detects something
fishy
... not describing scenario
tyler: propsal is completely intrusive, no user option
rachna: would like authors to define success
<tlr> ScribeNick: tlr
hal: if tyler's thing prevents
people from typing in, not gonna spend a lot of time ...
... but maybe is something else wrong? ...
... question is, set up test so it's strawman ...
... obvious part that should succeed will succeed ...
... that seems to be difficult issue ...
rachna: good point
tyler, rachna engage in speed talking contest
tyler: chuck reported people use form filler for banking passwords
<ifette> lol
tyler: take from that that form fillers etc are already used ...
<Zakim> ifette, you wanted to say it should be voluntary
ifette: if mandatory users will avoid in some way
rachna: need to test annoyance in UI testing
<scribe> ScribeNick: hal
tyler: will only know until we
test
... believe users will have to interact, not just pictures
tyler: would like to sit do and be coached on Mozzilla APIs required
Mez: could do this at F2F
<Mez> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#error-handling
<tlr> Code sprint might be useful in *addition* to a f2f.
tlr: if security is degraded in minor way don't interupt user
<rachna> signing off- I have to go to a mtg. Tyler let's continue this discussion to get your comments into the usability text.
tlr: if serious change to
security properties - interupt user, provide help
... should be able to get back to where you left off
<tyler> Ok, you can call me at the office until Thursday
tlr: error interactions not
popups, but error pages
... if user disables, ???
<tlr> http://www.w3.org/2006/WSC/drafts/rec/rewrite.html#id2739434
mez: looks like section 3.1 follows this, serge do you agree?
<tlr> *cough* will fix the anchor ASAP
serge: don't know
tlr: lots of warnings that get
ignored
... try to identify really bad security and force
interaction
tlr: try to distingush between to cases
serge: need strong rare warnings for serious problems
<tlr> ACTION: serge to contribute references to support 5.3.1 [recorded in http://www.w3.org/2007/08/22-wsc-minutes.html#action02]
<trackbot-ng> Created ACTION-283 - Contribute references to support 5.3.1 [on Serge Egelman - due 2007-08-29].
<Mez> hal, want to scribe your comments?
hal: 2 comments
... propsal depends on ability to distinguish between cases, which will be hard to establish emprically
... going back to where you were may be very hard, especially synching btw web site and browser
tlr: agree with first, second -
only back to prior user agent state not web site
... start TLS negotiaiton - server shows good cert, but domain
name is wrong
tlr: have means to know what correct url is
tlr: suggest augment error page to contain live link to site
tlr: option to user to follow
link
... constructing url must be possible from cert alone
tlr: must use safe method to access site
<Zakim> ifette, you wanted to note scary use case
<Zakim> Mez, you wanted to say make more general, if user has nicname, use that (probably same as ian)
ifette: scary scenario - browser appears to endorse bad guy site
mez: DNS based identity is scary
tlr: agree attack would be
possible
... 2 things to mitigate
... user needs ?? from authority
... would reference org not user
<Mez> DN's are scarey too, btw (org field, etc)
tlr: idea is to interrupt flow and check w/o leaking info to bad guys
bill-d: discussion on list - use known good DNS server - does that solve problem?
<Mez> We're wrapping after this question; it's time folks
tlr: no - typical circumstance that they are intercepting at TCP level
<ifette> someone doing the zakim, rrsagent commands to draft minutes?